GlassFish in Production

Last week I noted how to install and configure GlassFish on your development machine. In a production environment, your needs and setup are a bit different. So here are my suggestions on how to deploy GlassFish in production. If you have better ideas or experiences, please share them and I'll update the entry.

Step 1: Install GlassFish

bleonard@opensolaris:~$ pfexec pkg install glassfishv2
PHASE                                          ITEMS
Indexing Packages                            554/554 
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  12/12   6363/6363 142.44/142.44 

PHASE                                        ACTIONS
Install Phase                              7404/7404 
Reading Existing Index                           9/9 
Indexing Packages                              12/12  

Assuming you are going to run GlassFish using its cluster profile, you also need to install the SUNWjdmk-base package:

bleonard@opensolaris:$ pfexec pkg install SUNWjdmk-base
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1         3/3     1.09/1.09

PHASE                                        ACTIONS
Install Phase                                  10/10
PHASE                                          ITEMS
Reading Existing Index                           9/9
Indexing Packages                                1/1

There are still a few more hoops you need to jump through in order to get GlassFish to recognize the JDMK libraries. The SUNWjdmk-base package installs them into /usr/share/lib/jdmk. However, GlassFish looks for them in /opt/SUNWjdmk/5.1/lib. The easiest way to fix this is to add a link in /opt:

pfexec mkdir /opt/SUNWjdmk
pfexec mkdir /opt/SUNWjdmk/5.1
pfexec ln -s /usr/share/lib/jdmk /opt/SUNWjdmk/5.1/lib 

Step 2: Create a User to Mange the Server

The application server stores configuration information in the user's home directory, therefore we need an actual user account (instead of just a role). I'm going to create a user and group called appservr. Users on the system can then switch to the appservr user to administer the server.

bleonard@opensolaris:$ pfexec groupadd appservr
bleonard@opensolaris:$ pfexec useradd -g appservr -b /export/home -c "Application Server Administrator" -m appservr
80 blocks

bleonard@opensolaris:$ pfexec passwd appservr New Password: Re-enter new Password: passwd: password successfully changed for appserv

Step 3:  Create the Domains Directory

GlassFish will create its domains in the /var directory. You can change the location in the /usr/appserver/config/asenv.conf file. But assuming you want to leave it set to /var, we need to create a directory writable by the appservr user:

bleonard@opensolaris:$ pfexec mkdir /var/appserver
bleonard@opensolaris:$ pfexec chown appservr:appservr /var/appserver/

Step 4: Create and Start the Domain

Now you should be able to turn control of managing the application server to any other user on the system - they would simply need to switch to the appservr user:

bleonard@opensolaris:~$ su appservr
Sun Microsystems Inc.    SunOS 5.11    snv_101b    November 2008

Then they're free to administer the server - create domains, etc...

$ asadmin create-domain --user admin --adminport 4848 --profile cluster domain1
Please enter the admin password>
Please enter the admin password again>
Please enter the master password [Enter to accept the default]:>
Please enter the master password again [Enter to accept the default]:>
Using port 4848 for Admin.
Using default port 8080 for HTTP Instance.
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using default port 8181 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Using default port 8686 for JMX_ADMIN.
Domain being created with profile:cluster, as specified on command line or environment.
Security Store uses: JKS
Domain domain1 created.
$ asadmin start-domain --user admin domain1
Starting Domain domain1, please wait.
Log redirected to /var/appserver/domains/domain1/logs/server.log.
Please enter the admin password>
Redirecting output to /var/appserver/domains/domain1/logs/server.log
Domain domain1 started.
Domain [domain1] is running [Sun Java System Application Server 9.1_01 (build b09d-fcs)] with its configuration and logs at: [/var/appserver/domains].
Admin Console is available at [http://localhost:4848].
Use the same port [4848] for "asadmin" commands.
User web applications are available at these URLs:
[http://localhost:8080 https://localhost:8181 ].
Following web-contexts are available:
[/web1  /__wstx-services ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://opensolaris:8686/jmxrmi] for domain management purposes.
Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ].
Domain supports application server clusters and other standalone instances.

Step 5: Creating a SMF Service for the Domain

This step is optional but makes administering the server much nicer. It can be performed by the root user, or you can assign the necessary privileges to the appservr user. Assuming the latter case, the additional steps you need take are well documented in the asadmin create-service help file:

$ asadmin create-service --help

First you will note: "To run this command, you must have solaris.smf.\* authorization." The solaris.smf.\* authorizations are included with the "Service Management" profile. So to assign these privileges to the appserv user:

bleonard@opensolaris:~$ pfexec usermod -P "Service Management" appservr

Or if you decide that you only want the appservr user to be able to enable and disable the service, assign them the "Service Operator" profile instead:

bleonard@opensolaris:~$ pfexec usermod -P "Service Operator" appservr

The help for asadmin create-service also states the following: "It is also essential for the users to have write permission in the directory tree: /var/svc/manifest/application/SUNWappserver."

So let's do that too:

bleonard@opensolaris:~$ pfexec mkdir /var/svc/manifest/application/SUNWappserver
bleonard@opensolaris:~$ pfexec chown appservr:appservr /var/svc/manifest/application/SUNWappserver

Now you can log back in as appservr and create the service. Before doing so we need to store the password information in a file. I created a file called appservr_password.txt in appservr's home directory containing the following:


Modify the file as follows so only the appservr user can read its contents:

$ chmod 600 appservr_password.txt

Then run the asadmin create-service command as follows:

$ pfexec asadmin create-service --type das --passwordfile appservr_password.txt /var/appserver/domains/domain1/

Now the appservr user can start the domain using:

$ svcadm enable domain1

And I think that should pretty much cover it. Let me know if I've overlooked anything.


This is excellent, thanks! You should link to it from the GlassFish wiki.

Posted by Ryan de Laplante on February 19, 2009 at 03:11 PM GMT #

These Glassfish howtos are Great! Thank you for posting them.

Posted by marty on February 20, 2009 at 11:46 AM GMT #

Thanks, that's really useful. Are you sure you need to chown the smf directories? I'd expect 'pfexec asadmin create-service' to grant you enough privileges to install the manifests etc.

Posted by Dick Davies on February 22, 2009 at 12:28 AM GMT #

I too was hoping that by adding the "Service Management" profile to the "appservr" account, that it would gain write permissions to the SMF directories, but unfortunately, that's not the case.

Posted by Brian Leonard on February 23, 2009 at 07:09 AM GMT #

I used this quite effectively and I really appreciate your efforts. It has saved me a lot of time and effort.

I think the usermod -P commands must not be quite right because on my system, OpenSolaris, I still had to create the service as root.

I think the last command is svcadm enable domain1.

Thanks for your good work.

Posted by Ivan S Kirkpatrick on February 28, 2009 at 01:05 AM GMT #

Hi Brian,

thanks a lot for this very helpful blog entry.
I found two small glitches:

1.) Typo in Step 1: it should be "pfexec mkdir /opt/SUNWjdmk" instead of "pfexec mkdir /opt/SUNWjmdk" (notice jdmk instead of jmdk).

2.) Step 5: as Ivan already mentioned, in the last step it should be "svcadm enable domain1" instead of "svcs enable domain1".

Keep up the great work!

Posted by Jan Lagerpusch on April 06, 2009 at 12:57 AM GMT #

Hi again,

I would like to find out about the proper way to update GF (to 2.1.1-b60) on OpenSolaris. Starting out from a "default LiveCD" installation, I am trying to find out what is the best way to do so. It seems there are two options:

1.) Use the package Manager to install "glassfishv2" (incl. all dependencies). However, the version installed is "2.01-b09", so updating the version to 2.1.1-b60 is required.

2.) Do a completely manual installation of GF 2.1.1-b60 (downloading the .jar, downloading & installing all the dependencies, etc.) - this seems rather tedious to me. Also, the SMF functionality seems to be missing this way.

While I find #1 a lot easier, I am wondering why essential tools like the "update center" are missing after installation. Is there a way to install GF with all the usual tools using OpenSolaris package Manager?

Also, what would be the correct steps to update to b60 afterwards? What I tried is:
1.) downloading the .jar
2.) installing it
3.) disabling the service via SMF
3.) moving folders / symlinks around
4.) go through the asupgrade procedure to reuse installed domains
5.) enabling the service via SMF

Any help on how to do this "the right way" (i. e. as it is supposed to work on OpenSolaris) would be greatly appreciated.

Thanks in advance,
Jan Lagerpusch

Posted by Jan Lagerpusch on April 06, 2009 at 04:39 AM GMT #

Ivan/Jan, I've corrected the typos - thanks!

Jan, let me chew on your upgrade question a bit and get back to you.


Posted by William Leonard on April 08, 2009 at 11:00 AM GMT #

Hi Brian,

thanks for the information - would be great to hear from you reg. the upgrade question.

Btw: who is William? :-)

Best regards,

Posted by Jan Lagerpusch on April 08, 2009 at 11:49 PM GMT #

My full name is William Brian Leonard, but I've always been called by my middle name Brian. Sometimes William slips in there though :-).

I'm still chasing the update question.


Posted by William Leonard on April 09, 2009 at 06:11 AM GMT #

It would be much better to add an ACL allowing your user to operate within the application server filesystem hierarchy:
chmod -R A+user:appserv:rx:allow /var/svc/manifest/application/SUNWappserver

Posted by Damian Wojsław on August 27, 2009 at 01:01 PM GMT #

Uhm. sorry for "-R", I had directory in mind and then forgot to change it. My bad for pasting shell history. :)

Posted by Damian Wojsław on August 27, 2009 at 01:03 PM GMT #

Hi Brian,

It seems I can access glassfish from the PC itself, but not from the nearest network ( still the same subnet ).

AFAIK, OSOL2009.06 has no IP Filter running by default

FYI, I execute the ./asadmin start-domain domain1
using my user account, not root, and not 'appserv' user like your example.

Perhaps I am missing something.
Please let me know.

Thank you,


Posted by Handojo on October 15, 2010 at 09:45 AM GMT #

Hi Handojo,

So you can ping the machine? SSH into the machine? If you install Apache (SUNWapch22) and start it (svcadm enable apache22), can you reach it remotely (port 80)?


Posted by W Brian Leonard on October 15, 2010 at 10:33 AM GMT #

Yes I can ping the machine

Yes I can ssh the machine

I havent install SUNWapch22 so i can't start it.

But, I am running my glassfish only until Step 4 according to your tutorial. I did not run Step 5.

Is the Port not really open or being block unless we wrap glassfish under svcadm ? This is my first guessing as I do not find this behavior on Fedora

I can ssh and i can see that service ssh is running using svcs

Posted by Handojo on October 16, 2010 at 07:09 AM GMT #

Sorry, Brian,

I said I run my glassfish only until Step 4, but I skipped the creation of user "appservr"

Having performed completely from Step 1 to Step 5, I can browse the main glassfish from the same network. I will have to see if I can browse this from outside network.

It seems there is a mechanism here in Solaris, that, if a user runs a process that listens to TCP/UDP ports without using SMF, then only that user/session can connect to that TCP/UDP ports

If the user wants to publish the process to everyone, he must use SMF to publish that process ( as a service ).

This is new to me as the behavior does not exist in Fedora

Posted by Handojo on October 16, 2010 at 09:23 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.


« August 2016