[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1619) support for Glassfish in seam-gen

[Daniel Kimmig (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-1619?page=comments#action_12378302 ] 
            
Daniel Kimmig commented on JBSEAM-1619:
---------------------------------------

I was thinking about requesting a feature concerning seam-gen for a long time. That feature would have been to make seam-gen aware of other containers such as Glassfish and Tomcat.

Although I am happy to see that there is work in progress to decouple seam-gen from JBoss AS, I think it is quite disappointing that you rule out Tomcat like that. Bringing Tomcat to seam-gen would help Seam adoption much more then Glassfish imho, because the biggest concern about Seam adoption is still the environment restriction it emposes. By aggressively showing RAD with seam-gen on a container like Tomcat, much of the "Do i need to use EJB on one of those huge and complicated appservers?"-FUD could be negated.

As Michael Yuan pointed out in his blog ( http://www.michaelyuan.com/blog/2007/07/24/seam-20-and-tomcat/ ), there are two ways to use Seam on Tomcat, either with Embedded JBoss MC or without the MC but restricted to Seam POJOs. If that is the case, why is it so hard to ask the user during seam-setup which container he chooses and if he enters Tomcat, then ask which of these two options should be used.

My concern for this issue relies in the fact that in my company we evaluated Seam and found its features quite nice, especially for a new project that needs JSF components ajaxified with each other. It was great to read about seam-gen, a tool that supposedly should get you started with the project structure and build process. Unfortunately a lot of development effort has been done using Spring/Hibernate on Tomcat during the last years and therefor all of theapplications are hosted on a unique instance of Tomcat. 


I think I am by far not alone with an environment like that. If you want to compete with Spring, you need to be able to live in the same environment that Spring does. This is the only way that you can make developers choose Seam for their next project. Because in real life, no one will port their production applications to a different container/appserver JUST to make the new project executable.


I opened a thread concerning this issue in the Seam forum. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087856#4087856


> 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
>             Fix For: 2.0.0.GA
>
>         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