On 18 Jan 2011, at 10:55, Shane Bryzak wrote: > On 18/01/11 04:24, Pete Muir wrote: >> Hi Dan >> >> JSR-299 is no longer in existence, as the spec is now complete. We will be >> filing a new JSR for CDI 1.1. If you want to discuss this, mail >> [email protected], or file an issue in the CDI issue tracker on >> jboss.org. >> >> Specifically regarding your points, >> >> 1) this was recognised as a bug in GlassFish, and has been fixed >> accordingly. I would suggest raising a CDI issue and pointing out that >> there has been confusion about this, and it would be helpful if the spec >> explicitly stated that the it is referring to the JAR file spec, and that >> service providers do not need to be placed in bean archives. > > Should we also raise a CDITCK issue to add a test for this?
Sounds like a good plan. >> 2) this also sounds like a GlassFish bug, so I don't think mailing the EG is >> appropriate, instead you should raise an GLASSFISH issue. This is well >> defined at the moment, and is simply a hard area to get right, hence why we >> are finding bugs. Short of actually enforcing an impl on people there is >> little I think we can do to improve this. >> >> Pete >> >> On 17 Jan 2011, at 18:04, Dan Allen wrote: >> >>> I attempted to send this message to [email protected], but it was >>> rejected. Can you forward it on if necessary? >>> >>> -Dan >>> >>> On Mon, Jan 17, 2011 at 13:00, Dan Allen<[email protected]> wrote: >>> JSR-299 EG, >>> >>> For a while now, the Seam 3 project has been working to solve a portability >>> issue that prevents modules (i.e., extensions) from running on GlassFish >>> (3.0 and 3.1) [1]. After much research, we've determined that this isn't a >>> problem that we have much control over. It's clear that there is an >>> inconsistency in the way the JSR-299 specification is being interpreted >>> with regard to extension loading. >>> >>> The question is this. Does an extension have to be in an bean archive in >>> order to be loaded? >>> >>> Section 11.5 states: >>> >>> "An extension is a service provider of the service >>> javax.enterprise.inject.spi.Extension declared in META-INF/services." >>> >>> If one assumes that "service provider" refers to the term defined in the >>> jar specification [2], then one would conclude that an extension does not >>> have to be in a bean archive to be recognized (these are orthogonal >>> concerns). However, the Java EE 6 reference implementation (GlassFish) does >>> not honor this interpretation prior to version 3.1-b37, as indicated by [3]. >>> >>> Even with the recent fix to the reference implementation, there is a >>> secondary interpretation problem: >>> >>> Can an extension register a bean programmatically for a class that resides >>> in another non-bean archive? >>> >>> This question requires a short example. >>> >>> Assume one archive, a.jar, has the following contents: >>> >>> org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class >>> >>> A second archive, b.jar, has the following contents: >>> >>> org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class >>> org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class >>> org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class >>> META-INF/services/javax.enterprise.inject.spi.Extension >>> >>> AnotherBeanClassToRegister has an injection point of type >>> BeanClassToRegister: >>> >>> public class AnotherBeanClassToRegister { >>> @Inject >>> private BeanClassToRegister collaborator; >>> } >>> >>> BeanClassToRegister and AnotherBeanClassToRegister are added as beans >>> programmatically in respective extensions listed in the service provider >>> descriptor: >>> >>> public class ManualBeanRegistrationExtension implements Extension { >>> public void registerBeans(@Observes BeforeBeanDiscovery event, >>> BeanManager bm) { >>> >>> event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class)); >>> } >>> } >>> >>> public class AnotherManualBeanRegistrationExtension implements Extension { >>> public void registerBeans(@Observes BeforeBeanDiscovery event, >>> BeanManager bm) { >>> >>> event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class)); >>> } >>> } >>> >>> The two libraries, a.jar and b.jar are bundled in a web archive, test.war >>> >>> WEB-INF/lib/a.jar >>> WEB-INF/lib/b.jar >>> WEB-INF/beans.xml >>> >>> Deploying this archive to the reference implementation fails with an error >>> message that the injection point from above cannot be satisfied. Clearly >>> there is a visibility problem across bean archives in this case. >>> >>> Adding META-INF/beans.xml to a.jar and removing the >>> ManualBeanRegistrationExtension from b.jar resolves the issue in the >>> reference implementation. >>> >>> The fact that there is so much discussion around this issue has led me to >>> the conclusion that it needs to be addressed at the specification level. >>> >>> These scenarios have been prepared using Open TCK tests (based on >>> Arquillian). [4] >>> >>> -Dan >>> >>> p.s. Thanks to Jason Porter for helping track down this issue and drafting >>> the initial the Open TCK tests. >>> >>> [1] https://issues.jboss.org/browse/SOLDER-47 >>> [2] >>> http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider >>> [3] http://java.net/jira/browse/GLASSFISH-14808 >>> [4] >>> https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opentck/javaee/cdi/spi/beforebeandiscovery >>> >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> http://www.google.com/profiles/dan.j.allen >>> >>> >>> >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> http://www.google.com/profiles/dan.j.allen >> >> _______________________________________________ >> weld-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
