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
6 months, 1 week
@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'
11 years
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?
--
Александр Свиридов
11 years, 1 month
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.
--
Александр Свиридов
11 years, 1 month
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
11 years, 1 month
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
11 years, 1 month
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
11 years, 1 month
