GlassFish Tip: log asadmin commands

I don’t think I’ve seen this tip mentioned before in blogs or documentation and yet have had the request from different users and customers.
If you want to log all the asadmin commands, simply set the AS_LOGFILE environment variable to the name of a file.

% export AS_LOGFILE=/tmp/asadmin.log
% asadmin ...
% cat /tmp/asadmin.log
12/23/2010 14:31:33 EXIT: 0 asadmin list-domains
12/23/2010 14:32:39 EXIT: 1 asadmin start-domain
12/23/2010 14:33:27 EXIT: 0 asadmin start-domain
12/23/2010 14:33:58 EXIT: 0 asadmin list-domains
12/23/2010 14:34:04 EXIT: 0 asadmin list-applications
12/23/2010 14:34:21 EXIT: 0 asadmin undeploy org.beginningee6.tutorial_demo11_war_1.0
12/23/2010 14:38:13 EXIT: 0 asadmin stop-domain
12/23/2010 14:38:46 EXIT: 1 asadmin start-domain
12/23/2010 14:41:00 EXIT: 0 asadmin --verbose start-domain domain1
12/23/2010 14:41:58 EXIT: 0 asadmin get servers.\*
12/23/2010 14:42:14 EXIT: 0 asadmin get servers.server.server.resource-ref.jdbc/__TimerPool.enabled
12/23/2010 14:44:37 EXIT: 0 asadmin deploy ../../HelloHK2bis.war

If you think this should be the default behavior, file an issue (with “3.2” as the “Fix Version”). I’ll vote for it!

If you’re trying to troubleshoot asadmin (or simply curious) you can set export AS_DEBUG=true to obtain a chatty output.

GlassFish tip: customize directory listings

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.

More with “deploy –libraries” in GlassFish

A few months back Sahoo mentioned the use of "asadmin deploy --libraries" in the comments section as an effective way to deal with libraries. I recently had two people ask me about the behavior of GlassFish when multiple applications are deployed with --libraries pointing to the set jar file so I thought I’d share here what I found (this is for GlassFish v2.x). Thanks to Siva and Hong for the help there.

When multiple applications have --libraries pointing to the same jar, the classloading infrastructure tries to “share” the jar by loading it in the same classloader.

A side effect of this is that modifications to the jar require the undeployment and deployment of the application (along with its --libraries option) for it to use the updated version of the library. A simple deployment will trigger a ClassNotFoundException.

Note that it is your responsibility to keep track of all the applications using a given library and to do an undeploy/deploy for all of them as you may otherwise end up having different applications using different versions of the library.

The other option, which doesn’t require the keep track of the applications using a given library, is to update the library bits and simply restart the server. Of course that has other drawbacks…

I’m moving from the (NetBeans) GlassFish development server to a production server and my application won’t run! Help!

I’ve recently seen a flurry of people moving to production GlassFish servers coming from a NetBeans development environment so I thought I’d write down in this post what I’ve been replying on the various mailing lists and forums.

NetBeans auto-magically creates all the resources required in the GlassFish runtime (JNDI resources, connexion pools, and other configuration), so directly deploying an application (.war, .ear artifacts) in a newly-installed GlassFish instance will most likely fail because the resources the application replies on are not present. To fix this you have several options:

1/ add the remote production GlassFish server to the list of NetBeans servers. The trick is that you first need to point NetBeans to a local install and later describe the remote server with IP and Port number.

2/ use the GLASSFISH_HOME/bin/asupgrade tool to inject all the applications/resources/configuration from a source to the production target. Note this tool can work across multiple version of GlassFish and migrates things like security stores, virtual servers, etc… If using strictly the same bits (same version of GlassFish) in development and production, you could also probably use GLASSFISH_HOME/bin/asadmin backup-domain and the GLASSFISH_HOME/bin/asadmin restore-domain commands.

3/ re-create all the resources using either the CLI (asadmin) or the GUI (http://localhost:4848). For Make sure you can ping the database when creating connection pools.

% bin/asadmin create-jdbc
Closest matching command(s):

All of this (deployed applications, JNDI resources, virtual hosts, and configuration) is stored in GLASSFISH_HOME/domains/domain1/conf/domain.xml. You shouldn’t edit this by hand but it may be useful for troubleshooting and diff’ing the development and production environments..

Update : Peter Williams suggests a fourth way using sun-resources.xml .

GlassFish tip – Change the admin console timeout value

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.

GlassFish tip: Broken or Corrupted domain.xml

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 :
% asadmin 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.

GlassFish tip – Have your application be the root application

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, it’s really 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.

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.

  • 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! :)

  • 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).

  • 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).

  • 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.

  • 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).

  • 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).

  • 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)

  • 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.

GlassFish tip: verbose glassfish

I love the GlassFish graphical 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.