@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, 4 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, 5 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, 5 months
Unable to find java.lang.Integer in any bean archives
by Emily Jiang
I'm trying to run the cdi tck but got an error for the following test:
In the test:
org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest
Method: arquillianBeforeClass
Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000817:
Unable to find Bean Deployment Archive for class java.lang.Integer
at
org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39)
at
org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70)
at
org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86)
at
org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186)
... 15 more
It seems that Custom bean was added by an extension but the bean implements
Bean<Integer>. Surely the java.lang.Interger should not be any bean
archives. Can someone tell me what I might done wrong? Will integrator need
to do something to cater for all of the java.x classes or Weld should
handle this?
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
Re: [weld-dev] Java EE component class injection point validation
by Emily Jiang
oops. yes. Can you shed some lights on this problem?
On Mon, May 18, 2015 at 8:48 AM, Martin Kouba <mkouba(a)redhat.com> wrote:
> Emily,
>
> I believe this one belongs rather to the weld-dev ML.
>
> Martin
>
> Dne 18.5.2015 v 09:23 Emily Jiang napsal(a):
>
>>
>> In CDI1.2 spec, section 5.5.7
>> If a Java EE component class supporting injection that is not a bean has
>> an injection point of
>> type InjectionPoint and qualifier @Default, the container automatically
>> detects the problem
>> and treats it as a definition error.
>>
>> How can I plugin this validation? Is there a callback spi I can use to
>> validate the injection point on JavaEE component? This exception needs
>> to be thrown during the application deployment.
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang(a)apache.org <mailto:ejiang@apache.org>
>>
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
CDI EJB Intergration on Weld
by Emily Jiang
I have a few questions on ejb integration on Weld.
1)Does Weld handle the instance creation for ejb (using
injectionTarget.produce) or delegate the instance creation to EJB
container? I guess Weld will create the instead as it can manage
decorators. If not, how can decorators be managed? Please confirm.
2) When Weld creates the EJB instance, how can the other non-CDI
aroundconstruct interceptors (such as the interceptors defined via
ejb-jar.xml or @Interceptors) be passed in? I found out the
WeldCreationContext and AroundConstructCallback but I cannot find anything
mentioned in the weld reference doc. Is this the right plugin point?
3)If Weld creates the EJB instance, how can all interceptors (cdi style and
ejb style) be invoked? Will the instance need to be passed back to EJB
container together with all CDI interceptors (get hold of them via
EjbEndpointServiceImpl.java) and EJB container needs to manage the
interceptors being invoked?
4)In Weld spec, it says you must register the SessionBeanInterceptor as the
inner most interceptor in the stack for all EJBS. Can you clarify what
inner most means? Does this interceptor need to be the first EJB
interceptor to be called or the last EJB interceptor to be invoked?
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
annotations on Weld proxy classes
by Emily Jiang
It seems Weld proxy has the same annotations as the proxied class. However
this conflicts with Bean validation spec as far as @Valid is concerned.
This section of the bean validation spec is ending up in violation due to
the duplicated annotation:
• One must not mark a method return value for cascaded validation more than
once in a line of a class hierarchy.
In other words, overriding methods on sub types (be it sub
classes/interfaces or interface implementations) cannot mark the return
value for cascaded validation if the return value has already been marked
on the overridden method of the super type or interface.
"The @Valid annotation is used to declare that a cascaded validation of the
given method/constructor parameters or
return values is performed by the Bean Validation provider. "
Here is some debug added to the apache bean validation code that shows
which two classes have the @Valid on the createValidEvent method:
$$$$$$$$$$$$DEBUG clazz = class
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass
method = public
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass.createValidEvent()
$$$$$$$$$$$$DEBUG clazz = class
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue
method = public
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue.createValidEvent()
$$$$$$$$$$$$$$$$$DEBUG returnValid = 2 // number of hits having @Valid
If I understand correctly, I think this annotation needs to be treated
differently.
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
Weld 2.3
by Jozef Hartinger
I've created a new branch named *2.3* in the weld repo. This branch is
going to host the 2.3.x stream of Weld releases.
Weld 2.3 will remain a CDI 1.2 implementation. We are incrementing the
minor version due to several new features we plan on adding. A final
release of Weld 2.3 is planned to be released this summer.
Our CI setup has been updated to test this new branch regularly.
Note that from now on, we are dropping Java 6 support and therefore Java
7 is the minimal requirement for building and running Weld 2.3
Jozef
9 years, 6 months
Re: [weld-dev] [cdi-tck] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
by Emily Jiang
Thank you Tom and Jozef!
On Mon, May 25, 2015 at 9:39 AM, Tomas Remes <tremes(a)redhat.com> wrote:
>
> Hi Emily,
>
> Yes I am already working on that. As I commented on the isssue.
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Emily Jiang" <emijiang6(a)googlemail.com>
> To: "Jozef Hartinger" <jharting(a)redhat.com>
> Cc: "cdi-tck" <cdi-tck(a)lists.jboss.org>, "Weld-Dev List" <
> weld-dev(a)lists.jboss.org>
> Sent: Monday, May 25, 2015 10:31:31 AM
> Subject: Re: [cdi-tck] [weld-dev] cdi tck:
> org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
>
> Thank you Jozef! By the way, the tck-484 was logged a few days ago but its
> description was not clear enough, so Tomas Remes had some question on it.
> With my detailed explaination, can you guys work together to get this issue
> solved? Thank you very much!
>
> On Mon, May 25, 2015 at 7:03 AM, Jozef Hartinger < jharting(a)redhat.com >
> wrote:
>
>
>
> Hi Emily,
>
> I cannot find anything in the CDI spec that would prevent lazy
> initialization of the web container. Therefore, I think you are right and
> the test should be modified. There is already a CDI TCK ticket at
> https://issues.jboss.org/browse/CDITCK-484
>
> Jozef
>
>
> On 05/24/2015 04:21 PM, Emily Jiang wrote:
>
>
>
> I am trying to run the cdi tck:
> org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
> Method: testDeployment
>
> It seems this test is to verify whether both web modules receive the
> initilization event of ApplicationScoped. The confusing bit is that the
> test directly verfies whether both events are received without trying to
> send request to activate the web modules. I think the test assume web
> modules are active and did not consider the fact of that some application
> server starts the modules in a lazy mode.
>
> The CDI spec says:
> The application scope is active:
> • during the service() method of any servlet in the web application,
> during the doFilter()
> method of any servlet filter and when the container calls any
> ServletContextListener,
> HttpSessionListener, AsyncListener or ServletRequestListener
>
> According to cdi spec 6.7.3:
> An event with qualifier @Initialized(ApplicationScoped.class) is fired
> when the application
> context is initialized and an event with qualifier
> @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a
> Servlet container, or
> • any java.lang.Object for other types of application.
> The spec did not say whether the event should be recieved. In my
> environment, if the web module url is hit, the obeserved event will be
> obsevered.
>
> I think we have implemented this correctly as I can confirm the
> application scope is active when a request is sent and the event of
> @Initialized(ApplicationScoped.class) is received as well but the test
> assumes the web module is active automatically without even needing to send
> the first request.
>
> Can someone shed some lights on this? What is the test trying to do? I am
> suggesting the test should be updated to send the first request first
> before checking the size of the obsevers.
>
> I did not directly send to cdi tck as I would like to get some input from
> weld dev list first.
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang(a)apache.org
>
>
> _______________________________________________
> weld-dev mailing list weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang(a)apache.org
>
> _______________________________________________
>
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
