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): create-jdbc-connection-pool create-jdbc-resource
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