From jharting at redhat.com Thu Apr 2 02:54:02 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 02 Apr 2015 08:54:02 +0200 Subject: [weld-dev] Changes to WildFly Maven profiles Message-ID: <551CE78A.7040207@redhat.com> Yesterday I did several changes to how Weld tests are run on WildFly. This applied to both master and 2.2: 1) No distinct profiles for WildFly 8 and 9 There is now only a single "incontainer" profile for both WildFly 8 and 9. This applies to the CDI TCK runner, integration tests (tests-arquillian) and probe integration tests (Weld 3.x only). To run the tests on wildfly run: > mvn clean verify -Dincontainer 2) No remote profiles Previously, the scenario for debugging in an application server was: - start WF manually (with debugger attached) - run a test with the remote profile The "incontainer" profile has been configured to allow connecting to a running WF instance. Therefore, the procedure for debugging is now: - start WF manually (with debugger attached) - run a test with the "incontainer" profile Jozef From jharting at redhat.com Wed Apr 8 02:46:01 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 08 Apr 2015 08:46:01 +0200 Subject: [weld-dev] Weld 2.2.10.SP1 and 3.0.0.Alpha7 Message-ID: <5524CEA9.5060201@redhat.com> See http://weld.cdi-spec.org/download/ for release notes and download links. From janb at intalio.com Thu Apr 9 20:00:35 2015 From: janb at intalio.com (Jan Bartel) Date: Fri, 10 Apr 2015 10:00:35 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container Message-ID: Hi Weld developers, The Jetty project is looking at how we can do a tighter integration with Weld, also with a view to discussions in the Servlet Spec 4 committee to alleviate the necessity for CDI implementations to maintain jetty-specific initialisation code. During investigations, I noticed that we seem to have a conflict in the handling of a few annotations for classes that are managed by the servlet container (ie servlets, filters, listeners etc): @Resource @PostConstruct @PreDestroy As Jetty puts a servlet/filter/listener into service, we introspect the class and find the above annotations and process them. It seems that Weld does too, as I see the following failure for this code snippet: public class TestListener implements ServletContextListener { @Resource(mappedName="maxAmount") private Double maxAmount; } javax.naming.NameNotFoundException; remaining name 'maxAmount' at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) at javax.naming.InitialContext.lookup(InitialContext.java:411) at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) Googling around, it is not clear to me exactly which of the Common Annotations (JSR250) that Weld supports and I'd appreciate some input from the Weld devs in order for Jetty to work out how best to move forward with Weld integration. In particular, I'd appreciate some clear feedback on which of the following @Resource annotation usages will be handled by Weld: @Resource on a class @Resource on a field @Resource on a method @Resource annotations without an accompanying @Producer annotation Secondly, as can be seen from the stacktrace above, Weld is failing to find the matching JNDI entry for an @Resource annotation. This is because Weld appears not to be looking in "java:comp/env" namespace, although IIRC that is mandated by the JavaEE spec for EE managed classes (servlets/filters/listeners etc). So if Jetty delegates handling of some/all processing of @Resource, how do we ensure that Weld will be able to find the right JNDI entry? thanks for your time, Jan -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' From janb at intalio.com Thu Apr 9 22:12:58 2015 From: janb at intalio.com (Jan Bartel) Date: Fri, 10 Apr 2015 12:12:58 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: Message-ID: A little more info ... I also get an error for this snippet: private DataSource myDS; @Resource(mappedName="jdbc/mydatasource") public void setMyDatasource(DataSource ds) { myDS=ds; } java.lang.IllegalArgumentException: No @Resource annotation found on injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedMethod] @Resource public com.acme.test.AnnotationTest.setMyDatasource(DataSource) at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:38) at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) at org.eclipse.jetty.servlet.ServletContextHandler$Context.createServlet(ServletContextHandler.java:1279) at org.eclipse.jetty.servlet.ServletHolder.newInstance(ServletHolder.java:1183) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:585) at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:396) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:870) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) thanks, Jan On 10 April 2015 at 10:00, Jan Bartel wrote: > Hi Weld developers, > > The Jetty project is looking at how we can do a tighter integration > with Weld, also with a view to discussions in the Servlet Spec 4 > committee to alleviate the necessity for CDI implementations to > maintain jetty-specific initialisation code. > > During investigations, I noticed that we seem to have a conflict in > the handling of a few annotations for classes that are managed by the > servlet container (ie servlets, filters, listeners etc): > > @Resource > @PostConstruct > @PreDestroy > > As Jetty puts a servlet/filter/listener into service, we introspect > the class and find the above annotations and process them. It seems > that Weld does too, as I see the following failure for this code > snippet: > > public class TestListener implements ServletContextListener > { > @Resource(mappedName="maxAmount") > private Double maxAmount; > } > > > javax.naming.NameNotFoundException; remaining name 'maxAmount' > at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) > at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) > at javax.naming.InitialContext.lookup(InitialContext.java:411) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) > at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) > at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) > at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) > at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) > at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) > at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) > at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) > at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) > at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) > at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) > at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) > at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) > at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) > > > Googling around, it is not clear to me exactly which of the Common > Annotations (JSR250) that Weld supports and I'd appreciate some input > from the Weld devs in order for Jetty to work out how best to move > forward with Weld integration. > > In particular, I'd appreciate some clear feedback on which of the > following @Resource annotation usages will be handled by Weld: > > @Resource on a class > @Resource on a field > @Resource on a method > @Resource annotations without an accompanying @Producer annotation > > Secondly, as can be seen from the stacktrace above, Weld is failing to > find the matching JNDI entry for an @Resource annotation. This is > because Weld appears not to be looking in "java:comp/env" namespace, > although IIRC that is mandated by the JavaEE spec for EE managed > classes (servlets/filters/listeners etc). So if Jetty delegates > handling of some/all processing of @Resource, how do we ensure that > Weld will be able to find the right JNDI entry? > > thanks for your time, > Jan > -- > Jan Bartel > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' From jharting at redhat.com Fri Apr 10 02:58:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 10 Apr 2015 08:58:47 +0200 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: Message-ID: <552774A7.2020409@redhat.com> Hi Jan, to briefly explain the current integration: Handling or @Resource injection is not handled by Weld core itself. It is abstracted using the following SPI: http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/injection/spi/ResourceInjectionServices.html Weld Servlet provides a default implementation of this SPI. An application, Servlet runtime or a library may provide an alternative implementation of the given service and take over resource lookups. As for integration with Jetty, Weld provides a decorator that performs CDI and resource injection for Servlets, Filters and listeners. We can change that for Weld to only provide CDI injection (https://issues.jboss.org/browse/WELD-1919). Alternatively, instead of Weld hooking into lifecycle of Jetty-managed components, Jetty could use CDI APIs to perform CDI injection on instances it manages. Additional comments inline: On 04/10/2015 02:00 AM, Jan Bartel wrote: > Hi Weld developers, > > The Jetty project is looking at how we can do a tighter integration > with Weld, also with a view to discussions in the Servlet Spec 4 > committee to alleviate the necessity for CDI implementations to > maintain jetty-specific initialisation code. > > During investigations, I noticed that we seem to have a conflict in > the handling of a few annotations for classes that are managed by the > servlet container (ie servlets, filters, listeners etc): > > @Resource > @PostConstruct > @PreDestroy > > As Jetty puts a servlet/filter/listener into service, we introspect > the class and find the above annotations and process them. It seems > that Weld does too, as I see the following failure for this code > snippet: > > public class TestListener implements ServletContextListener > { > @Resource(mappedName="maxAmount") > private Double maxAmount; > } > > > javax.naming.NameNotFoundException; remaining name 'maxAmount' > at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) > at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) > at javax.naming.InitialContext.lookup(InitialContext.java:411) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) > at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) > at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) > at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) > at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) > at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) > at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) > at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) > at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) > at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) > at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) > at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) > at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) > at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) > > > Googling around, it is not clear to me exactly which of the Common > Annotations (JSR250) that Weld supports and I'd appreciate some input > from the Weld devs in order for Jetty to work out how best to move > forward with Weld integration. > > In particular, I'd appreciate some clear feedback on which of the > following @Resource annotation usages will be handled by Weld: > > @Resource on a class > @Resource on a field > @Resource on a method > @Resource annotations without an accompanying @Producer annotation @Resource on a field (with or without @Producer), @Resource on a method, @PostConstruct and @PreDestroy are handled by Weld on a managed instance (generally). > > Secondly, as can be seen from the stacktrace above, Weld is failing to > find the matching JNDI entry for an @Resource annotation. This is > because Weld appears not to be looking in "java:comp/env" namespace, > although IIRC that is mandated by the JavaEE spec for EE managed > classes (servlets/filters/listeners etc). So if Jetty delegates > handling of some/all processing of @Resource, how do we ensure that > Weld will be able to find the right JNDI entry? This might be a bug in weld-servlet's ResourceInjectionServices implementation. Can you file an issue at https://issues.jboss.org/browse/WELD ? > > thanks for your time, > Jan From jharting at redhat.com Fri Apr 10 02:59:40 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 10 Apr 2015 08:59:40 +0200 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: Message-ID: <552774DC.1000303@redhat.com> Looks like another bug in weld-servlet's default ResourceInjectionServices On 04/10/2015 04:12 AM, Jan Bartel wrote: > A little more info ... I also get an error for this snippet: > > > private DataSource myDS; > > @Resource(mappedName="jdbc/mydatasource") > public void setMyDatasource(DataSource ds) > { > myDS=ds; > } > > > > java.lang.IllegalArgumentException: No @Resource annotation found on > injection point [BackedAnnotatedParameter] Parameter 1 of > [BackedAnnotatedMethod] @Resource public > com.acme.test.AnnotationTest.setMyDatasource(DataSource) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:38) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) > at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) > at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) > at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) > at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) > at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) > at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) > at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) > at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) > at org.eclipse.jetty.servlet.ServletContextHandler$Context.createServlet(ServletContextHandler.java:1279) > at org.eclipse.jetty.servlet.ServletHolder.newInstance(ServletHolder.java:1183) > at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:585) > at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:396) > at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:870) > at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344) > at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) > > > thanks, > Jan > > On 10 April 2015 at 10:00, Jan Bartel wrote: >> Hi Weld developers, >> >> The Jetty project is looking at how we can do a tighter integration >> with Weld, also with a view to discussions in the Servlet Spec 4 >> committee to alleviate the necessity for CDI implementations to >> maintain jetty-specific initialisation code. >> >> During investigations, I noticed that we seem to have a conflict in >> the handling of a few annotations for classes that are managed by the >> servlet container (ie servlets, filters, listeners etc): >> >> @Resource >> @PostConstruct >> @PreDestroy >> >> As Jetty puts a servlet/filter/listener into service, we introspect >> the class and find the above annotations and process them. It seems >> that Weld does too, as I see the following failure for this code >> snippet: >> >> public class TestListener implements ServletContextListener >> { >> @Resource(mappedName="maxAmount") >> private Double maxAmount; >> } >> >> >> javax.naming.NameNotFoundException; remaining name 'maxAmount' >> at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >> at org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >> at javax.naming.InitialContext.lookup(InitialContext.java:411) >> at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >> at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >> at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >> at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >> at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >> at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >> at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >> at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >> at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >> at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >> at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >> at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >> >> >> Googling around, it is not clear to me exactly which of the Common >> Annotations (JSR250) that Weld supports and I'd appreciate some input >> from the Weld devs in order for Jetty to work out how best to move >> forward with Weld integration. >> >> In particular, I'd appreciate some clear feedback on which of the >> following @Resource annotation usages will be handled by Weld: >> >> @Resource on a class >> @Resource on a field >> @Resource on a method >> @Resource annotations without an accompanying @Producer annotation >> >> Secondly, as can be seen from the stacktrace above, Weld is failing to >> find the matching JNDI entry for an @Resource annotation. This is >> because Weld appears not to be looking in "java:comp/env" namespace, >> although IIRC that is mandated by the JavaEE spec for EE managed >> classes (servlets/filters/listeners etc). So if Jetty delegates >> handling of some/all processing of @Resource, how do we ensure that >> Weld will be able to find the right JNDI entry? >> >> thanks for your time, >> Jan >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' > > From janb at intalio.com Sun Apr 12 20:13:05 2015 From: janb at intalio.com (Jan Bartel) Date: Mon, 13 Apr 2015 10:13:05 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: <552774A7.2020409@redhat.com> References: <552774A7.2020409@redhat.com> Message-ID: Hi Jozef, Thanks for the info, a couple of followup questions inline ... > to briefly explain the current integration: Handling or @Resource injection > is not handled by Weld core itself. It is abstracted using the following > SPI: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/injection/spi/ResourceInjectionServices.html > Weld Servlet provides a default implementation of this SPI. An application, > Servlet runtime or a library may provide an alternative implementation of > the given service and take over resource lookups. Looking at the WeldServletLifecyle class on line 124, it will always provide an implementation of the ResourceInjectionServices (an instance of ServletResourceInjectionServices). If we were to provide our own implementation of ResourceInjectionServices, how would we override that one? Is there a way to get a hold of the Deployment and thus the BeanDeploymentArchives so we could set our own implementation up? Ideally we'd like a pure CDI api way of interacting with weld, but maybe that's not possible in this case? > As for integration with Jetty, Weld provides a decorator that performs CDI > and resource injection for Servlets, Filters and listeners. We can change > that for Weld to only provide CDI injection > (https://issues.jboss.org/browse/WELD-1919). Looks like the decorator will only call inject anyway - in my tests I haven't seen it call any PostConstruct or PreDestroy methods (on servlet/filter/listeners at least). Alternatively, instead of Weld > hooking into lifecycle of Jetty-managed components, Jetty could use CDI APIs > to perform CDI injection on instances it manages. > Yes, potentially we could do that, although we'd probably need your guidance on the best way to do that. Can @Resource be used by pojo beans or only by servlet artifacts (servlet/filter/listeners)? If the latter, then I'm fine for Jetty to do all the handling of @Resource. If not, then it probably makes sense for weld to handle it, and we'd need a way to disable Jetty's implementation if weld is present in a webapp ... cheers Jan > Additional comments inline: > > > On 04/10/2015 02:00 AM, Jan Bartel wrote: >> >> Hi Weld developers, >> >> The Jetty project is looking at how we can do a tighter integration >> with Weld, also with a view to discussions in the Servlet Spec 4 >> committee to alleviate the necessity for CDI implementations to >> maintain jetty-specific initialisation code. >> >> During investigations, I noticed that we seem to have a conflict in >> the handling of a few annotations for classes that are managed by the >> servlet container (ie servlets, filters, listeners etc): >> >> @Resource >> @PostConstruct >> @PreDestroy >> >> As Jetty puts a servlet/filter/listener into service, we introspect >> the class and find the above annotations and process them. It seems >> that Weld does too, as I see the following failure for this code >> snippet: >> >> public class TestListener implements ServletContextListener >> { >> @Resource(mappedName="maxAmount") >> private Double maxAmount; >> } >> >> >> javax.naming.NameNotFoundException; remaining name 'maxAmount' >> at >> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >> at >> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >> at javax.naming.InitialContext.lookup(InitialContext.java:411) >> at >> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >> at >> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >> at >> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >> at >> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >> at >> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >> at >> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >> at >> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >> at >> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >> at >> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >> at >> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >> at >> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >> at >> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >> at >> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >> at >> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >> at >> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >> at >> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >> at >> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >> at >> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >> >> >> Googling around, it is not clear to me exactly which of the Common >> Annotations (JSR250) that Weld supports and I'd appreciate some input >> from the Weld devs in order for Jetty to work out how best to move >> forward with Weld integration. >> >> In particular, I'd appreciate some clear feedback on which of the >> following @Resource annotation usages will be handled by Weld: >> >> @Resource on a class >> @Resource on a field >> @Resource on a method >> @Resource annotations without an accompanying @Producer annotation > > @Resource on a field (with or without @Producer), @Resource on a method, > @PostConstruct and @PreDestroy are handled by Weld on a managed instance > (generally). >> >> >> Secondly, as can be seen from the stacktrace above, Weld is failing to >> find the matching JNDI entry for an @Resource annotation. This is >> because Weld appears not to be looking in "java:comp/env" namespace, >> although IIRC that is mandated by the JavaEE spec for EE managed >> classes (servlets/filters/listeners etc). So if Jetty delegates >> handling of some/all processing of @Resource, how do we ensure that >> Weld will be able to find the right JNDI entry? > > This might be a bug in weld-servlet's ResourceInjectionServices > implementation. Can you file an issue at > https://issues.jboss.org/browse/WELD ? > >> >> thanks for your time, >> Jan > > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' From jharting at redhat.com Mon Apr 13 05:13:15 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 13 Apr 2015 11:13:15 +0200 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: <552774A7.2020409@redhat.com> Message-ID: <552B88AB.50408@redhat.com> On 04/13/2015 02:13 AM, Jan Bartel wrote: > Hi Jozef, > > Thanks for the info, a couple of followup questions inline ... > > >> to briefly explain the current integration: Handling or @Resource injection >> is not handled by Weld core itself. It is abstracted using the following >> SPI: >> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/injection/spi/ResourceInjectionServices.html >> Weld Servlet provides a default implementation of this SPI. An application, >> Servlet runtime or a library may provide an alternative implementation of >> the given service and take over resource lookups. > Looking at the WeldServletLifecyle class on line 124, it will always > provide an implementation of the ResourceInjectionServices (an > instance of ServletResourceInjectionServices). If we were to provide > our own implementation of ResourceInjectionServices, how would we > override that one? Is there a way to get a hold of the Deployment and > thus the BeanDeploymentArchives so we could set our own implementation > up? Ideally we'd like a pure CDI api way of interacting with weld, but > maybe that's not possible in this case? You need to interact with Weld APIs to do this. A service can be overridden using ServiceLoader mechanism. See http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services for details. > > >> As for integration with Jetty, Weld provides a decorator that performs CDI >> and resource injection for Servlets, Filters and listeners. We can change >> that for Weld to only provide CDI injection >> (https://issues.jboss.org/browse/WELD-1919). > Looks like the decorator will only call inject anyway - in my tests I > haven't seen it call any PostConstruct or PreDestroy methods (on > servlet/filter/listeners at least). OK, it's probably the case then that for these components Weld only provides CDI + resource injection and does not call @PostConstruct/@PreDestroy > > Alternatively, instead of Weld >> hooking into lifecycle of Jetty-managed components, Jetty could use CDI APIs >> to perform CDI injection on instances it manages. >> > Yes, potentially we could do that, although we'd probably need your > guidance on the best way to do that. Can @Resource be used by pojo > beans or only by servlet artifacts (servlet/filter/listeners)? If the > latter, then I'm fine for Jetty to do all the handling of @Resource. > If not, then it probably makes sense for weld to handle it, and we'd > need a way to disable Jetty's implementation if weld is present in a > webapp ... I think the best approach would be to modify the integrating decorator to only provide CDI injection to Jetty-managed instances. I have implemented it here: https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 > > cheers > Jan > >> Additional comments inline: >> >> >> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>> Hi Weld developers, >>> >>> The Jetty project is looking at how we can do a tighter integration >>> with Weld, also with a view to discussions in the Servlet Spec 4 >>> committee to alleviate the necessity for CDI implementations to >>> maintain jetty-specific initialisation code. >>> >>> During investigations, I noticed that we seem to have a conflict in >>> the handling of a few annotations for classes that are managed by the >>> servlet container (ie servlets, filters, listeners etc): >>> >>> @Resource >>> @PostConstruct >>> @PreDestroy >>> >>> As Jetty puts a servlet/filter/listener into service, we introspect >>> the class and find the above annotations and process them. It seems >>> that Weld does too, as I see the following failure for this code >>> snippet: >>> >>> public class TestListener implements ServletContextListener >>> { >>> @Resource(mappedName="maxAmount") >>> private Double maxAmount; >>> } >>> >>> >>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>> at >>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>> at >>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>> at >>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>> at >>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>> at >>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>> at >>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>> at >>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>> at >>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>> at >>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>> at >>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>> at >>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>> at >>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>> at >>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>> at >>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>> at >>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>> at >>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>> at >>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>> at >>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>> at >>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>> at >>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>> >>> >>> Googling around, it is not clear to me exactly which of the Common >>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>> from the Weld devs in order for Jetty to work out how best to move >>> forward with Weld integration. >>> >>> In particular, I'd appreciate some clear feedback on which of the >>> following @Resource annotation usages will be handled by Weld: >>> >>> @Resource on a class >>> @Resource on a field >>> @Resource on a method >>> @Resource annotations without an accompanying @Producer annotation >> @Resource on a field (with or without @Producer), @Resource on a method, >> @PostConstruct and @PreDestroy are handled by Weld on a managed instance >> (generally). >>> >>> Secondly, as can be seen from the stacktrace above, Weld is failing to >>> find the matching JNDI entry for an @Resource annotation. This is >>> because Weld appears not to be looking in "java:comp/env" namespace, >>> although IIRC that is mandated by the JavaEE spec for EE managed >>> classes (servlets/filters/listeners etc). So if Jetty delegates >>> handling of some/all processing of @Resource, how do we ensure that >>> Weld will be able to find the right JNDI entry? >> This might be a bug in weld-servlet's ResourceInjectionServices >> implementation. Can you file an issue at >> https://issues.jboss.org/browse/WELD ? >> >>> thanks for your time, >>> Jan >> > > From janb at intalio.com Mon Apr 13 18:41:50 2015 From: janb at intalio.com (Jan Bartel) Date: Tue, 14 Apr 2015 08:41:50 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: <552B88AB.50408@redhat.com> References: <552774A7.2020409@redhat.com> <552B88AB.50408@redhat.com> Message-ID: Jozef, >> Looking at the WeldServletLifecyle class on line 124, it will always >> provide an implementation of the ResourceInjectionServices (an >> instance of ServletResourceInjectionServices). If we were to provide >> our own implementation of ResourceInjectionServices, how would we >> override that one? Is there a way to get a hold of the Deployment and >> thus the BeanDeploymentArchives so we could set our own implementation >> up? Ideally we'd like a pure CDI api way of interacting with weld, but >> maybe that's not possible in this case? > > You need to interact with Weld APIs to do this. A service can be overridden > using ServiceLoader mechanism. See > http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services > for details. Ok, great, I'll give this a go and report back. >> Alternatively, instead of Weld >>> >>> hooking into lifecycle of Jetty-managed components, Jetty could use CDI >>> APIs >>> to perform CDI injection on instances it manages. >>> >> Yes, potentially we could do that, although we'd probably need your >> guidance on the best way to do that. Can @Resource be used by pojo >> beans or only by servlet artifacts (servlet/filter/listeners)? If the >> latter, then I'm fine for Jetty to do all the handling of @Resource. >> If not, then it probably makes sense for weld to handle it, and we'd >> need a way to disable Jetty's implementation if weld is present in a >> webapp ... > > I think the best approach would be to modify the integrating decorator to > only provide CDI injection to Jetty-managed instances. I have implemented it > here: > https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 So if jetty is handling @Resource (handling making the jndi entries and injecting the fields/methods) for servlets/filters/listeners, what will happen if someone declares this in eg a servlet: public class MyServlet extends HttpServlet { @Producer @Resource (name="foo") @MyDb private DataSource db; } Will weld still inspect this class and find the producer and make it available for injection in other code? cheers Jan > >> >> cheers >> Jan >> >>> Additional comments inline: >>> >>> >>> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>>> >>>> Hi Weld developers, >>>> >>>> The Jetty project is looking at how we can do a tighter integration >>>> with Weld, also with a view to discussions in the Servlet Spec 4 >>>> committee to alleviate the necessity for CDI implementations to >>>> maintain jetty-specific initialisation code. >>>> >>>> During investigations, I noticed that we seem to have a conflict in >>>> the handling of a few annotations for classes that are managed by the >>>> servlet container (ie servlets, filters, listeners etc): >>>> >>>> @Resource >>>> @PostConstruct >>>> @PreDestroy >>>> >>>> As Jetty puts a servlet/filter/listener into service, we introspect >>>> the class and find the above annotations and process them. It seems >>>> that Weld does too, as I see the following failure for this code >>>> snippet: >>>> >>>> public class TestListener implements ServletContextListener >>>> { >>>> @Resource(mappedName="maxAmount") >>>> private Double maxAmount; >>>> } >>>> >>>> >>>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>>> at >>>> >>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>>> at >>>> >>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>>> at >>>> >>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>>> at >>>> >>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>>> at >>>> >>>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>>> at >>>> >>>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>>> at >>>> >>>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>>> at >>>> >>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>> at >>>> >>>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>>> at >>>> >>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>> at >>>> >>>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>>> at >>>> >>>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>>> at >>>> >>>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>>> at >>>> >>>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>>> at >>>> >>>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>>> at >>>> >>>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>>> at >>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>>> >>>> >>>> Googling around, it is not clear to me exactly which of the Common >>>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>>> from the Weld devs in order for Jetty to work out how best to move >>>> forward with Weld integration. >>>> >>>> In particular, I'd appreciate some clear feedback on which of the >>>> following @Resource annotation usages will be handled by Weld: >>>> >>>> @Resource on a class >>>> @Resource on a field >>>> @Resource on a method >>>> @Resource annotations without an accompanying @Producer annotation >>> >>> @Resource on a field (with or without @Producer), @Resource on a method, >>> @PostConstruct and @PreDestroy are handled by Weld on a managed instance >>> (generally). >>>> >>>> >>>> Secondly, as can be seen from the stacktrace above, Weld is failing to >>>> find the matching JNDI entry for an @Resource annotation. This is >>>> because Weld appears not to be looking in "java:comp/env" namespace, >>>> although IIRC that is mandated by the JavaEE spec for EE managed >>>> classes (servlets/filters/listeners etc). So if Jetty delegates >>>> handling of some/all processing of @Resource, how do we ensure that >>>> Weld will be able to find the right JNDI entry? >>> >>> This might be a bug in weld-servlet's ResourceInjectionServices >>> implementation. Can you file an issue at >>> https://issues.jboss.org/browse/WELD ? >>> >>>> thanks for your time, >>>> Jan >>> >>> >> >> > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' From janb at intalio.com Tue Apr 14 01:17:55 2015 From: janb at intalio.com (Jan Bartel) Date: Tue, 14 Apr 2015 15:17:55 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: <552774A7.2020409@redhat.com> <552B88AB.50408@redhat.com> Message-ID: Hi Jozef, >>> Looking at the WeldServletLifecyle class on line 124, it will always >>> provide an implementation of the ResourceInjectionServices (an >>> instance of ServletResourceInjectionServices). If we were to provide >>> our own implementation of ResourceInjectionServices, how would we >>> override that one? Is there a way to get a hold of the Deployment and >>> thus the BeanDeploymentArchives so we could set our own implementation >>> up? Ideally we'd like a pure CDI api way of interacting with weld, but >>> maybe that's not possible in this case? >> >> You need to interact with Weld APIs to do this. A service can be overridden >> using ServiceLoader mechanism. See >> http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services >> for details. > > Ok, great, I'll give this a go and report back. I've implemented the service for the ResourceInjectionServices (for now each method simply does a println), and it looks like weld is seeing it: Apr 14, 2015 11:40:34 AM org.jboss.weld.bootstrap.AdditionalServiceLoader put DEBUG: Installing additional service org.jboss.weld.injection.spi.ResourceInjectionServices (class org.eclipse.jetty.cdi.servlet.ResourceInjectionServices) Weld ResourceInjectionServices jetty constructor called However, it does not appear to be being used, as I see no output from my service, but still get the following error: java.lang.RuntimeException: Error looking up maxAmount in JNDI at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:50) at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) Any hints? thanks, Jan > > >>> Alternatively, instead of Weld >>>> >>>> hooking into lifecycle of Jetty-managed components, Jetty could use CDI >>>> APIs >>>> to perform CDI injection on instances it manages. >>>> >>> Yes, potentially we could do that, although we'd probably need your >>> guidance on the best way to do that. Can @Resource be used by pojo >>> beans or only by servlet artifacts (servlet/filter/listeners)? If the >>> latter, then I'm fine for Jetty to do all the handling of @Resource. >>> If not, then it probably makes sense for weld to handle it, and we'd >>> need a way to disable Jetty's implementation if weld is present in a >>> webapp ... >> >> I think the best approach would be to modify the integrating decorator to >> only provide CDI injection to Jetty-managed instances. I have implemented it >> here: >> https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 > > So if jetty is handling @Resource (handling making the jndi entries > and injecting the fields/methods) for servlets/filters/listeners, what > will happen if someone declares this in eg a servlet: > > public class MyServlet extends HttpServlet > { > > @Producer @Resource (name="foo") > @MyDb > private DataSource db; > } > > Will weld still inspect this class and find the producer and make it > available for injection in other code? > > cheers > Jan > >> >>> >>> cheers >>> Jan >>> >>>> Additional comments inline: >>>> >>>> >>>> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>>>> >>>>> Hi Weld developers, >>>>> >>>>> The Jetty project is looking at how we can do a tighter integration >>>>> with Weld, also with a view to discussions in the Servlet Spec 4 >>>>> committee to alleviate the necessity for CDI implementations to >>>>> maintain jetty-specific initialisation code. >>>>> >>>>> During investigations, I noticed that we seem to have a conflict in >>>>> the handling of a few annotations for classes that are managed by the >>>>> servlet container (ie servlets, filters, listeners etc): >>>>> >>>>> @Resource >>>>> @PostConstruct >>>>> @PreDestroy >>>>> >>>>> As Jetty puts a servlet/filter/listener into service, we introspect >>>>> the class and find the above annotations and process them. It seems >>>>> that Weld does too, as I see the following failure for this code >>>>> snippet: >>>>> >>>>> public class TestListener implements ServletContextListener >>>>> { >>>>> @Resource(mappedName="maxAmount") >>>>> private Double maxAmount; >>>>> } >>>>> >>>>> >>>>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>>>> at >>>>> >>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>>>> at >>>>> >>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>>>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>>>> at >>>>> >>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>>>> at >>>>> >>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>>>> at >>>>> >>>>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>>>> at >>>>> >>>>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>>>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>>>> at >>>>> >>>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>>> at >>>>> >>>>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>>>> at >>>>> >>>>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>>>> at >>>>> >>>>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>>>> at >>>>> >>>>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>>>> at >>>>> >>>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>>>> at >>>>> >>>>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>>>> at >>>>> >>>>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>>>> at >>>>> >>>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>>>> at >>>>> >>>>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>>>> at >>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>>>> >>>>> >>>>> Googling around, it is not clear to me exactly which of the Common >>>>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>>>> from the Weld devs in order for Jetty to work out how best to move >>>>> forward with Weld integration. >>>>> >>>>> In particular, I'd appreciate some clear feedback on which of the >>>>> following @Resource annotation usages will be handled by Weld: >>>>> >>>>> @Resource on a class >>>>> @Resource on a field >>>>> @Resource on a method >>>>> @Resource annotations without an accompanying @Producer annotation >>>> >>>> @Resource on a field (with or without @Producer), @Resource on a method, >>>> @PostConstruct and @PreDestroy are handled by Weld on a managed instance >>>> (generally). >>>>> >>>>> >>>>> Secondly, as can be seen from the stacktrace above, Weld is failing to >>>>> find the matching JNDI entry for an @Resource annotation. This is >>>>> because Weld appears not to be looking in "java:comp/env" namespace, >>>>> although IIRC that is mandated by the JavaEE spec for EE managed >>>>> classes (servlets/filters/listeners etc). So if Jetty delegates >>>>> handling of some/all processing of @Resource, how do we ensure that >>>>> Weld will be able to find the right JNDI entry? >>>> >>>> This might be a bug in weld-servlet's ResourceInjectionServices >>>> implementation. Can you file an issue at >>>> https://issues.jboss.org/browse/WELD ? >>>> >>>>> thanks for your time, >>>>> Jan >>>> >>>> >>> >>> >> > > > > -- > Jan Bartel > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' From jharting at redhat.com Tue Apr 14 09:17:49 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 14 Apr 2015 15:17:49 +0200 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: <552774A7.2020409@redhat.com> <552B88AB.50408@redhat.com> Message-ID: <552D137D.8080907@redhat.com> On 04/14/2015 12:41 AM, Jan Bartel wrote: > Jozef, > > > >>> Looking at the WeldServletLifecyle class on line 124, it will always >>> provide an implementation of the ResourceInjectionServices (an >>> instance of ServletResourceInjectionServices). If we were to provide >>> our own implementation of ResourceInjectionServices, how would we >>> override that one? Is there a way to get a hold of the Deployment and >>> thus the BeanDeploymentArchives so we could set our own implementation >>> up? Ideally we'd like a pure CDI api way of interacting with weld, but >>> maybe that's not possible in this case? >> You need to interact with Weld APIs to do this. A service can be overridden >> using ServiceLoader mechanism. See >> http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services >> for details. > Ok, great, I'll give this a go and report back. Actually, this only work for global per-deployment Services. ResourceInjectionServices is a per-module type of service (in order to support EARs) and therefore this mechanism will not work. Sorry for misleading information. There isn't currently any nice way of overriding ResourceInjectionServices in weld-servlet. > > >>> Alternatively, instead of Weld >>>> hooking into lifecycle of Jetty-managed components, Jetty could use CDI >>>> APIs >>>> to perform CDI injection on instances it manages. >>>> >>> Yes, potentially we could do that, although we'd probably need your >>> guidance on the best way to do that. Can @Resource be used by pojo >>> beans or only by servlet artifacts (servlet/filter/listeners)? If the >>> latter, then I'm fine for Jetty to do all the handling of @Resource. >>> If not, then it probably makes sense for weld to handle it, and we'd >>> need a way to disable Jetty's implementation if weld is present in a >>> webapp ... >> I think the best approach would be to modify the integrating decorator to >> only provide CDI injection to Jetty-managed instances. I have implemented it >> here: >> https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 > So if jetty is handling @Resource (handling making the jndi entries > and injecting the fields/methods) for servlets/filters/listeners, what > will happen if someone declares this in eg a servlet: > > public class MyServlet extends HttpServlet > { > > @Producer @Resource (name="foo") > @MyDb > private DataSource db; > } > > Will weld still inspect this class and find the producer and make it > available for injection in other code? Servlets, filters, etc. are considered to be non-contextual instances. That means their lifecycle is not managed by CDI and therefore they should not declare producer fields/methods, observer methods, etc. In this particular case it is likely to work because the class of the servlet also happens to fulfill CDI managed bean requirements and therefore the class ends up being a source of two components - a Servlet and a CDI managed bean. The CDI managed bean will therefore handle the producer field access. Note however that the instances will be separate - i.e. CDI will create its own instance of the servlet class and will not use the one managed by the Servlet container. This last part are ugly internals and corner-cases of the two specs. The simplified point would be to not use @Produces on these non-contextual components at all. > > cheers > Jan > >>> cheers >>> Jan >>> >>>> Additional comments inline: >>>> >>>> >>>> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>>>> Hi Weld developers, >>>>> >>>>> The Jetty project is looking at how we can do a tighter integration >>>>> with Weld, also with a view to discussions in the Servlet Spec 4 >>>>> committee to alleviate the necessity for CDI implementations to >>>>> maintain jetty-specific initialisation code. >>>>> >>>>> During investigations, I noticed that we seem to have a conflict in >>>>> the handling of a few annotations for classes that are managed by the >>>>> servlet container (ie servlets, filters, listeners etc): >>>>> >>>>> @Resource >>>>> @PostConstruct >>>>> @PreDestroy >>>>> >>>>> As Jetty puts a servlet/filter/listener into service, we introspect >>>>> the class and find the above annotations and process them. It seems >>>>> that Weld does too, as I see the following failure for this code >>>>> snippet: >>>>> >>>>> public class TestListener implements ServletContextListener >>>>> { >>>>> @Resource(mappedName="maxAmount") >>>>> private Double maxAmount; >>>>> } >>>>> >>>>> >>>>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>>>> at >>>>> >>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>>>> at >>>>> >>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>>>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>>>> at >>>>> >>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>>>> at >>>>> >>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>>>> at >>>>> >>>>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>>>> at >>>>> >>>>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>>>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>>>> at >>>>> >>>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>>>> at >>>>> >>>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>>> at >>>>> >>>>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>>>> at >>>>> >>>>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>>>> at >>>>> >>>>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>>>> at >>>>> >>>>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>>>> at >>>>> >>>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>>>> at >>>>> >>>>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>>>> at >>>>> >>>>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>>>> at >>>>> >>>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>>>> at >>>>> >>>>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>>>> at >>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>>>> >>>>> >>>>> Googling around, it is not clear to me exactly which of the Common >>>>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>>>> from the Weld devs in order for Jetty to work out how best to move >>>>> forward with Weld integration. >>>>> >>>>> In particular, I'd appreciate some clear feedback on which of the >>>>> following @Resource annotation usages will be handled by Weld: >>>>> >>>>> @Resource on a class >>>>> @Resource on a field >>>>> @Resource on a method >>>>> @Resource annotations without an accompanying @Producer annotation >>>> @Resource on a field (with or without @Producer), @Resource on a method, >>>> @PostConstruct and @PreDestroy are handled by Weld on a managed instance >>>> (generally). >>>>> >>>>> Secondly, as can be seen from the stacktrace above, Weld is failing to >>>>> find the matching JNDI entry for an @Resource annotation. This is >>>>> because Weld appears not to be looking in "java:comp/env" namespace, >>>>> although IIRC that is mandated by the JavaEE spec for EE managed >>>>> classes (servlets/filters/listeners etc). So if Jetty delegates >>>>> handling of some/all processing of @Resource, how do we ensure that >>>>> Weld will be able to find the right JNDI entry? >>>> This might be a bug in weld-servlet's ResourceInjectionServices >>>> implementation. Can you file an issue at >>>> https://issues.jboss.org/browse/WELD ? >>>> >>>>> thanks for your time, >>>>> Jan >>>> >>> > > From jharting at redhat.com Tue Apr 14 09:19:30 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 14 Apr 2015 15:19:30 +0200 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: References: <552774A7.2020409@redhat.com> <552B88AB.50408@redhat.com> Message-ID: <552D13E2.7000805@redhat.com> On 04/14/2015 07:17 AM, Jan Bartel wrote: > Hi Jozef, > >>>> Looking at the WeldServletLifecyle class on line 124, it will always >>>> provide an implementation of the ResourceInjectionServices (an >>>> instance of ServletResourceInjectionServices). If we were to provide >>>> our own implementation of ResourceInjectionServices, how would we >>>> override that one? Is there a way to get a hold of the Deployment and >>>> thus the BeanDeploymentArchives so we could set our own implementation >>>> up? Ideally we'd like a pure CDI api way of interacting with weld, but >>>> maybe that's not possible in this case? >>> You need to interact with Weld APIs to do this. A service can be overridden >>> using ServiceLoader mechanism. See >>> http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services >>> for details. >> Ok, great, I'll give this a go and report back. > I've implemented the service for the ResourceInjectionServices (for > now each method simply does a println), and it looks like weld is > seeing it: > > Apr 14, 2015 11:40:34 AM org.jboss.weld.bootstrap.AdditionalServiceLoader put > DEBUG: Installing additional service > org.jboss.weld.injection.spi.ResourceInjectionServices (class > org.eclipse.jetty.cdi.servlet.ResourceInjectionServices) > Weld ResourceInjectionServices jetty constructor called > > However, it does not appear to be being used, as I see no output from > my service, but still get the following error: > > java.lang.RuntimeException: Error looking up maxAmount in JNDI > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:50) > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) > at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) > at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) > at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) > at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) > at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) > at org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) > at org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) > at org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) > at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) > at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) > > Any hints? Actually I somehow missed the fact the ResourceInjectionServices are per-module instead of per-deployment type of Service. As a result, it is not possible to override it using AdditionalServiceLoader. See my other e-mail for details. Sorry about that. > > thanks, > Jan > >> >>>> Alternatively, instead of Weld >>>>> hooking into lifecycle of Jetty-managed components, Jetty could use CDI >>>>> APIs >>>>> to perform CDI injection on instances it manages. >>>>> >>>> Yes, potentially we could do that, although we'd probably need your >>>> guidance on the best way to do that. Can @Resource be used by pojo >>>> beans or only by servlet artifacts (servlet/filter/listeners)? If the >>>> latter, then I'm fine for Jetty to do all the handling of @Resource. >>>> If not, then it probably makes sense for weld to handle it, and we'd >>>> need a way to disable Jetty's implementation if weld is present in a >>>> webapp ... >>> I think the best approach would be to modify the integrating decorator to >>> only provide CDI injection to Jetty-managed instances. I have implemented it >>> here: >>> https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 >> So if jetty is handling @Resource (handling making the jndi entries >> and injecting the fields/methods) for servlets/filters/listeners, what >> will happen if someone declares this in eg a servlet: >> >> public class MyServlet extends HttpServlet >> { >> >> @Producer @Resource (name="foo") >> @MyDb >> private DataSource db; >> } >> >> Will weld still inspect this class and find the producer and make it >> available for injection in other code? >> >> cheers >> Jan >> >>>> cheers >>>> Jan >>>> >>>>> Additional comments inline: >>>>> >>>>> >>>>> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>>>>> Hi Weld developers, >>>>>> >>>>>> The Jetty project is looking at how we can do a tighter integration >>>>>> with Weld, also with a view to discussions in the Servlet Spec 4 >>>>>> committee to alleviate the necessity for CDI implementations to >>>>>> maintain jetty-specific initialisation code. >>>>>> >>>>>> During investigations, I noticed that we seem to have a conflict in >>>>>> the handling of a few annotations for classes that are managed by the >>>>>> servlet container (ie servlets, filters, listeners etc): >>>>>> >>>>>> @Resource >>>>>> @PostConstruct >>>>>> @PreDestroy >>>>>> >>>>>> As Jetty puts a servlet/filter/listener into service, we introspect >>>>>> the class and find the above annotations and process them. It seems >>>>>> that Weld does too, as I see the following failure for this code >>>>>> snippet: >>>>>> >>>>>> public class TestListener implements ServletContextListener >>>>>> { >>>>>> @Resource(mappedName="maxAmount") >>>>>> private Double maxAmount; >>>>>> } >>>>>> >>>>>> >>>>>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>>>>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>>>>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>>>>> at >>>>>> >>>>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>>>> at >>>>>> >>>>>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>>>>> at >>>>>> >>>>>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>>>>> at >>>>>> >>>>>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>>>>> at >>>>>> >>>>>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>>>>> at >>>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>>>>> >>>>>> >>>>>> Googling around, it is not clear to me exactly which of the Common >>>>>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>>>>> from the Weld devs in order for Jetty to work out how best to move >>>>>> forward with Weld integration. >>>>>> >>>>>> In particular, I'd appreciate some clear feedback on which of the >>>>>> following @Resource annotation usages will be handled by Weld: >>>>>> >>>>>> @Resource on a class >>>>>> @Resource on a field >>>>>> @Resource on a method >>>>>> @Resource annotations without an accompanying @Producer annotation >>>>> @Resource on a field (with or without @Producer), @Resource on a method, >>>>> @PostConstruct and @PreDestroy are handled by Weld on a managed instance >>>>> (generally). >>>>>> >>>>>> Secondly, as can be seen from the stacktrace above, Weld is failing to >>>>>> find the matching JNDI entry for an @Resource annotation. This is >>>>>> because Weld appears not to be looking in "java:comp/env" namespace, >>>>>> although IIRC that is mandated by the JavaEE spec for EE managed >>>>>> classes (servlets/filters/listeners etc). So if Jetty delegates >>>>>> handling of some/all processing of @Resource, how do we ensure that >>>>>> Weld will be able to find the right JNDI entry? >>>>> This might be a bug in weld-servlet's ResourceInjectionServices >>>>> implementation. Can you file an issue at >>>>> https://issues.jboss.org/browse/WELD ? >>>>> >>>>>> thanks for your time, >>>>>> Jan >>>>> >>>> >> >> >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' > > From jharting at redhat.com Wed Apr 22 03:20:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 22 Apr 2015 09:20:51 +0200 Subject: [weld-dev] Weld 2.2.11.Final & 3.0.0.Alpha8 Message-ID: <55374BD3.2060407@redhat.com> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ https://developer.jboss.org/thread/256103 From jharting at redhat.com Mon Apr 27 10:57:05 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 27 Apr 2015 16:57:05 +0200 Subject: [weld-dev] Bootstrap API in Weld 3.0.0.Alpha8 Message-ID: <553E4E41.7020200@redhat.com> We extended Weld's API for Java SE in the recent 3.0.0.Alpha8 release. The main feature is a new builder for programmatic configuration of managed classes, packages, enabled interceptors and others. This could serve as a draft for the bootstrap API to be added to CDI. See the release blog post for more details: http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ Jozef From jharting at redhat.com Tue Apr 28 01:58:23 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 28 Apr 2015 07:58:23 +0200 Subject: [weld-dev] [cdi-dev] Bootstrap API in Weld 3.0.0.Alpha8 In-Reply-To: References: <553E4E41.7020200@redhat.com> Message-ID: <553F217F.8040001@redhat.com> Hi Antonio, the artifact you mentioned is correct. The CDI API 1.2, which is transitively resolved, is correct also. The builder API is present in the Weld-specific org.jboss.weld.environment.se package. HTH, Jozef On 04/27/2015 11:36 PM, Antonio Goncalves wrote: > Hi Josef, > > Which Maven artifact is needed to start playing with it ? When I use > this one below, I miss all the CDI APIs (javax.inject.*, > javax.enterprise.inject.*, etc.) : > > > org.jboss.weld.se > > weld-se-core > 3.0.0.Alpha8 > > > Is there an artifact that also depends on the new version of the API ? > Or we just use the "old" CDI 1.2 APIs ? > > Thanks > Antonio > > > On Mon, Apr 27, 2015 at 4:57 PM, Jozef Hartinger > wrote: > > We extended Weld's API for Java SE in the recent 3.0.0.Alpha8 release. > The main feature is a new builder for programmatic configuration of > managed classes, packages, enabled interceptors and others. This could > serve as a draft for the bootstrap API to be added to CDI. > > See the release blog post for more details: > http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ > > Jozef > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | > Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150428/b47ed998/attachment-0001.html From emijiang6 at googlemail.com Wed Apr 29 17:52:14 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 29 Apr 2015 22:52:14 +0100 Subject: [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml Message-ID: CDI1.2 spec section 8.2.2 says: In the beans.xml Each child element must specify the name of a decorator bean class. If there is no class with the specified name, or if the class with the specified name is not a decorator bean class, the container automatically detects the problem and treats it as a deployment problem. If the same class is listed twice under the element, the container automatically detects the problem and treats it as a deployment problem. Will Weld do the validation or Weld expects the integrator to do the validation? I am confused about what validations are done by the spec reference implemenatation (RI) or RI consumer. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150429/c4d76add/attachment.html From jharting at redhat.com Thu Apr 30 01:24:59 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 30 Apr 2015 07:24:59 +0200 Subject: [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml In-Reply-To: References: Message-ID: <5541BCAB.6020305@redhat.com> Hi Emily, Weld performs all these validations. Jozef On 04/29/2015 11:52 PM, Emily Jiang wrote: > CDI1.2 spec section 8.2.2 says: > In the beans.xml > Each child element must specify the name of a decorator bean > class. If there is no class with the specified name, or if the class > with the specified name is not a decorator bean class, the container > automatically detects the problem and treats it as a deployment problem. > If the same class is listed twice under the element, the > container automatically detects the problem and treats it as a > deployment problem. > > Will Weld do the validation or Weld expects the integrator to do the > validation? > > I am confused about what validations are done by the spec reference > implemenatation (RI) or RI consumer. > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150430/6d24a366/attachment.html