mardi mai 24, 2011

Intercepting startup and shutdown events

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

Startup and shutdown actions is a pretty common use-case for enterprise development and GlassFish 3.x offers at least two different ways to implement such call-backs: lifecycle modules and EJB 3.1 startup beans.

GlassFish Lifecycle modules

The first one has been around for a little while and is called Lifecycle modules. These are specific to GlassFish and thus not portable to other application servers but they offer a simple and effective way to implement behavior that applies to the entire application server instance (or to an entire cluster), independently of any deployed application.

A single class implementing com.sun.appserv.server.LifecycleListener (available from as-install/glassfish/modules/glassfish-api.jar) can intercept five different events: Initialization, Startup, Ready, Shutdown, and Termination (check the documentation for more details). Here's a canonical example :

public class GlassFishEvents implements com.sun.appserv.server.LifecycleListener {

    private static final Logger logger = Logger.getLogger("");

    public void handleEvent(LifecycleEvent le) throws ServerLifecycleException {
       switch (le.getEventType()) {
          case LifecycleEvent.INIT_EVENT:
          case LifecycleEvent.READY_EVENT:
          case LifecycleEvent.SHUTDOWN_EVENT:
          case LifecycleEvent.STARTUP_EVENT:
          case LifecycleEvent.TERMINATION_EVENT:
             logger.severe("UNKNOWN event");

Registering the lifecycle module can be done via the admin console or the CLI (asadmin create-lifecycle-module) with optional ordering (relative to other modules, similar to servlets), an enabled/disabled state (default is enabled) and the ability to prevent the server from starting if the module fails to load.

Startup and singleton EJB

An alternate way is to use EJB 3.1 (part of Java EE 6) and in particular a bean combining the @Startup and @Singleton annotations. Its lifecycle methods marked with JSR 250 common annotations will contain the event callback logic. Here's a simple example simulation the creation of database tables :

public class CreateTables {
    public void init() {
       logger.warning("Creating tables");

    public void cleanup() {
       logger.warning("Dropping table...");

While this offers a more portable solution, it has some notable differences with GlassFish lifecycle modules.

First of all there are only two events that can be intercepted: @PostConstruct, @PreDestroy which are application events, not runtime system events. Undeploying the application is also the only way to disable the behavior and since this is an application-level event interception, there cannot be action taken on other parts of the runtime on failure (arguably you can do a lot more in the rest of you application).

Finally there is no notion of ordering but rather you can express explicit dependencies using @DependsOn as shown here to simulate populating tables that need to be previously created :

public class PopulateTables {
    public void init() {
       logger.warning("Populating tables");

    public void cleanup() {
       logger.warning("archiving table data");

Also note that a Singleton approach only applies to a single instance (not a cluster-wide singleton). If you're wondering which approach to chose, it really boils down to whether you want to implement system-level or application-level events.

Of course you can combine the two approaches which would trigger a log similar to this one on a startup/shutdown cycle :

WARNING: Creating tables
WARNING: Populating tables
WARNING: archiving table data
WARNING: Dropping table...

jeudi sept. 17, 2009

GlassFish tip: customize directory listings

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

With GlassFish being a very capable HTTP server out of the bowser (thank you Grizzly!), it was time for v3 to offer the ability to configure directory listings. It is now possible to have pages listing files per NAME (default), SIZE, or LAST_MODIFIED.

Configuration can be done inside web.xml (in the form of an additional init-param to the DefaultServlet servlet called sortedBy). This would hold true for a given application and support dynamic reloading (no full redeploy, no restart to take changes into account).

You might find it more convenient to have it be part of default-web.xml (located in domains/domain1/config/). Of course that would require restarting the container. In both cases, the listing should be explicitly allowed or else the user will see a 404 Not Found error. Here's an example to configure the listing presentation in either config files :



Of course there's also the XSLT approach to have yet more control over the presentation. Check the use of localXsltFile and globalXsltFile in the default-web.xml file itself.

mardi déc. 16, 2008

GlassFish tips on Java HowTo blog

It may well be old news to some, but the JavaHowTo blog has some nice tips on using GlassFish.
Recent ones include :
"How to create jdbc connection pool and DataSource in GlassFish"
"Disable NetBeans httpmonitor in GlassFish" (yes, that's pretty annoying)

More tips on GlassFish can be found here.

mardi nov. 27, 2007

GlassFish tip - Change the admin console timeout value

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

The default timeout value for the Web Admin Console of GlassFish v2 is set to 60 minutes by default.
If you want to change this (some people find it annoying to be disconnect too often and other find one hour to be too long), you can either emit this asadmin command:

% asadmin set server.admin-service.das-config.admin-session-timeout-in-minutes= ...

...or modify the value of <das-config admin-session-timeout-in-minutes="60" ... in the domain.xml config file (editing XML by hand isn't a really good idea).
Make sure you restart your browser for this to take effect (thanks Kedar).
The documentation for this feature is here.

Previous GlassFish tips are here.

vendredi août 31, 2007

GlassFish tip: Broken or Corrupted domain.xml

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

domain.xml (located in GLASSFISH_INSTALL/domain/DOMAIN_NAME/config) is a key configuration file in GlassFish and it should never be edited by hand. So now that I've said this, I'd be lying if I said I never did this myself. And yes I've had times when my config file was corrupted which would prevent GlassFish from starting. If you end up with a corrupted domain.xml file \*without\* editing it by hand (never happened to me), you have one thing to do: file a bug with steps to reproduce.

If for some reason domain.xml is indeed corrupted (malformed XML or not compliant to the associated DTD), here are a few things you can do before or after the corruption:

• run the following command to verify the correctness of the file :
%asadamin verify-domain-xml

• restore the entire domain :
%asadmin restore-domain
...if you had previously backed it up :
asadmin backup-domain

• if you're happy losing all domain configuration (deployed applications, JDBC resources, JVM options, ...) or desperately want to get back to a working domain, you can create a new one :
%asadmin create-domain domain-name

...or recreate default domain1 by first deleting it :
%asadmin delete-domain domain1
and running the setup script again from the root directory (GlassFish 2.x only) :
ant -f setup.xml

You can also try to fix the content of this config file with a smart XML editor providing code completion, color syntaxing and well-formeness verification based on its DTD. If you're using NetBeans, go to "DTDs and XML Schema Catalogs". If you're using GlassFish 3 and above, you probably want to read why there is no longer a DTD/Schema.

jeudi août 30, 2007

GlassFish tip - Have your application be the root application

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

I've had the question several times about how to install a web application at the root of GlassFish (the use-case being probably to put into production an application on an intranet). Well, as discussed here it's as simple as deploying your application with a "/" web context which can be done using the web Admin console (set the "Context Root:" field to "/") or the command line :

% asadmin deploy --contextroot "/" your-webapp.war

or making sure the sun-web.xml deployment descriptor contains a context-root element set to /.

The alternate solution is to use the notion of default web module for a given virtual server just like the web admin console is the default for port 4848.

Change the HTTP listen port to default 80 (with appropriate privileges on Unix) and you're off to the simplest possible URL for your users.

jeudi août 02, 2007

What is a GlassFish master password anyway?

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

If you came here looking for the default password for the GlassFish admin console, it's "adminadmin" (although with GlassFish 3 and above the introduction of a default anonymous user now means you should no longer be prompted for user/password). If the master password is what you're looking for, then read on.

With GlassFish v2 (SJS Application Server 9.1) soon to be released in final version, people are starting to move from the development phase to the production planning phase. This means that they are often moving from the "developer" profile to the "cluster" or "enterprise" profiles. One of the questions I often hear is "what is a master password anyway"? Here are a few hints gathered from talking to customers experiencing the use of a more secure and clustered environments (thanks to Sreeni and Kedar for some of these):

What is an Domain? What is a cluster? What is an Domain Admin Server (DAS)? What is a Node Agent (NA)? What is a repository?
These links explain it in best detail: and See also this picture.

What is a master password?
First you shouldn't need it in the "developer" profile. Otherwise, straight from the documentation: "The master password (MP) is an overall shared password. It is never used for authentication and is never transmitted over the network.". The master password is also the password for the secure keystore (NSS in the case of an "Enterprise" profile, KJS otherwise).

What is the default master password?
"changeit" (not "adminadmin")

What is the "default" profile?
$INSTALL-DIR/config/asadminenv.conf contains the default profile used during installation (the one used by the "asadmin create-domain" command).

One can upgrade from a "developer" to a "cluster" profile on the fly. Can I move back to a "developer" profile?
It's not supported but the only file touched during the upgrade is domain.xml, so restoring the original file should work.

Why would I need an "Enterprise" profile rather than the "Cluster" profile?
The "Enterprise" profile is when you need HADB (the distributed Highly-Available DataBase) and/or an NSS keystore.

Is it necessary to start the node before starting the domain ?
No, but whenever the Node Agent (NA) is started for the first time, it tries to bind with Domain Admin Server (DAS). The usual sequence is to start DAS and then NA. If the DAS is not running at the time node agent is started, it knows that it is yet to bind with DAS and it does so whenever the DAS comes up later.

lundi mai 21, 2007

GlassFish tips for demoers and others (avoid those restarts)

One of the good things about having your environment change is that it makes you ask yourself the question of why you ended up with some habits. NetBeans 6.0 Milestone 9 not bundling Tomcat by default (but still supporting it) is one such example I think. On that note I'd invite you to read Geertjan's post on Oddly Shaped Bicycles.

So the above thread got the discussion going about NetBeans experiences with people using GlassFish as part of their demos whether it is to demo Java EE 5 features, deploy and run OpenESB artifacts, run OpenPortal, an interoperable JAX-WS Web Service, or a JRuby on Rails application, a whole lot of people use GlassFish nowadays. Whether using Tomcat or GlassFish a seamless experience can be achieved with fast startups or incremental deployments.

Startup time for GlassFish is not perfect (we're working on it) but very good for a full-blown application server. Luckily, incremental deployment is most often extremely fast and, if no restart is required which makes the life of demoers but also pretty much everyone else's so much more enjoyable (having an unplanned application server restart during a demo is never good).

So here's a little list of do's and dont's when using GlassFish in demos (not your typical use-case but still...). If this looks too long, skip to the last bullet.

 &bull Use GlassFish v2. First of all if you're using GlassFish v1, this version was pretty much frozen more than a year ago. GlassFish v2 has much better startup time, better error handling, and less restarts (almost everything in the web container is now dynamic). GlassFish v2 is now in beta 2, so if you're using a NetBeans milestone, you really shouldn't be afraid to use a GlassFish beta! :)

 &bull Delete does not undeploy. One of the most annoying problem reported is application server restarts. With GlassFish v1, this clearly happens when there is a mismatch between you domain.xml (in domains/domain1/) and the file system and this is most likely due to deleting projects from NetBeans (after you're done with the previous demo) and not undeploying them (I filed this RFE).

 &bull Undeploy only works on existing projets. When using the web UI to undeploy non-existing applications, you get a (what could be a bit friendlier) error/exception. All it says it that it couldn't find the application (most likely a DPL5040). When using the GlassFish web UI, make sure you pay attention to the upper right corner which will tell you ("Restart Required") a restart is needed (and subsequent deployments from NetBeans will trigger a restart if you don't do it yourself before).

 &bull Hand cleaning. If you don't want to start the AS to clean older applications to then restart it, you can always be careful and remove the appropriate entries in domain.xml (not sure I should be suggesting this). Only make sure you keep an backup of domain.xml and run a asadmin verify-domain-xml to make sure you have a valid config file.

 &bull Clean, then restart. Always (re)start your application server before the demo only after any conflicts between domain.xml and the filesystem have been resolved (see above).

 &bull Clean or remove the log file. When Starting GlassFish from NetBeans, the log file of the application server is shown in the IDE. If it's big it'll take (what can seem) forever to 'cat' thru before actually showing the start-up sequence. You should probably delete the glassfish logfile (domains/domain/logs/server.log) or have the log file rotate with on a small size (a few hundred Kb).

 &bull Restart from scratch? I've you want to be really extra safe, you can re-create the domain using:
% asadmin delete-domain domain_name
% asadmin create-domain domain_name
(be careful, this creates a brand new domain with no resources other than the default ones)

 &bull Backup/Restore! Probably a better alternative (one that could make most of the above obsolete) is to do domain backup/restore:
% asadmin backup-domain domain_name
% asadmin restore-domain [--filename backup_file] domain_name
(make sure the domain is stopped and in the desired stable state when creating the backup).

If you have reproducible use-cases of an annoying/unneeded application server restart with GlassFish v2, please report it (bug, or comment here).
Feel free to suggest tips. I'm sure I'm missing a few.

vendredi janv. 12, 2007

GlassFish tip: verbose glassfish

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

I love the GlassFish log viewer (and more generally the Web Console) as well as the NetBeans integration, but in development mode, looking for application System.out's can be challenging.
So I often use this :

asadmin start-domain --verbose

Documentation for this supported feature is here.
Btw, it seems like this is the only way to have certain JVM options such as -verbose:gc (although using JConsole may be a better choice) defined in domain.xml to show up at all.


This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« juillet 2016

No bookmarks in folder


No bookmarks in folder