jeudi janv. 21, 2010

My first reaction when I started to help Paul and the team run and test Bill Burke's ex11_1 sample on GlassFish v3 was that this code could be refactored to be much simpler and more portable with Java EE 6 and JAX-RS 1.1. This wasn't the best approach to show the portability of existing JAX-RS code so the porting happened with minimal (really small) changes. Yet, I wanted to share the simplifications here.

Remove web.xml altogether. The Jersey servlet no longer needs to be declared and mapped, and the EJB local references now have well known and portable names. This is replaced with a @ApplicationPath("mypath") annotation placed on the ShoppingApplication class.

Put those EJBs in a WAR. The initial project has three artifacts: WAR, EJB jar, and a global EAR, each having a separate Maven pom.xml. This can all be boiled down to a single WAR file.

Morph resources and Beans into a single class. The dichotomy between \*Resource and \*ResourceBean is no longer necessary. A resource can simply now be a transactional EJB by adding the @Stateless along side the @Path annotation.

Test. This is made easy by the simplified packaging but essentially is the same as what's described here (uses the GlassFish Maven plugin).

The end-result has 60% less lines of code (and I'm sure you could get even remove more without hurting the code).
These are all simplifications made possible by Servlet 3.0, EJB 3.1 and JAX-RS 1.1 (all part of Java EE 6).

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.

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