@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
Validation on Alternative/Interceptor/Decorator mentioned in beans.xml
by Emily Jiang
CDI1.2 spec section 8.2.2 says:
In the beans.xml
Each child <class> element must specify the name of a decorator bean class.
If there is no class with the specified name, or if the class with the
specified name is not a decorator bean class, the container automatically
detects the problem and treats it as a deployment problem.
If the same class is listed twice under the <decorators> element, the
container automatically detects the problem and treats it as a deployment
problem.
Will Weld do the validation or Weld expects the integrator to do the
validation?
I am confused about what validations are done by the spec reference
implemenatation (RI) or RI consumer.
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 7 months
Re: [weld-dev] [cdi-dev] Bootstrap API in Weld 3.0.0.Alpha8
by Jozef Hartinger
Hi Antonio,
the artifact you mentioned is correct. The CDI API 1.2, which is
transitively resolved, is correct also. The builder API is present in
the Weld-specific org.jboss.weld.environment.se package.
HTH,
Jozef
On 04/27/2015 11:36 PM, Antonio Goncalves wrote:
> Hi Josef,
>
> Which Maven artifact is needed to start playing with it ? When I use
> this one below, I miss all the CDI APIs (javax.inject.*,
> javax.enterprise.inject.*, etc.) :
>
> <dependency>
> <groupId>org.jboss.weld.se
> <http://org.jboss.weld.se></groupId>
> <artifactId>weld-se-core</artifactId>
> <version>3.0.0.Alpha8</version>
> </dependency>
>
> Is there an artifact that also depends on the new version of the API ?
> Or we just use the "old" CDI 1.2 APIs ?
>
> Thanks
> Antonio
>
>
> On Mon, Apr 27, 2015 at 4:57 PM, Jozef Hartinger <jharting(a)redhat.com
> <mailto:jharting@redhat.com>> wrote:
>
> We extended Weld's API for Java SE in the recent 3.0.0.Alpha8 release.
> The main feature is a new builder for programmatic configuration of
> managed classes, packages, enabled interceptors and others. This could
> serve as a draft for the bootstrap API to be added to CDI.
>
> See the release blog post for more details:
> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>
> Jozef
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider
> licenses the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9 years, 8 months
Changes to WildFly Maven profiles
by Jozef Hartinger
Yesterday I did several changes to how Weld tests are run on WildFly.
This applied to both master and 2.2:
1) No distinct profiles for WildFly 8 and 9
There is now only a single "incontainer" profile for both WildFly 8 and
9. This applies to the CDI TCK runner, integration tests
(tests-arquillian) and probe integration tests (Weld 3.x only). To run
the tests on wildfly run:
> mvn clean verify -Dincontainer
2) No remote profiles
Previously, the scenario for debugging in an application server was:
- start WF manually (with debugger attached)
- run a test with the remote profile
The "incontainer" profile has been configured to allow connecting to a
running WF instance. Therefore, the procedure for debugging is now:
- start WF manually (with debugger attached)
- run a test with the "incontainer" profile
Jozef
9 years, 8 months
