Upgrade APEX 4.1.1 to 4.2.1 on Oracle Linux with GlassFish

Environment: Oracle Linux 6.3, Oracle database 11.2.0.3.0 EE, APEX 4.1.1.00.23, GlassFish 3.1.2.2

This blog post explains how you can upgrade your Application Express installation from version 4.1.1 to version 4.2.1, with the APEX Listener deployed under GlassFish.

Steps:

1) download the software

Update: APEX 4.2.1 is no longer available from the Oracle website. Please use a more recent version of APEX (5.1, 18.x, 19.x). You can download the software here.

2) copy and extract the software

Now copy and extract the apex_4.2.1.zip file to your server. I use “unzip” to unzip the zip file. This will create a folder named “apex”. I usually keep this folder on my server in a permanent location, for example /u01/app/apex.

3) check the tablespace requirements

You need about 275MB of free space in the APEX tablespace (mine is called “APEX”) and 100MB of free space in the SYSTEM tablespace.

4) stop the APEX Listener

Before you start with the upgrade, you need to stop the APEX Listener to make sure no one is using the software during the upgrade.

To stop the APEX Listener under GlassFish, you can do it as follows:

– connect to the GlassFish administration console (by default this is port 4848 using SSL).

– log in with the “admin” user.

– click on Standalone Instances => Applications.

– select the “apex” application and select “Disable” from the “More Actions” drop down list.

The APEX Listener should now be stopped on your GlassFish instance.

5) start the upgrade

To upgrade the APEX software, you need to run the “apexins.sql” sql script from within the “apex” folder that you extracted above. You need to connect as SYS as SYSDBA with the oracle software owner (mine is called “oracle”). Make sure the “apex” folder is writeable!

apexins.sql needs 4 parameters: the name of the tablespace for the APEX user (in my case: APEX), the name of the tablespace for the FLOWS_FILES user (in my case: APEX), the name of the TEMP tablespace (in my case: TEMP) and the name of the virtual image directory (which is “/i/”).

$ su - oracle
$ cd /u01/app/apex
$ sqlplus /nolog
SQL*Plus: Release 11.2.0.3.0 Production on Thu Jan 3 11:21:39 2013

Copyright (c) 1982, 2011, Oracle. All rights reserved.

SQL> connect / as sysdba
Connected.
SQL> @apexins.sql APEX APEX TEMP /i/

The upgrade will now start. This will create a new schema called “APEX_040200”. The upgrade can take some time, depending on the speed of your server. On my server (with fairly recent hardware), it took about 17 minutes. After the upgrade, check the installation log file (in the same folder where you exectuted the apexins.sql file) to make sure no errors were encountered during the process.

6) verify the installation

I always verify my APEX installation after a upgrade by querying dba_registry:

$ sqlplus /nolog

SQL*Plus: Release 11.2.0.3.0 Production on Thu Jan 3 12:06:21 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn / as sysdba
Connected.
SQL> select status from dba_registry where comp_id='APEX';

STATUS
-------------------------------------------------------
VALID

7) copy the images

Next, copy the new and updated images from your installation folder to the GlassFish docroot (you might take a backup folder of the original docroot/i folder just in case):

$ cp -rf /u01/app/apex/images/* /u01/app/glassfish/glassfish/nodes/localhost-domain1/node01/docroot/i/

8) start the APEX Listener

Finally, start the APEX Listener again (see under step 4) and check if all your applications work fine :-) You should now have a nicely upgraded APEX 4.2.1.00.08 installation!

HTH,

Matthias

 

Update:

If you are accessing network services from withing APEX, like LDAP authentication, print servers and such, you will need to grant the new APEX_040200 user network access or it won’t work. This is documented in the installation guide and is only needed for Oracle 11g. You can grant network access by running the following PL/SQL script with user SYS as SYSDBA:

DECLARE
ACL_PATH VARCHAR2(4000);
BEGIN
-- Look for the ACL currently assigned to '*' and give APEX_040200
-- the "connect" privilege if APEX_040200 does not have the privilege yet.
SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_040200',
'connect') IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH,
'APEX_040200', TRUE, 'connect');
END IF;
EXCEPTION
-- When no ACL has been assigned to '*'.
WHEN NO_DATA_FOUND THEN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml',
'ACL that lets power users to connect to everywhere',
'APEX_040200', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');
END;
/
COMMIT;

 

APEX 4.2.1 and APEX Listener 2.0 released!

First of all: a happy New Year to all my blog readers! I wish you an exciting 2013 with lots of interesting projects, no budget restraints and no unexpected downtime ;-)

When I returned from the Christmas holidays, I noticed that both Application Express 4.2.1 and the APEX Listener 2.0 have been released!

APEX 4.2.1 is actually the first patch set release for APEX 4.2. You can download the full release here (for new installations or upgrades) or, if you have a support contract, you can download the patch only (with number 14732511) here (for upgrades from version 4.2). There are a lot of bugs that have been fixed with this patch set (check for a full list here),  and also some new features have been introduced, for example the inclusion of AnyChart version 6 (which has even more HTML5 support). I’m happy with this patch set release, since this means it’s time to upgrade for us. We had some issues in the past after upgrading to a minor APEX release, so I learned to have patience and wait for the first patch set ;-)

Application Express Listener 2.0 was available as a Early Adaptor version for a while, but now the first production release is available. There are a lot of new features, like the ability to define multiple database connections, and more support for RESTful services. There are now also 2 ways to configure it: using SQL Developer (you need at least version 3.2.2) and using a new command-line interface. The web interface however has been removed, which I find a bit sad because I liked it :( We are using the APEX listener deployed to GlassFish, and I’m not sure if anything has changed in that matter. This is something I need to look into. I also wonder how you would upgrade from a previous version of the APEX Listener to this one. I suppose this involves some redeployment, and so also some (planned) downtime.

Enjoy,

Matthias

How to modify the version of Java used for GlassFish 3.1.2.2

Environment: GlassFish 3.1.2.2 OSE Web Profile, Oracle Linux 6.3, Java 7 Update 7.

Whenever you upgrade your Java installation or install a new version, you have to make sure that your GlassFish installation is using the new version.

1) Download and install the new Java JDK 

New versions of Java can be found here. For GlassFish, you need to download the JDK (so not JRE), and you can use both Java 6 or Java 7.

For example, I downloaded and installed JDK 7 Update 7 to /u01/app/jdk1.7.0_07 and I created a symbolic link “java7” to it:

$ /u01/app/java>tar -zxf jdk-7u7-linux-x64.tar.gz
$ /u01/app/java>ln -sf jdk1.7.0_07 java7
$ /u01/app/java>ls -la
total 93904
drwxr-xr-x   4 oracle oinstall     4096 Sep 10 15:16 .
drwxr-xr-x   7 oracle oinstall     4096 Feb 17  2012 ..
lrwxrwxrwx   1 oracle oinstall       11 Feb  7  2012 java6 -> jdk1.6.0_30
lrwxrwxrwx   1 oracle oinstall       11 Sep 10 15:16 java7 -> jdk1.7.0_07
drwxr-xr-x  10 oracle oinstall     4096 Feb  3  2012 jdk1.6.0_30
drwxr-xr-x   8 oracle oinstall     4096 Aug 29 03:12 jdk1.7.0_07

2) Modify the GlassFish domain config file and JAVA_HOME environment variable

Next, you need to modify the AS_JAVA  variable in the GlassFish config file “asenv.conf”. In my case, this file was stored in the folder /u01/app/glassfish/glassfish/config. I changed it as follows:

AS_JAVA=/u01/app/java/java7

You also need to modify the environment variable JAVA_HOME. This variable can be found in the .bash_profile file of the user which is used to start GlassFish. Run “echo $JAVA_HOME” to see its current value. After the changes, log out and log in again (or run .bash_profile) to reset it.

3) Restart the GlassFish domain server

Restart the GlassFish domain server and any other server instances you might have.

/u01/app/glassfish/bin/asadmin stop-local-instance
/u01/app/glassfish/bin/asadmin stop-domain domain1

/u01/app/glassfish/bin/asadmin start-domain domain1
/u01/app/glassfish/bin/asadmin start-local-instance

 

HTH,

Matthias

 

 

Monitoring JVM memory performance of GlassFish 3.1.2

Environment: GlassFish OSE 3.1.2.2, Oracle Linux 6.3

In this blog post I will explain how you can enable and monitor the memory statistics of the Java Virtual Machine in GlassFish 3.1.2.

1) Enable monitoring for the JVM module

There are 2 ways to enable JVM monitoring: by using the graphical admin console, or from the command line by running the asadmin command.

From the graphical admin console

Start up the admin console (by default this runs on port 4848), log in as admin and click on “Monitoring Data” in the left menu. Now click on “Configure Monitoring” in the right menu for the instance you want to monitor. You should now see the screen with the list of configurable components (see screenshot below). Set the Monitoring Level of the JVM component to “Low” and click on Save. No instance restart is needed for this change.

From the command line

Start up the asadmin command (under the ../glassfish/bin folder). Use the subcommand “enable-monitoring” or “disable-monitoring” to enable/disable monitoring for a specific component. To specify the instance that you want to configure, add the “–target” option.

asadmin> enable-monitoring --modules jvm=LOW --target myinstance
Command enable-monitoring executed successfully.

2) View JVM memory statistics

From the graphical admin console

Click on “Monitoring Data” in the left menu and then on “Server” (under “View Monitoring Data”) in the right menu. You should now see the Server Monitoring screen (see screenshot below). To view the JVM memory statistics, click on the blue arrow next to “JVM: Memory Statistics”.

From the command line

Start up the asadmin command. Use the “get –monitor” subcommand to retrieve the required monitoring statistics.

asadmin> get --monitor myinstance.jvm.memory.usedheapsize.*
myinstance:
myinstance.jvm.memory.dotted-name = myinstance.jvm.memory
myinstance.jvm.memory.usedheapsize-count-count = 119150920
myinstance.jvm.memory.usedheapsize-count-description = Amount of used memory in bytes
myinstance.jvm.memory.usedheapsize-count-lastsampletime = 1346166888774
myinstance.jvm.memory.usedheapsize-count-name = UsedHeapSize
myinstance.jvm.memory.usedheapsize-count-starttime = 1346144878093
myinstance.jvm.memory.usedheapsize-count-unit = bytes

Command get executed successfully.

3) Schedule monitoring

To schedule the monitoring of memory statistics, you could easily add a command line entry to your crontab file. The following example will execute every 10 minutes and write the datetime and the usedheapsize to a log file.

>crontab -l
*/10 * * * * echo `date`>>/tmp/glassfish_memory.log;/u01/app/glassfish/bin/asadmin get --monitor myinstance.jvm.memory.usedheapsize-count-count>>/tmp/glassfish_memory.log

HTH,
Matthias

Upgrading APEX Listener from 1.1.3 to 1.1.4 on GlassFish 3.1.2.2

Environment: APEX Listener 1.1.4, GlassFish 3.1.2.2 OSE Web Profile, Oracle Linux 6.2 64-bit

In this post I will explain how you can upgrade the APEX Listener from version 1.1.3 to version 1.1.4 deployed under GlassFish.

Note: unless you are running a GlassFish cluster, there is no way to upgrade the APEX Listener without interruptions. However, if you plan things well, you can minimize downtime to only a few minutes.

Step 1: download and unzip the new software

Version 1.1.4 of the APEX Listener can be downloaded here. There are no separate 32-bit/64-bit versions or different versions for Windows/Linux. Put the zip file somewhere on the file system of your server and unzip it. Inside the zip file you will find the documentation files and the apex.war file, which contains the source code.

Step 2: modify the web.xml file inside apex.war

Before deploying the new APEX Listener, we will first modify the location of the config file inside the apex.war file. By default, the config file is stored in /tmp, but since this is a temporary file system, you might lose this file after a server reboot and APEX will stop working.

To modify the location of the config file, we need to extract the apex.war file, modify the web.xml file and finally recreate the apex.war file.

First, extract the apex.war file into a new folder by using the Java “jar” utility:

oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4/modified>/u01/app/java/java6/bin/jar xf ../apex.war
oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4/modified>ls -la
total 32
drwxr-xr-x 8 oracle oinstall 4096 Aug 20 14:45 .
drwxr-xr-x 5 oracle oinstall 4096 Aug 20 14:44 ..
drwxr-xr-x 2 oracle oinstall 4096 Jun 15 22:04 api
drwxr-xr-x 2 oracle oinstall 4096 Jul 13 00:14 ____embedded
drwxr-xr-x 2 oracle oinstall 4096 Jul 13 00:19 META-INF
drwxr-xr-x 2 oracle oinstall 4096 Jun 15 22:02 resourceTemplates
drwxr-xr-x 5 oracle oinstall 4096 Jun 15 22:03 scripts
drwxr-xr-x 3 oracle oinstall 4096 Jul 13 00:19 WEB-INF

Next, use a text editor to uncomment and modify the “config.dir” param-value inside the WEB-INF/web.xml file. This is how the first part of my web.xml file looks like:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
        xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
        <display-name>ApexMod</display-name>
        <context-param>
                <param-name>config.dir</param-name>
                <param-value>/home/oracle/apex_listener/config</param-value>
        </context-param>
        <context-param>
                <param-name>version</param-name>
                <param-value>1.1.4.195.00.12</param-value>
        </context-param>

Note that my APEX Listener config file is stored under /home/oracle/apex_listener/config/apex.

Now let’s recreate the apex.war file again using the “jar” utility:

oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4/modified>/u01/app/java/java6/bin/jar cf ../apex.war .
oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4/modified>cd ..
oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4>ls -la
total 20140
drwxr-xr-x 5 oracle oinstall     4096 Aug 20 14:44 .
drwxr-xr-x 6 oracle oinstall     4096 Aug 17 11:22 ..
-rwxr-x--- 1 oracle oinstall 10719937 Aug 17 11:26 apex_listener.1.1.4.195.00.12.zip
-rw-r--r-- 1 oracle oinstall  9839841 Aug 20 15:09 apex.war
drwxr-xr-x 5 oracle oinstall     4096 Jul 13 00:20 docs
-rw-r--r-- 1 oracle oinstall     2906 Jul 13 00:20 index.htm
drwxr-xr-x 4 oracle oinstall     4096 Jul 13 00:20 javadoc
-rw-r--r-- 1 oracle oinstall    24890 Jul 13 00:20 license.html
drwxr-xr-x 8 oracle oinstall     4096 Aug 20 14:45 modified
-rw-r--r-- 1 oracle oinstall     3242 Jul 13 00:20 readme.html
oracle@ol6ora11g02 /u01/app/apex_listener/1.1.4>rm -rf modified

Step 3: redeploy the apex.war file under GlassFish

Start up the GlassFish admin console (by default it runs under port 4848), click on “Applications” and then click on “Redeploy” next to the “apex” application (or whatever you called your APEX Listener deployment).

 

In the next screen, browse to the new “apex.war” file and click on “OK”. This will remove the old APEX Listener and deploy the new version. If everything went fine, click on “Launch” to check if APEX is working fine again. In case of errors, you should check the server.log file for the GlassFish instance where you deployed the APEX Listener.

That’s it! Good luck :-)

 

Matthias

Removal of APEX Listener cache folder causes hanging of APEX

Environment: APEX 4.1, GlassFish 3.1.1/3.1.2, APEX Listener 1.1.3, Oracle Linux 6.2 64-bit

In the past couple of months, we had several lock ups of our APEX environments. This all started after we moved to GlassFish with the APEX Listener. The symptoms were always the same: all database connections in the connection pool were in use and hanging, and we had to restart the GlassFish instance to release them.

Today, I was finally able to reproduce this problem at will and I found a solution!

The problem is caused by the removal of the file system folder that the APEX Listener uses to cache files.

We had the file caching enabled to increase the performance of a APEX application which downloads images from the database through a procedure.

This is how our caching is configured:

As you see, the caching folder is set to /tmp/apex/cache. I believe this is the default configuration.

Now, for some reasons, Linux sometimes removes all folders from the /tmp folder. And this not only happens after a server reboot! There must be some process scheduled to do this, but I haven’t found yet which one. When we had a recent hang of APEX I noticed some broken images in the applications. I checked the file system and behold, the file cache folder was gone! A restart of the GlassFish instance (and so also the APEX Listener) recreated the caching folder.

Maybe this issue has been fixed in the newer version 1.1.4 of the APEX Listener, I didn’t try it out yet…

In the mean time, I found a permanent solution for the problem by setting the Cache File Location to a folder outside the /tmp file system, for example /home/oracle/apex/cache.

 

Matthias

GlassFish Server release 3.1.2.2 fixes APEX file download bug

A new microrelease version of GlassFish Server has been released: version 3.1.2.2. According to the release notes, the following issues were fixed:

  • NetBeans bug 211962
  • JAX-WS issue JAX_WS-1059
  • GlassFish Server issue GLASSFISH-18446

I didn’t find the time to try out this new release yet, but according to the bug issue list, it also contains a fix for GlassFish issue 18444, something that I blogged about in one of my previous posts. Since this bug breaks the file downloads in APEX, it’s a critical issue, so it’s strange they didn’t mention this in the release notes.

 

Matthias

Configuration and deployment of PDF printing in APEX 4.1.1 using GlassFish 3.1.2 and Apache FOP

Environment: Oracle database 11.2.0.3, APEX 4.1.1, GlassFish 3.1.2 Open Source Edition (Web Profile), Oracle Linux 6.2

Update: Apache FOP support has been deprecated in ORDS 19.2. So please don’t upgrade to ORDS 19.2 (or higher) if you still rely on Apache FOP for PDF generation.

Apache FOP (XSL-FO Processor) can be used together with APEX to allow PDF printing of classic or interactive reports. In this blog post, I will explain how you can deploy and configure FOP in APEX 4.1.1 with GlassFish 3.1.2.

Apache FOP can be installed on a Java application server by deploying the fop.war web archive, which can be found in the /utilities/fop folder inside the APEX installation files. However, the fop.war file does not work out of the box on GlassFish 3.1.2.

I faced two different kind of errors in my installation:

1) package oracle.xml.parser.v2 does not exist: this is because GlassFish can’t find the xmlparserv2.jar file which can be found in $ORACLE_HOME/lib.

2) java.lang.IllegalStateException: getOutputStream() has already been called: this has something to do with getOutputStream() being used more than once; I’m far from a Java specialist, but I found a workaround for this problem on the internet.

This is the solution:

First, we need to extract the original fop.war file (I used the jar utility from my Java 6 JDK installation):

$ /u01/app/java/java6/bin/jar -xf fop.war

You should see the following:

$ ls -la

-rw-r–r– 1 oracle oinstall 1792 May 4 12:44 apex_fop.jsp
-rw-r–r– 1 oracle oinstall 7016135 May 4 12:44 fop.war
drwxr-xr-x 4 oracle oinstall 4096 May 4 14:00 WEB-INF

Next, copy the xmlparserv2.jar file from $ORACLE_HOME/lib into the WEB-INF/lib folder:

$ cp -p /u01/app/oracle/product/11.2.0/db_1/lib/xmlparserv2.jar WEB-INF/lib

Now we need to modify the two apex_fop.jsp files in the top folder and under WEB-INF/classes. Add the following 2 lines just before the final “driver.run();” call:

out.clear();
out = pageContext.pushBody();

The full apex_fop.jsp file should look like this:










Now we are going to recreate the fop.war file:

$ /u01/app/java/java6/bin/jar -cvf fop.war apex_fop.jsp WEB-INF

We are now ready to deploy the fop.war file in GlassFish:

– start up the GlassFish admin console (default: port 4848)

– click on Standalone Instances -> your instance

– click on Applications -> Deploy -> local packaged file… and browse to the “fop.war” file (see screenshot below)

– click on OK; “fop” should now appear in the list of Deployed Applications

After this, you can already test your Apache FOP deployment by opening http://<servername&gt;:<port>/fop/apex_fop.jsp in a web browser. If you see a Java NullPointerException error, things are looking good ;-)

Finally, we need to tell APEX where to find the print server:

– log in to the APEX workspace “internal” with the username “admin”

– click on Manage Instance -> Instance Settings

– fill in the Report Printing part (see screenshot below):

Print Server: External (Apache FOP)
Print Server Host Address: localhost
Print Server Port: (your APEX port)
Print Server Script: /fop/apex_fop.jsp

That’s it! Now try to print a report as PDF in APEX; it should work fine!

 

Matthias

 

 

File upload fails for APEX 4.1.1 with GlassFish 3.1.2

Environment: APEX 4.1.1, GlassFish 3.1.2 Open Source Edition, Oracle database 11.2.0.3.0, Oracle Linux 6.2

I tried to export/import some workspaces and applications from APEX 4.1.1 with GlassFish 3.1.1 and Oracle 10g to a new server which had a fresh installation of APEX 4.1.1 with GlassFish 3.1.2 and Oracle 11g as back end. To my surprise, I received the following error when I tried to upload any export sql file:

1 error has occurred

File must be selected to upload. (Go to error)

I first thought that it was a browser issue, so I tried both Google Chrome and Internet Explorer 9, but the error remained. Then I tried to re-export the workspace and applications, maybe the file got corrupt or something. Still, same error… I had a look at the log files of both the APEX listener and the GlassFish instance that APEX was deployed under, but I didn’t see anything wrong.

And then I noticed the following thread on the OTN APEX forum: https://forums.oracle.com/forums/thread.jspa?threadID=2359384. Looks like some other people were also having problems uploading files, and it seemed to be related to the version of GlassFish…

Next, I found this GlassFish bug description: http://java.net/jira/browse/GLASSFISH-18444. They were talking about problems with rich:fileupload and apache file uploads. Bingo! So, I downloaded the modified web-core.jar file, copied it to the modules folder of my GlassFish installation (after renaming the original file) and, after restarting my GlassFish instance, file uploads worked fine again in APEX! Problem solved for now, but luckily this didn’t happen in production!

 

Update 08/2012: this issue has now been fixed in GlassFish 3.1.2.2. See my blog post about this!

 

Matthias

Automatically start GlassFish 3.1.2 on Oracle Linux 6.2 after server reboot

Environment: GlassFish 3.1.2 Open Source Edition (Web Profile), Oracle Linux 6.2

When you installed GlassFish on Oracle Linux, you probably want to make sure that your Domain Administration Server (DAS) and/or any standalone instances that you created are automatically started after a server reboot. You can do this with a shell script which you add as a service under Linux.

The first step is to create a script under /etc/init.d (with user root):

$ vi /etc/init.d/glassfish

#!bin/bash

# description: glassfish start stop restart
# processname: glassfish
# chkconfig: 2345 20 80

GLASSFISH_HOME=/u01/app/glassfish3
GLASSFISH_USER=oracle
RETVAL=0

case "$1" in
start)
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin start-domain domain1"
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin start-local-instance instance1"
;;
stop)
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin stop-local-instance instance1"
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin stop-domain domain1"
;;
restart)
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin restart-local-instance instance1"
su - $GLASSFISH_USER -c "$GLASSFISH_HOME/bin/asadmin restart-domain domain1"
;;
*)
echo $"Usage: $0 {start|stop|restart}"
RETVAL=1
esac
exit $RETVAL

This script will start, stop or restart the DAS with name “domain1” and the local instance with name “instance1” on your Linux server. You should adapt the script for your specific GlassFish instances.

GLASSFISH_HOME is the folder where GlassFish was installed (in my case: /u01/app/glassfish3). GLASSFISH_USER is the name of the user account under which GlassFish is running (in my case: user oracle).

Note: GlassFish needs a JAVA_HOME variable pointing to the folder of your Java binaries. In my case, JAVA_HOME is defined in the .bash_profile of the user “oracle”. You could also add it to the /etc/init.d/glassfish script.

Next, set the correct file permissions on the script:

$ chmod 755 /etc/init.d/glassfish

You can test the script as follows:

$ sh /etc/init.d/glassfish start

Now we need to create a service from the script:

$ chkconfig –add glassfish

This will create a service and start it in the runlevels 2,3,4 and 5. To check this, run the following command:

$ chkconfig|grep glassfish
glassfish 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Let’s check the service:

$ service glassfish stop

Waiting for the instance to stop …
Command stop-local-instance executed successfully.
Waiting for the domain to stop ….
Command stop-domain executed successfully.

Looks ok! The last thing you should test is rebooting your server to see if GlassFish is automatically started after the reboot. Have fun!

Matthias