[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1449) Change the "glassfish" example to "jee5" and include oc4j11 support

[ http://jira.jboss.com/jira/browse/JBSEAM-1449?page=comments#action_12366356 ] Michael Yuan commented on JBSEAM-1449: -------------------------------------- Thanks Pete for taking over this! Please see the message from Sun below to make the example more JEE5 compliant. It mostly concerns using the correct XML name space and using the JEE5 library-directory to package the EAR. I think this will also help on OC4J. On 6/20/07, Tim Quinn <Timothy.Quinn(a)sun.com&gt; wrote: Hi, Gavin and Thomas. Roger Kitain suggested I contact you about this. Please point me to the right people if appropriate. I work on the GlassFish engineering team. In looking at the Seam booking example for GlassFish for another reason I noticed some things I wanted to call to your attention and get your feedback on. 1. The packaging of the EAR identifies a <java> module jboss-seam.jar. The Java EE 5 spec calls for a module so marked to be an application client. Is that what jboss-seam.jar is? Normally the manifest for an app client JAR specifies the Main-Class for the app client, which that one does not. Or is that actually intended to be a library JAR? 2. There are a number of JARs packaged at the top level of the EAR. In GlassFish today, those JARs are added to the class path for the modules in the EAR. This behavior is actually a hold-over from earlier releases of GlassFish and Sun's app server before that when the spec did not spell out a way of identifying library JARs packaged in an EAR. The Java EE 5 spec (section EE 8.2) now lays out the specific ways that library JARs can be made available to the modules in an EAR. Although the spec language does not explicitly forbid other mechanisms, Bill Shannon the spec lead has said that the strong intent is to do just that. All releases of GlassFish implement the mechanisms that this section of the spec describes. We are currently working on changes that will (by default) remove the hold-over behavior that adds JARs at the EAR's top level to the class path. There are at least two ways that the GlassFish booking example could be changed so that it would work with GlassFish today, be in closer compliance with the spec, and work with GlassFish after the changes I described go in. 1. The JARs needed as library JARs could be packaged in the lib/ directory within the EAR. 2. The application.xml could specify <library-directory>.</library-directory> and the JARs could stay where they are. Or the JARs could be packaged in another directory and the <library-directory> setting changed accordingly. Choice 1 works because in the absence of an explicit setting for <library-directory> the default is lib/. Of course we want Seam to work as smoothly as possible with GlassFish now and going forward. Are you the right people to make the relevant changes to the GlassFish example? Thanks very much. - Tim -- 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