From mkouba at redhat.com  Thu Dec  1 02:57:16 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 1 Dec 2016 08:57:16 +0100
Subject: [weld-dev] Specializes bean in war causes unsatisfied
 resolution exception
In-Reply-To: <OF7850FB31.6B80D34E-ON0025807B.005D729C-8025807B.005D88AF@notes.na.collabserv.com>
References: <OFBADD4EE6.C246EA51-ON00258079.005776DA-80258079.00578D21@notes.na.collabserv.com>
	<425811502.514922.1480399585459.JavaMail.zimbra@redhat.com>
	<99d4d597-fd16-4a55-327e-8db5556b8b0c@redhat.com>
	<OF7850FB31.6B80D34E-ON0025807B.005D729C-8025807B.005D88AF@notes.na.collabserv.com>
Message-ID: <464bd731-7e99-854a-3100-0cad179bd909@redhat.com>

Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
> Thank you for the prompt replies.
>
> In answer to your question. It is UiSnapshotData which gets injected
> under OWB.

Ok, thanks. From my point of view this violates the EE class loading rules.

>
> Regards
> Benjamin
>
>
>
> From:        Martin Kouba <mkouba at redhat.com>
> To:        Matej Novotny <manovotn at redhat.com>, Benjamin
> Confino/UK/IBM at IBMGB,
> Cc:        Emily Jiang/UK/IBM at IBMGB, Tom Evans/UK/IBM at IBMGB,
> weld-dev at lists.jboss.org
> Date:        29/11/2016 07:42
> Subject:        Re: [weld-dev] Specializes bean in war causes
> unsatisfied resolution exception
> ------------------------------------------------------------------------
>
>
>
> Matej is correct. The specializing bean from the war disables the
> specialized bean from ear/lib. And since the bean from war is not
> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
> unsatisfied dependency exists.
>
> By the way, what instance of SnapshotData gets injected into
> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
> war/lib?
>
> Martin
>
> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>> Hello Benjamin
>>
>> Thanks for well written question!
>>
>>> (You can see the application at was_bugs/was_bug22 at master ?
>>> thikade/was_bugs ? GitHub )
>>
>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>
>>> My first thought was that this application should not work
>>
>> I agree with that. Anything located in EAR/lib cannot really "see"
> into WAR.
>> Hence the bean with @Specializes (in WAR) will disable the original
> bean (in EAR/lib) and the injection cannot be performed as
>> the specialized bean is not visible to the archive in EAR/lib.
>>
>>> I confirmed that this application works fine on OpenWebBeans.
>>
>> The fact that it does NOT work should be in accord with Java EE spec
> and its visibility restrictions.
>> Maybe you should be asking OWB guys why does it work at all?
>>
>> I am no EAR expert but I really think this is Java EE spec (not CDI)
> intended behavior.
>>
>> Matej
>>
>> ----- Original Message -----
>>> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>>> To: weld-dev at lists.jboss.org
>>> Cc: "Tom Evans" <TEVANS at uk.ibm.com>, "Emily Jiang" <EMIJIANG at uk.ibm.com>
>>> Sent: Monday, November 28, 2016 4:56:12 PM
>>> Subject: [weld-dev] Specializes bean in war causes unsatisfied
> resolution                 exception
>>>
>>> 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
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
>
> 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

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Thu Dec  1 07:23:26 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 1 Dec 2016 13:23:26 +0100
Subject: [weld-dev] Specializes bean in war causes unsatisfied
 resolution exception
In-Reply-To: <464bd731-7e99-854a-3100-0cad179bd909@redhat.com>
References: <OFBADD4EE6.C246EA51-ON00258079.005776DA-80258079.00578D21@notes.na.collabserv.com>
	<425811502.514922.1480399585459.JavaMail.zimbra@redhat.com>
	<99d4d597-fd16-4a55-327e-8db5556b8b0c@redhat.com>
	<OF7850FB31.6B80D34E-ON0025807B.005D729C-8025807B.005D88AF@notes.na.collabserv.com>
	<464bd731-7e99-854a-3100-0cad179bd909@redhat.com>
Message-ID: <7A86D9FB-41F5-42B5-8DCB-AB358E67A251@yahoo.de>

I have to correct a few things:

a.) This whole scenario is NOT defined in the CDI specification
b.) This scenario in question is defined by the EE umbrella specification
c.) The behaviour of OWB/TomEE is perfectly fine from an EE umbrella perspective
d.) It also absolutely makes sense
e.) See CDI-129. You did blow a whole into Weld a long time ago, now you have to live with it. Otoh that doesn't render the structure and behaviour of EARs useless...
f.) OWB doesn't have this problem as the proxy will resolve the correct instance for each request. A request to any of the other WARs will use the original bean, while a request to the 'special' WAR will use the @Specializes class. This is imo also what makes the most sense for users. 
g.) Weld behaviour renders EARs dead and useless. We could go on and remove them from the EE specs at all in that case... 
h.) And then I wonder why we have Enterprise EE Servers at all if not even EARs work... 
i.) I suggest to seek clarification from Linda and Bill resp the EE umbrella EG.

LieGrue,
strub

> Am 01.12.2016 um 08:57 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
>> Thank you for the prompt replies.
>> 
>> In answer to your question. It is UiSnapshotData which gets injected
>> under OWB.
> 
> Ok, thanks. From my point of view this violates the EE class loading rules.
> 
>> 
>> Regards
>> Benjamin
>> 
>> 
>> 
>> From:        Martin Kouba <mkouba at redhat.com>
>> To:        Matej Novotny <manovotn at redhat.com>, Benjamin
>> Confino/UK/IBM at IBMGB,
>> Cc:        Emily Jiang/UK/IBM at IBMGB, Tom Evans/UK/IBM at IBMGB,
>> weld-dev at lists.jboss.org
>> Date:        29/11/2016 07:42
>> Subject:        Re: [weld-dev] Specializes bean in war causes
>> unsatisfied resolution exception
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> Matej is correct. The specializing bean from the war disables the
>> specialized bean from ear/lib. And since the bean from war is not
>> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
>> unsatisfied dependency exists.
>> 
>> By the way, what instance of SnapshotData gets injected into
>> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
>> war/lib?
>> 
>> Martin
>> 
>> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>>> Hello Benjamin
>>> 
>>> Thanks for well written question!
>>> 
>>>> (You can see the application at was_bugs/was_bug22 at master ?
>>>> thikade/was_bugs ? GitHub )
>>> 
>>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>> 
>>>> My first thought was that this application should not work
>>> 
>>> I agree with that. Anything located in EAR/lib cannot really "see"
>> into WAR.
>>> Hence the bean with @Specializes (in WAR) will disable the original
>> bean (in EAR/lib) and the injection cannot be performed as
>>> the specialized bean is not visible to the archive in EAR/lib.
>>> 
>>>> I confirmed that this application works fine on OpenWebBeans.
>>> 
>>> The fact that it does NOT work should be in accord with Java EE spec
>> and its visibility restrictions.
>>> Maybe you should be asking OWB guys why does it work at all?
>>> 
>>> I am no EAR expert but I really think this is Java EE spec (not CDI)
>> intended behavior.
>>> 
>>> Matej
>>> 
>>> ----- Original Message -----
>>>> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>>>> To: weld-dev at lists.jboss.org
>>>> Cc: "Tom Evans" <TEVANS at uk.ibm.com>, "Emily Jiang" <EMIJIANG at uk.ibm.com>
>>>> Sent: Monday, November 28, 2016 4:56:12 PM
>>>> Subject: [weld-dev] Specializes bean in war causes unsatisfied
>> resolution                 exception
>>>> 
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> weld-dev mailing list
>>>> weld-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>> 
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>> 
>> 
>> 
>> 
>> 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
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev



From john.d.ament at gmail.com  Sat Dec 17 09:15:27 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Sat, 17 Dec 2016 14:15:27 +0000
Subject: [weld-dev] Weld & Groovy
Message-ID: <CAOqetn_e-aChVgpm8C5xy8e5R+TnnWLKoZhSSW8yADWyuQ0VHg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161217/875d2ad7/attachment.html 

From mkouba at redhat.com  Sat Dec 17 10:07:25 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Sat, 17 Dec 2016 16:07:25 +0100
Subject: [weld-dev] Weld & Groovy
In-Reply-To: <CAOqetn_e-aChVgpm8C5xy8e5R+TnnWLKoZhSSW8yADWyuQ0VHg@mail.gmail.com>
References: <CAOqetn_e-aChVgpm8C5xy8e5R+TnnWLKoZhSSW8yADWyuQ0VHg@mail.gmail.com>
Message-ID: <db27511c-dbef-a1b3-53bb-623fc339ce8e@redhat.com>

Yep, this issue [1] is fixed in Weld 3.0.0.Beta1 that we're going to 
release early next week.

Martin

[1]
https://issues.jboss.org/browse/WELD-2255


Dne 17.12.2016 v 15:15 John D. Ament napsal(a):
> 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
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From john.d.ament at gmail.com  Mon Dec 19 21:00:18 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 20 Dec 2016 02:00:18 +0000
Subject: [weld-dev] Does WELD-2260 Need to be fixed for StartMain?
Message-ID: <CAOqetn-PwXBHDUTSs2_UmfVG0cNWBHCDYrRuj2CwmH=QWN3huQ@mail.gmail.com>

Hi,

So I ran into an issue after manually patching to work around WELD-2260.
It didn't work for use cases where StartMain is used to boostrap Weld.  I'm
just not sure if its actually needed.  E.g. the fixes for WELD-2260 may be
good enough that this isn't an issue.

https://github.com/weld/core/pull/1535

Let me know what you think.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161220/d3adbbe6/attachment.html 

From mkouba at redhat.com  Tue Dec 20 03:47:17 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 20 Dec 2016 09:47:17 +0100
Subject: [weld-dev] Does WELD-2260 Need to be fixed for StartMain?
In-Reply-To: <CAOqetn-PwXBHDUTSs2_UmfVG0cNWBHCDYrRuj2CwmH=QWN3huQ@mail.gmail.com>
References: <CAOqetn-PwXBHDUTSs2_UmfVG0cNWBHCDYrRuj2CwmH=QWN3huQ@mail.gmail.com>
Message-ID: <b2ba3a8d-9d30-d677-a030-0ee9b0ad36c3@redhat.com>

Hi John,

I believe it's not necessary. However, it might make sense for other 
reasons. Hm, let's think about this during holidays ;-)

Martin

Dne 20.12.2016 v 03:00 John D. Ament napsal(a):
> Hi,
>
> So I ran into an issue after manually patching to work around
> WELD-2260.  It didn't work for use cases where StartMain is used to
> boostrap Weld.  I'm just not sure if its actually needed.  E.g. the
> fixes for WELD-2260 may be good enough that this isn't an issue.
>
> https://github.com/weld/core/pull/1535
>
> Let me know what you think.
>
> John
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

From mkouba at redhat.com  Wed Dec 21 01:51:22 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 21 Dec 2016 07:51:22 +0100
Subject: [weld-dev] Weld 3.0.0.Beta1 released
Message-ID: <d709f197-5433-de17-8e34-2267b5e5bd89@redhat.com>

http://weld.cdi-spec.org/news/2016/12/19/weld-300Beta1/

NOTE: There are some sync problems and so the artifacts are currently 
only available in JBoss Maven repository.

From john.d.ament at gmail.com  Wed Dec 21 06:42:57 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 21 Dec 2016 11:42:57 +0000
Subject: [weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container
Message-ID: <CAOqetn_m=Vq48FrqG2PH5mDjySQj3Jj=B2Marf3vb5R7wTvd4w@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161221/eeaeaa39/attachment.html 

From mkouba at redhat.com  Thu Dec 22 15:17:59 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 22 Dec 2016 21:17:59 +0100
Subject: [weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container
In-Reply-To: <CAOqetn_m=Vq48FrqG2PH5mDjySQj3Jj=B2Marf3vb5R7wTvd4w@mail.gmail.com>
References: <CAOqetn_m=Vq48FrqG2PH5mDjySQj3Jj=B2Marf3vb5R7wTvd4w@mail.gmail.com>
Message-ID: <0e5802dd-fb75-33ad-8816-94f1f6b1c838@redhat.com>

Hi John,

known issue and fixed in Arquillian Embedded Container Weld 2.0.0.Beta4.

Martin

Dne 21.12.2016 v 12:42 John D. Ament napsal(a):
> 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
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From john.d.ament at gmail.com  Thu Dec 22 15:54:20 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 22 Dec 2016 20:54:20 +0000
Subject: [weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container
In-Reply-To: <0e5802dd-fb75-33ad-8816-94f1f6b1c838@redhat.com>
References: <CAOqetn_m=Vq48FrqG2PH5mDjySQj3Jj=B2Marf3vb5R7wTvd4w@mail.gmail.com>
	<0e5802dd-fb75-33ad-8816-94f1f6b1c838@redhat.com>
Message-ID: <CAOqetn_OHh-5ZxU53YTpm71+h4b+H2sFknnjO1QW_cVtLm5mNw@mail.gmail.com>

Thanks Martin.  Guess I missed that announcement.

John

On Thu, Dec 22, 2016 at 3:18 PM Martin Kouba <mkouba at redhat.com> wrote:

> Hi John,
>
> known issue and fixed in Arquillian Embedded Container Weld 2.0.0.Beta4.
>
> Martin
>
> Dne 21.12.2016 v 12:42 John D. Ament napsal(a):
> > 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
> >
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161222/6e786eac/attachment.html 

From mkouba at redhat.com  Thu Dec 22 16:00:01 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 22 Dec 2016 22:00:01 +0100
Subject: [weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container
In-Reply-To: <CAOqetn_OHh-5ZxU53YTpm71+h4b+H2sFknnjO1QW_cVtLm5mNw@mail.gmail.com>
References: <CAOqetn_m=Vq48FrqG2PH5mDjySQj3Jj=B2Marf3vb5R7wTvd4w@mail.gmail.com>
	<0e5802dd-fb75-33ad-8816-94f1f6b1c838@redhat.com>
	<CAOqetn_OHh-5ZxU53YTpm71+h4b+H2sFknnjO1QW_cVtLm5mNw@mail.gmail.com>
Message-ID: <c3498065-354b-8d43-32c9-4681d1b38fba@redhat.com>

I think there was no announcement yet, it was a quick release ;-)

Martin

Dne 22.12.2016 v 21:54 John D. Ament napsal(a):
> Thanks Martin.  Guess I missed that announcement.
>
> John
>
> On Thu, Dec 22, 2016 at 3:18 PM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Hi John,
>
>     known issue and fixed in Arquillian Embedded Container Weld 2.0.0.Beta4.
>
>     Martin
>
>     Dne 21.12.2016 v 12:42 John D. Ament napsal(a):
>     > 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
>     >
>     >
>     > _______________________________________________
>     > weld-dev mailing list
>     > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/weld-dev
>     >
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic