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 week
Specializes bean in war causes unsatisfied resolution exception
by Benjamin Confino
Hello
A customer of mine sent in a test application with the following
structure:
A war file inside ear
Two jar files inside ear/lib
One jar file inside ear/war/WEB-INF/lib
There is a class inside one of the ear/lib jar files which @Injects a bean
from the other ear/lib jar file
And there is a class inside the ear/war/WEB-INF/lib jar file that
@Specializes the bean inside an ear/lib jar file
(You can see the application at was_bugs/was_bug22 at master ·
thikade/was_bugs · GitHub )
Attempting to run this application on Weld results in an Unsatisfied
Resolution Exception. When I remove the jar containing the @Specializes
bean the application works correctly.
My first thought was that this application should not work, because the
war file and it's internal jar would have a second classloader that would
be invisible to the application classloader. However the customer
attested, and I confirmed that this application works fine on
OpenWebBeans.
I do not think this is an integration issue, because I tested this on
Wildfly and got the same error.
So it seems that Weld throws an Unsatisfied Resolution Exception if
@specializes exists in a class that is loaded by a classloader which is
not visible .
What do you think is the correct behaviour is in this instance? From a
classloading perspective a class inside ear/lib should not be able to see
a class inside ear/war; but on the other hand the entire purpose of a
@Specializes bean is that you drop it into your application and it
replaces the original bean. It feels appropriate that you can drop in a
war file containing the @Specializes bean and it just works without you
having to do anything extra.
Best regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
9 years, 1 month
Re: [weld-dev] [cdi-dev] Think I found bug with interceptor
by Matej Novotny
Hi,
first of all let us take this conversation off the cdi list, as it is a Weld related question (moving to weld-dev list).
Now to your question(s)...
If you could attach a tiny reproducer, this would probably be resolved within minutes, so if you can send one, do so please.
> Now here's the problem, If I use this annotation on just a regular method
> which I call myself, it DOES NOT work.
This feels like very basic use case do I doubt it isn't working.
What are the classes where you declare these methods?
How to you obtain a reference to the bean which has `doSend` method?
Again, reproducer would make all this very obvious and I could help you quickly :)
> @Priority set on it and that works fine. But I've also tried setting
> <interceptors> in beans.xml
@Priority enables in for whole application, while beans.xml for the given bean archive.
And you should not combine both approaches.
Regards
Matej
----- Original Message -----
> From: "Michael Remijan" <mjremijan(a)yahoo.com>
> To: cdi-dev(a)lists.jboss.org
> Sent: Monday, November 14, 2016 5:43:27 AM
> Subject: [cdi-dev] Think I found bug with interceptor
>
> Greetings,
>
> I am using:
>
> <dependency>
> <groupId>org.jboss.weld.se</groupId>
> <artifactId>weld-se-core</artifactId>
> <version>3.0.0.Alpha15</version>
> </dependency>
>
> and I think I found a bug with the interceptors. I wanted to ask about it
> first before I put it in Jira.
>
> Basically, the interceptor I have defined works great if I annotate a method
> called by the CDI container, which in my case is an method observing for an
> event. I have an ExceptionRetryInterceptor class and an ExceptionRetry
> annotation. If I annotate an observer method like this:
>
> @ExceptionRetry
> public void send(
> @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt
> ) throws MessagingException, IOException {....}
>
>
> No problem, everything works fine. I can see the interceptor code being
> called in my logs.
>
> Now here's the problem, If I use this annotation on just a regular method
> which I call myself, it DOES NOT work. So if I refactor the above example so
> the annotation is NOT on the observer method called by the container, then
> the doSend() method below does NOT get wrapped by the interceptor:
>
>
> public void send(
> @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt
> ) throws MessagingException, IOException {
> //....
> doSend();
> }
>
> @ExceptionRetry
> public void doSend() {....} // this method does not get wrapped by the
> interceptor
>
>
> I'm trying to figure out why. My ExceptionRetryInterceptor class has a
> @Priority set on it and that works fine. But I've also tried setting
> <interceptors> in beans.xml but the doSend(){...} method still doesn't get
> wrapped.
>
> Any thoughts/help?
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
9 years, 2 months
