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
7 years, 3 months
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
7 years, 4 months
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
7 years, 4 months
