[
http://jira.jboss.com/jira/browse/JBSEAM-1619?page=comments#action_12368162 ]
Dan Allen commented on JBSEAM-1619:
-----------------------------------
We should probably establish the property glassfish.home early on as it will become useful
for executing commands for adding resources and deploying the exploded directory.
If the .war suffix is removed from the exploded archive, the following command will work
to deploy to Glassfish:
${glassfish.home}/bin/asadmin deploydir $PWD/exploded-archives/project_name
Unfortunately, if the directory has a .war suffix, Glassfish becomes confused and thinks
that it is supposed to be an actual .war file. Fortunately this does not mess up
compatibility with JBoss since the files are still copied into the JBoss deployment
directory in a directory that contains the .war suffix.
The nice part about Glassfish is that no further coping must be done to repeatedly deploy
files.
support for Glassfish in seam-gen
---------------------------------
Key: JBSEAM-1619
URL:
http://jira.jboss.com/jira/browse/JBSEAM-1619
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 2.0.0.BETA1
Environment: Glassfish V2
Reporter: Dan Allen
Attachments: glassfish-datasource.xml
Original Estimate: 1 day
Remaining Estimate: 1 day
I believe that adding support for Glassfish will help promote the adoption of Seam. In my
mind, Tomcat is not nearly as important because it is not a Java EE-compliant environment
and seam-gen is all about creating compliant projects.
Supporting Glassfish is actually quite straightforward. There are a couple of
assumptions that are made by seam-gen that render it incompatible with a generic Java
EE-compliant application server. Here is what needs to change:
1. The java:/ prefix on the data source causes problems with other servers. This can be
easily brought into compliance by adding
<use-java-context>false</use-java-context> to the *-ds.xml files and removing
the java:/ prefix from the persistence-*.xml files in the seam-gen/resources/META-INF
directory
2. Glassfish does not use Hibernate EntityManager as the default JPA provider, and
therefore does not have any of its jar files. Of course, we could just make everyone copy
necessary hibernate jar files into the glassfish installation directory, but that just
isn't going to go over well. I think a better approach is to modify the build.xml
file to copy the following three libraries if the property hibernate.needed=true is set:
hibernate-all.jar
thirdparty-all.jar
jboss-archive-browsing.jar (not currently in the seam distribution, but stuck inside the
jboss-embedded-all.jar file)
3. Make the hibernate.transaction.manager_lookup_class parameterized, perhaps asking
during setup
4. Removing the .war suffix on the exploded archive directory (so that Glassfish can
deploy the directory using asadmin deploydir)
That's it! Then you can have Glassfish working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira