Details

    • Type: Feature Request Feature Request
    • Status: Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 2.0.0.BETA1
    • Fix Version/s: 2.1.2.CR1
    • Component/s: Tools
    • Labels:
      None
    • Environment:
      Glassfish V2
    • Affects:
      Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration
    • Estimated Difficulty:
      Medium
    • Similar Issues:
      Show 10 results 

      Description

      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.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Dan Allen added a comment -

            Aside from one naming issue, this is really just a packaging issue. It's just a matter of having build.xml include targets that package it properly for a different server. I don't really see how that affects jbosstools, but I could be lacking the understanding.

            The biggest issue is the java:/ prefix on the datasource. JBoss is the only appserver that seems to understand this notation. To avoid having to modify the persistence.xml file for different environments, I propose that we use the standard JNDI naming (something like jdbc/datasource). This can be enabled in the -ds.xml file by using <use-java-context>false</use-java-context>.

            Show
            Dan Allen added a comment - Aside from one naming issue, this is really just a packaging issue. It's just a matter of having build.xml include targets that package it properly for a different server. I don't really see how that affects jbosstools, but I could be lacking the understanding. The biggest issue is the java:/ prefix on the datasource. JBoss is the only appserver that seems to understand this notation. To avoid having to modify the persistence.xml file for different environments, I propose that we use the standard JNDI naming (something like jdbc/datasource). This can be enabled in the -ds.xml file by using <use-java-context>false</use-java-context>.
            Hide
            Max Rydahl Andersen added a comment -

            if it purely changes in the build.xml then probably i'm fine...but if it changes where things are supposed to go or different set of jars etc. we should at least do it in a way so it is possible for us to reuse the set of libraries and where thing goes.

            the naming issue will be relevant if it changes the way templates will be processed and how things run in the embedded container.

            Show
            Max Rydahl Andersen added a comment - if it purely changes in the build.xml then probably i'm fine...but if it changes where things are supposed to go or different set of jars etc. we should at least do it in a way so it is possible for us to reuse the set of libraries and where thing goes. the naming issue will be relevant if it changes the way templates will be processed and how things run in the embedded container.
            Hide
            Samuel Doyle added a comment -

            There is a lot of noise on this subject and I believe Dan is correct in that adding GlassFish support will increase the adoption rate of Seam.

            Show
            Samuel Doyle added a comment - There is a lot of noise on this subject and I believe Dan is correct in that adding GlassFish support will increase the adoption rate of Seam.
            Hide
            Dan Allen added a comment -

            Fixed. The only change that was made to the shared templates is that I renamed Authenticator to AuthenticatorJavaBean, make Authenticator a @Local interface, and introduced the @Stateless bean AuthenticatorBean. So the generator for WAR projects has to copy AuthentictorJavaBean to Authenticator.java

            Please see the following entries documenting the progression for how I implemented it this support.

            http://www.mojavelinux.com/blog/archives/2008/10/deploying_a_seamgen_project_to_glassfish/
            http://code.google.com/p/seaminaction/wiki/DeployingToGlassFish
            http://in.relation.to/Bloggers/JBossAS5AndGlassFishSupportAddedToSeamgen

            Show
            Dan Allen added a comment - Fixed. The only change that was made to the shared templates is that I renamed Authenticator to AuthenticatorJavaBean, make Authenticator a @Local interface, and introduced the @Stateless bean AuthenticatorBean. So the generator for WAR projects has to copy AuthentictorJavaBean to Authenticator.java Please see the following entries documenting the progression for how I implemented it this support. http://www.mojavelinux.com/blog/archives/2008/10/deploying_a_seamgen_project_to_glassfish/ http://code.google.com/p/seaminaction/wiki/DeployingToGlassFish http://in.relation.to/Bloggers/JBossAS5AndGlassFishSupportAddedToSeamgen
            Hide
            Dan Allen added a comment -

            Ignore the comment about Authenticator.java. I restored the previous template so that it doesn't break JBoss Tools. I just use new file names for the @Stateless and @Local classes (AuthenticatorLocal.java and AuthenticatorBean.java).

            Show
            Dan Allen added a comment - Ignore the comment about Authenticator.java. I restored the previous template so that it doesn't break JBoss Tools. I just use new file names for the @Stateless and @Local classes (AuthenticatorLocal.java and AuthenticatorBean.java).

              People

              • Assignee:
                Dan Allen
                Reporter:
                Dan Allen
              • Votes:
                11 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 day
                  1d
                  Remaining:
                  Remaining Estimate - 1 day
                  1d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                    Development