WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
1 month, 2 weeks
@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'
10 years, 8 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
10 years, 9 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?
--
Александр Свиридов
10 years, 9 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
10 years, 9 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
10 years, 9 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
10 years, 9 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
10 years, 9 months
