Testing seam-gen in Seam 2.1.2-SNAPSHOT with GlassFish v2

On March 15 I read on The Aquarium that JBoss’ Dan Allen added JBoss AS 5 and GlassFish support to seam-gen. I had the pleasure to have met with Dan Allen at Devoxx 2008 (we hosted a BOFF on GlassFish and Seam) and there he already mentioned thinking about adding support for GlassFish to seam-gen. Tonight I downloaded Seam 2.1.2-SNAPSHOT and tried out the GlassFish support in seam-gen that Dan recently added.

My goal for this test was to find out how seam-gen can be used to generate the kind projects AMIS usually develops: web based applications that use an Oracle database underneath. Only now I would like to generate a project that can be deployed to GlassFish. So, I started seam-gen:

$ ./seam-gen

First check: specifying the GlassFish install directory

Call me hasty, a bad reader, impatient or just out of luck, but having read Dans blog article I had the impression that I could specify the GlassFish install directory in the questionaire presented by seam-gen. However, I was a bit disappointed to find out that I still need to provide a JBoss AS install dir. Reading Dans blog article more carefully provided me with the info I missed the first time: “As before, the seam-gen project build supports JBoss AS by default” … “All of the targets that pertain to GlassFish reside in the file glassfish-build.xml at the root of the project”.OK, so I have to specify a JBoss AS home at seam-gen time and the I’ll be able to deploy to GlassFish once I am done generating? That’s definately cool and enough for me!

Next check: hibernate-gen

One of the first things I checked was if a nasty bug in hibernate-gen is still there. In the process of setting up your project, seam-gen uses hibernate-gen: the Hibernate generation tool that generates Entity classes based on database connection parameters. The older version I used a few months ago didn’t handle Oracle database schemas well. Instead of only generating Entity classes for the schema of the provided database user, it would scan the entire database and attempt to generate Entity classes for all database tables and views that it encountered. The workaround for it was to specify hibernate.default_schema in hibernate-console.properties and then generate the Entity classes.

Fortunately, even without specifying this parameter hibernate now does a great job. It simply scans the database schema for the provided user and that’s it. Excellent!

Managing GlassFish from within ant

As can be read in glassfish-readme.txt in the project home, GlassFish can be started, restarted and stopped using ant. Also, deploying, redeploying and undeploying projects and datasource definitions all can be done with ant. Pretty neat Dan! Unfortunately I am not a very exprienced ant user, so it took a while before I found out I had to specify the glassfish.home directory in the build.properties file. Once I did, I could start and stop GlassFish without any problems.

Despite the little annoyances described above so far I was *VERY* much impressed with the excellent job that seam-gen does! Remember: this is SNAPSHOT software and so far it has done a really great job! No crashes, no exceptions, no stack traces but only comprehensive messages on my screen whenever something wasn’t configuered correctly. So, here’s:

The final test: deploying my project to GlassFish

A project that uses JPA should, by GlassFish terms, be deployed as an EAR. However, by Seam standards it’s perfectly ok to deploy it as a WAR file. So, I followed the Seam standards and tried for the WAS option. Here I ran into a few problems.

Let me start by describing my efforts to deploy an exploded archive: this goes without any problems whatsoever! The ant script totally kicks ass at this task. It doesn’t need to first create an exploded archive (task: gf-stage) or deploy a datasource (task: gf-gf-deploy-datasource). If it needs to, it will do it by itself!

However, deploying a WAR file gave me quite a headache. The first error I encountered was

Deployment Error -- Could not resolve a persistence unit corresponding to the persistence-unit-ref-name [SeamGenTest/pu] in scope of the module called
[.../glassfish-v2ur2/domains/domain1/applications/j2ee-modules/SeamGenTest]. Please verify your application.

As it turns out, the build.xml script removes the persistence.xml file in case of a WAR file. However, deploying an exploded WAR goes fine, so it *HAS* a persistence.xml file. This seems inconsistent to me.

Apart from that I had to replace these variables in resources/WEB-INF/component.xml

@debug@
@jndiPattern@
@seamEmfRef@

with the values I found in the components.xml file in the exploded war directory. It looks like ant doesn’t succesfully replace these placeholders with their correct values. Once I did that, the WAR would deploy without any problems.

Conclusion

GlassFish support for seam-gen is getting there and looking very, very promising. A great big thanks to Dan Allen for working on this! I will send him my comments and I hope he will be able to resolve the issues I mentioned here.