@Resource annotation handling by Weld vs Servlet container
by Jan Bartel
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 <janb(a)intalio.com>
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
9 years, 5 months
OsgiServiceProvider and Singleton
by Александр Свиридов
I use weld se+pax+osgi.
I have 3 bundles. And I want that one instance of one class of one bundle be accessed via CDI to other bundles. I tried different ways but I found no solution.
Is it possible to do taking into consideration that pax creates one cdi container for every bundle?
--
Александр Свиридов
9 years, 6 months
How to change logging level for weld se
by Александр Свиридов
Please, give the name of java system property which must be used in order to change the logging level for weld se.
--
Александр Свиридов
9 years, 6 months
JavaEE component classes - JPA entity listener
by Emily Jiang
In CDI 1.2 spec
11.5.7. ProcessInjectionPoint event
The container must fire an event for every injection point of every Java EE
component class
supporting injection that may be instantiated by the container at runtime,
including every managed bean declared using @ManagedBean, EJB session or
message-driven bean, bean, interceptor or decorator.
The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which
includes servlets, servlet filters, entity listeners etc.
My concern is about entity listeners in JPA. Eclipse link has done all the
injection for entity listeners. It does not fire the event, @See
createEntityListenerAndInjectDependancies(...)
JPA spec section 3.5.1 does not mention this event requirement. How can the
eclipse cdi implementation satisfy the CDI spec?
[1]
http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundat...
]
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
ManagedBean and Weld integration
by Emily Jiang
For managed beans (@ManagedBean classes), they are java EE component
classes. They support both cdi and non-cdi interceptors. When I create a
instance using injectionTarget.produce(), I got hold of the instance with
both cdi and non-cdi interceptors associated. However, the @Resource
injection point on the non-cdi interceptors are not injected when Weld
creates the interceptor instances.
Is there anything I have missed or this is a bug?
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
JavaEE component class vs. Weld managed classes
by Emily Jiang
I need to fire events for each JavaEE component class (e.g. process
injectionTarget, injectionPoint etc) during Weld bootstrap phase. At the
moment, I am think to go through all bdas per deployment and process all
classes in the bda and fire events for each JavaEE component classes as
Weld leaves it to be handled by the integrator. What is the best way to
find out which class is JavaEE component class? I don't like to idea of
building a long hardcoded list from the EE.5-1 table of the JavaEE7 spec.
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
CDI+OSGI: bundle packages scope
by Александр Свиридов
I use javase and solution osgi (felix)+cdi(weld)+paxcdi. I have two bundles A and B. Bundle B is a lib bundle.
In bundle A I have one class and one package.
package com.example.firstpackage;import com.example.secondpackage.Class2;publicclassClass1{@InjectprivateClass2 class2;}
In bundle B I have two classes and two packages
package com.example.secondpackage;import com.example.thirdpackage.Class3;publicclassClass2{@InjectprivateClass3 class3;}
and
package com.example.thirdpackage;publicclassClass3{....}
I install and start both bundles.
The problem - pax (or weld) for injecting in classes of bundle A scans only those packages which are imported for classes IN bundle A. In my example - CDI for injecting in Class1 Class2 will scan com.example.secondpackage of bundle B. However, it will throw exception as Class2 needs Class3 but com.example.thirdpackage is not scanned for bundle A (as it's not imported!!!). com.example.thirdpackage is only scanned for bundle B but, as I understand every bundles for cdi has its own scope. How to fix it?
--
Александр Свиридов
9 years, 6 months
