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
5 days, 2 hours
Weld 3.0 Beta 1 & Arquillian Embedded Container
by John D. Ament
Hi,
It seems that Arquillian Embedded Container Weld (2.0 Beta3) is not
compatible with Weld 3 Beta 1. Is this a known issue, or do we need to
bump to Weld container 3.0.x to add CDI 2.0 support?
java.lang.NoClassDefFoundError: org/jboss/weld/literal/InitializedLiteral
at
org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:244)
at
org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
John
9 years
Weld & Groovy
by John D. Ament
Hi
So based on the last issue I saw, I just want to run this by you guys.
I'm starting to run tests with Weld 3. I saw the following, which made me
think of the groovy issue
Caused by: java.lang.AbstractMethodError:
org.apache.cxf.Bus$1366014918$Proxy$_$$_WeldClientProxy.getProperty(Ljava/lang/String;)Ljava/lang/Object;
at org.apache.cxf.common.util.ClassHelper.getRealClass(ClassHelper.java:81)
I just want to confirm that this is fixed on master, and its just because
Weld is a little out of date.
-Dweld.version=3.0.0.Alpha17 -Dcdi-api.version=2.0-EDR2
John
9 years
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
