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.
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
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
globalXsltFile in the
default-web.xml file itself.
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
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…
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
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
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 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.
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.