Thanks for the info, a couple of followup questions inline ...
to briefly explain the current integration: Handling or @Resource
is not handled by Weld core itself. It is abstracted using the following
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
and resource injection for Servlets, Filters and listeners. We can change
that for Weld to only provide CDI injection
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
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
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):
> 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
> public class TestListener implements ServletContextListener
> private Double maxAmount;
> javax.naming.NameNotFoundException; remaining name 'maxAmount'
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344)
> 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
> 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
> thanks for your time,
Jan Bartel <janb(a)intalio.com>
'Expert Jetty/CometD developer,production,operations advice'