[jira] [Updated] (OWB-1179) OWB-Arquillian scanner doesn't ignore classes with ClassNotFound and NoClassDefFound

[Mark Struberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated OWB-1179:
---
Fix Version/s: 2.0.0

> OWB-Arquillian scanner doesn't ignore classes with ClassNotFound and 
> NoClassDefFound
> 
>
> Key: OWB-1179
> URL: https://issues.apache.org/jira/browse/OWB-1179
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Arquillian
>Affects Versions: 1.2.8, 1.7.3
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 2.0.0
>
>
> Came across a class which implements a Servlet Filter.
> OWB blows up if the servlet spec api is not on the classpath.
> Sometimes those classes are purely optional. 
> We should imo only log those problems and ignore the class where this 
> happens. 
> That is the same handling we do in the 'real' ScannerService as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: behaviour of URLClassLoader#findResources

[Mark Struberg]

After 2 days of debugging and side by side comparison between old OWB versions 
and OWB-2 I now likely found the problem.

Test is NoNavigationParameterWarFileTest.

In OWB-1.2.x and 1.7.x we did _only_ scan jars with a beans.xml.
For OWB-2.0 I added the full implicit bda handling due to some TCK tests.

That means we now pick up every damn class. 
And there is a funny jar called
DefaultBeanArchiveInformation{bdaUrl='archive://deltaspikeUtils.jar//', 
beanDiscoveryMode=ANNOTATED}
which contains things like
org.openqa.selenium.lift.match.SelectionMatcher
etc.

Those damn classes not only create NoClassDefFound but also LinkingErrors, as 
they try to load native DLLs (which of course fail on my Mac)...
And this crazy jar contains 1300 classes...

The damn guy who added this to DeltaSpike back then in early 2012 calls himself 
'struberg' ;)

The test now passes. Running the full suite right now.

LieGrue,
strub


> Am 09.07.2017 um 22:20 schrieb Romain Manni-Bucau :
> 
> A good test would be to upgrade bval tck module I think. It had some
> requirement "as a container" which can have leaked this behavior.
> 
> Le 9 juil. 2017 22:18, "Mark Struberg"  a écrit :
> 
>> Yes I did hit the single CL case. We basically found it twice in the same
>> CL...
>> That was a clear bug and I fixed it.
>> But I'm currently working on yet another weird issue with the DeltaSpike
>> build and will commit all once I'm done.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 09.07.2017 um 22:09 schrieb Romain Manni-Bucau >> :
>>> 
>>> This is another issue then if we have duplicates in the same loader and
>> not
>>> a hierarchy. Did we identify which one we hit? Set is not a solution for
>>> hierarchy one normally and for single loader case the impl should be
>>> revisited anyway. No?
>>> 
>>> 
>>> 
>>> Le 9 juil. 2017 20:18, "Mark Struberg"  a
>> écrit :
>>> 
 Usually a Set is a good idea. But in case of URLs it's pretty nasty due
>> to
 the equals in URLs might be very expensive as it _might_ do a DNS
>> resolving
 over the internet even ;)
 In OWB we have an own UrlSet for it which at least only does the equals
>> on
 the toExternalForm(). Much better, but not really cheap neither.
 
 LieGrue,
 strub
 
 
> Am 09.07.2017 um 20:04 schrieb John D. Ament :
> 
> If the same URL comes back from multiple classloaders, you may want to
 use
> a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
> checks to the URLStreamHandler, which by default looks at the ref
 attribute
> of the URL.
> 
> I do think you need to delegate up to the parent classloader in case
>> you
> come across a resource that wasn't loaded by OWB's ClassLoader.
> 
> John
> 
> On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com
> 
> wrote:
> 
>> Hi Mark
>> 
>> Shouldnt delegate but if you add "arquillian context" we can need in
 some
>> environment to fake it. If so we can revisit our classloader config to
 makt
>> it assumed and not just a best effort exception (which came from tck
 needs)
>> 
>> Le 9 juil. 2017 12:47, "Mark Struberg"  a
>> écrit :
>> 
>>> Hi!
>>> 
>>> Should the URLClassLoader#findResources really delegate back to it's
>>> parent?
>>> 
>>> It looks like getResources() should give all the resources found for
 the
>>> CL + it's parent chain and findResources should only return the
 resources
>>> from the 'local' path of the current CL.
>>> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse
>> on
>>> this :(
>>> 
>>> With delegating to the parent in findResources we essentially picked
 the
>>> resources up twice.
>>> 
>>> LieGrue,
>>> strub
>> 
 
 
>> 
>> 

Re: behaviour of URLClassLoader#findResources

[Romain Manni-Bucau]

A good test would be to upgrade bval tck module I think. It had some
requirement "as a container" which can have leaked this behavior.

Le 9 juil. 2017 22:18, "Mark Struberg"  a écrit :

> Yes I did hit the single CL case. We basically found it twice in the same
> CL...
> That was a clear bug and I fixed it.
> But I'm currently working on yet another weird issue with the DeltaSpike
> build and will commit all once I'm done.
>
> LieGrue,
> strub
>
>
> > Am 09.07.2017 um 22:09 schrieb Romain Manni-Bucau  >:
> >
> > This is another issue then if we have duplicates in the same loader and
> not
> > a hierarchy. Did we identify which one we hit? Set is not a solution for
> > hierarchy one normally and for single loader case the impl should be
> > revisited anyway. No?
> >
> >
> >
> > Le 9 juil. 2017 20:18, "Mark Struberg"  a
> écrit :
> >
> >> Usually a Set is a good idea. But in case of URLs it's pretty nasty due
> to
> >> the equals in URLs might be very expensive as it _might_ do a DNS
> resolving
> >> over the internet even ;)
> >> In OWB we have an own UrlSet for it which at least only does the equals
> on
> >> the toExternalForm(). Much better, but not really cheap neither.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 09.07.2017 um 20:04 schrieb John D. Ament :
> >>>
> >>> If the same URL comes back from multiple classloaders, you may want to
> >> use
> >>> a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
> >>> checks to the URLStreamHandler, which by default looks at the ref
> >> attribute
> >>> of the URL.
> >>>
> >>> I do think you need to delegate up to the parent classloader in case
> you
> >>> come across a resource that wasn't loaded by OWB's ClassLoader.
> >>>
> >>> John
> >>>
> >>> On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>>
> >>> wrote:
> >>>
>  Hi Mark
> 
>  Shouldnt delegate but if you add "arquillian context" we can need in
> >> some
>  environment to fake it. If so we can revisit our classloader config to
> >> makt
>  it assumed and not just a best effort exception (which came from tck
> >> needs)
> 
>  Le 9 juil. 2017 12:47, "Mark Struberg"  a
>  écrit :
> 
> > Hi!
> >
> > Should the URLClassLoader#findResources really delegate back to it's
> > parent?
> >
> > It looks like getResources() should give all the resources found for
> >> the
> > CL + it's parent chain and findResources should only return the
> >> resources
> > from the 'local' path of the current CL.
> > Is this assumption correct? The ClassLoader JavaDoc is pretty sparse
> on
> > this :(
> >
> > With delegating to the parent in findResources we essentially picked
> >> the
> > resources up twice.
> >
> > LieGrue,
> > strub
> 
> >>
> >>
>
>

Re: behaviour of URLClassLoader#findResources

[Mark Struberg]

Yes I did hit the single CL case. We basically found it twice in the same CL...
That was a clear bug and I fixed it. 
But I'm currently working on yet another weird issue with the DeltaSpike build 
and will commit all once I'm done.

LieGrue,
strub


> Am 09.07.2017 um 22:09 schrieb Romain Manni-Bucau :
> 
> This is another issue then if we have duplicates in the same loader and not
> a hierarchy. Did we identify which one we hit? Set is not a solution for
> hierarchy one normally and for single loader case the impl should be
> revisited anyway. No?
> 
> 
> 
> Le 9 juil. 2017 20:18, "Mark Struberg"  a écrit :
> 
>> Usually a Set is a good idea. But in case of URLs it's pretty nasty due to
>> the equals in URLs might be very expensive as it _might_ do a DNS resolving
>> over the internet even ;)
>> In OWB we have an own UrlSet for it which at least only does the equals on
>> the toExternalForm(). Much better, but not really cheap neither.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 09.07.2017 um 20:04 schrieb John D. Ament :
>>> 
>>> If the same URL comes back from multiple classloaders, you may want to
>> use
>>> a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
>>> checks to the URLStreamHandler, which by default looks at the ref
>> attribute
>>> of the URL.
>>> 
>>> I do think you need to delegate up to the parent classloader in case you
>>> come across a resource that wasn't loaded by OWB's ClassLoader.
>>> 
>>> John
>>> 
>>> On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau >> 
>>> wrote:
>>> 
 Hi Mark
 
 Shouldnt delegate but if you add "arquillian context" we can need in
>> some
 environment to fake it. If so we can revisit our classloader config to
>> makt
 it assumed and not just a best effort exception (which came from tck
>> needs)
 
 Le 9 juil. 2017 12:47, "Mark Struberg"  a
 écrit :
 
> Hi!
> 
> Should the URLClassLoader#findResources really delegate back to it's
> parent?
> 
> It looks like getResources() should give all the resources found for
>> the
> CL + it's parent chain and findResources should only return the
>> resources
> from the 'local' path of the current CL.
> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on
> this :(
> 
> With delegating to the parent in findResources we essentially picked
>> the
> resources up twice.
> 
> LieGrue,
> strub
 
>> 
>> 

Re: behaviour of URLClassLoader#findResources

[Romain Manni-Bucau]

This is another issue then if we have duplicates in the same loader and not
a hierarchy. Did we identify which one we hit? Set is not a solution for
hierarchy one normally and for single loader case the impl should be
revisited anyway. No?



Le 9 juil. 2017 20:18, "Mark Struberg"  a écrit :

> Usually a Set is a good idea. But in case of URLs it's pretty nasty due to
> the equals in URLs might be very expensive as it _might_ do a DNS resolving
> over the internet even ;)
> In OWB we have an own UrlSet for it which at least only does the equals on
> the toExternalForm(). Much better, but not really cheap neither.
>
> LieGrue,
> strub
>
>
> > Am 09.07.2017 um 20:04 schrieb John D. Ament :
> >
> > If the same URL comes back from multiple classloaders, you may want to
> use
> > a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
> > checks to the URLStreamHandler, which by default looks at the ref
> attribute
> > of the URL.
> >
> > I do think you need to delegate up to the parent classloader in case you
> > come across a resource that wasn't loaded by OWB's ClassLoader.
> >
> > John
> >
> > On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau  >
> > wrote:
> >
> >> Hi Mark
> >>
> >> Shouldnt delegate but if you add "arquillian context" we can need in
> some
> >> environment to fake it. If so we can revisit our classloader config to
> makt
> >> it assumed and not just a best effort exception (which came from tck
> needs)
> >>
> >> Le 9 juil. 2017 12:47, "Mark Struberg"  a
> >> écrit :
> >>
> >>> Hi!
> >>>
> >>> Should the URLClassLoader#findResources really delegate back to it's
> >>> parent?
> >>>
> >>> It looks like getResources() should give all the resources found for
> the
> >>> CL + it's parent chain and findResources should only return the
> resources
> >>> from the 'local' path of the current CL.
> >>> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on
> >>> this :(
> >>>
> >>> With delegating to the parent in findResources we essentially picked
> the
> >>> resources up twice.
> >>>
> >>> LieGrue,
> >>> strub
> >>
>
>

Re: behaviour of URLClassLoader#findResources

[Mark Struberg]

Usually a Set is a good idea. But in case of URLs it's pretty nasty due to the 
equals in URLs might be very expensive as it _might_ do a DNS resolving over 
the internet even ;)
In OWB we have an own UrlSet for it which at least only does the equals on the 
toExternalForm(). Much better, but not really cheap neither.

LieGrue,
strub


> Am 09.07.2017 um 20:04 schrieb John D. Ament :
> 
> If the same URL comes back from multiple classloaders, you may want to use
> a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
> checks to the URLStreamHandler, which by default looks at the ref attribute
> of the URL.
> 
> I do think you need to delegate up to the parent classloader in case you
> come across a resource that wasn't loaded by OWB's ClassLoader.
> 
> John
> 
> On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau 
> wrote:
> 
>> Hi Mark
>> 
>> Shouldnt delegate but if you add "arquillian context" we can need in some
>> environment to fake it. If so we can revisit our classloader config to makt
>> it assumed and not just a best effort exception (which came from tck needs)
>> 
>> Le 9 juil. 2017 12:47, "Mark Struberg"  a
>> écrit :
>> 
>>> Hi!
>>> 
>>> Should the URLClassLoader#findResources really delegate back to it's
>>> parent?
>>> 
>>> It looks like getResources() should give all the resources found for the
>>> CL + it's parent chain and findResources should only return the resources
>>> from the 'local' path of the current CL.
>>> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on
>>> this :(
>>> 
>>> With delegating to the parent in findResources we essentially picked the
>>> resources up twice.
>>> 
>>> LieGrue,
>>> strub
>> 

Re: behaviour of URLClassLoader#findResources

[John D. Ament]

If the same URL comes back from multiple classloaders, you may want to use
a Set instead of a List to ensure uniqueness.  URLs delegate uniqueness
checks to the URLStreamHandler, which by default looks at the ref attribute
of the URL.

I do think you need to delegate up to the parent classloader in case you
come across a resource that wasn't loaded by OWB's ClassLoader.

John

On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau 
wrote:

> Hi Mark
>
> Shouldnt delegate but if you add "arquillian context" we can need in some
> environment to fake it. If so we can revisit our classloader config to makt
> it assumed and not just a best effort exception (which came from tck needs)
>
> Le 9 juil. 2017 12:47, "Mark Struberg"  a
> écrit :
>
> > Hi!
> >
> > Should the URLClassLoader#findResources really delegate back to it's
> > parent?
> >
> > It looks like getResources() should give all the resources found for the
> > CL + it's parent chain and findResources should only return the resources
> > from the 'local' path of the current CL.
> > Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on
> > this :(
> >
> > With delegating to the parent in findResources we essentially picked the
> > resources up twice.
> >
> > LieGrue,
> > strub
>

Re: VOTE Release Apache Meecrowave-1.0.0

[Jean-Louis MONTEIRO]

+1
Thank you

Le dim. 9 juil. 2017 à 00:19, Jean-Louis MONTEIRO  a
écrit :

> It's already late. I'll have a look to this one tomorrow if not too late.
>
> Le sam. 8 juil. 2017 à 22:20, Romain Manni-Bucau 
> a écrit :
>
>> +1
>>
>> Le 8 juil. 2017 19:43, "Gerhard Petracek"  a écrit
>> :
>>
>> > +1
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2017-07-08 0:43 GMT+02:00 Mark Struberg :
>> >
>> > > Hi folks!
>> > >
>> > > And finally Meecrowave-1.0.0!
>> > > This is a maintenance version for the EE7 compatible version.
>> > > It's actually the previous 0.3.2 work. We just moved to 1.0.0 to
>> indicate
>> > > that it's production ready.
>> > >
>> > > The following tickets have been resolved since 0.3.1:
>> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > > projectId=12320731=12340988
>> > >
>> > > Bug
>> > >
>> > > • [MEECROWAVE-29] - tomcat 9.0.0.M21 upgrade
>> > > • [MEECROWAVE-34] - meecrowave pidfile option fails with NPE
>> > > • [MEECROWAVE-44] - meecrowave.sh is broken
>> > > • [MEECROWAVE-49] - Returning a binary leads to nullpointers
>> > > • [MEECROWAVE-50] - meecrowave-maven-plugin is not portable
>> > > • [MEECROWAVE-51] - Upgrade dependency versions
>> > > Improvement
>> > >
>> > > • [MEECROWAVE-35] - support application/*+json out of the box
>> > > • [MEECROWAVE-36] - set default max string length to 64x1024
>> > > • [MEECROWAVE-37] - @Context on a field in CDI proxies is
>> broken
>> > > • [MEECROWAVE-38] - drop not needed java 9 workarounds
>> > > • [MEECROWAVE-42] - allow to auto package meecrowave in
>> > > meecrowave:bundle goal
>> > > New Feature
>> > >
>> > > • [MEECROWAVE-30] - Make it easier to reuse Cli
>> > > • [MEECROWAVE-31] - Auto reloading backbone
>> > > • [MEECROWAVE-40] - basic jaxws support if
>> cxf-rt-frontend-jaxws
>> > > is present in meecrowave classloader
>> > > • [MEECROWAVE-41] - make meecrowave:bundle pick up content
>> from
>> > > src/main/meecrowave/conf/*
>> > > • [MEECROWAVE-43] - Introduce @WsMapping annotation to define
>> > > WebService endpoint mapping
>> > > Task
>> > >
>> > > • [MEECROWAVE-32] - upgrade log4j2 to 2.8.2
>> > > • [MEECROWAVE-33] - upgrade johnzon to 1.1.1
>> > > • [MEECROWAVE-46] - Upgrade to Tomcat 9.0.0.M22
>> > > • [MEECROWAVE-47] - CXF 3.1.12 upgrade
>> > > • [MEECROWAVE-52] - Upgrade to OWB-1.7.4
>> > >
>> > >
>> > > Here is the staging repo
>> > > https://repository.apache.org/content/repositories/
>> > > orgapacheopenwebbeans-1029/
>> > >
>> > > And here is the source release:
>> > > https://repository.apache.org/content/repositories/
>> > > orgapacheopenwebbeans-1029/org/apache/meecrowave/meecrowave/1.0.0/
>> > >
>> > >
>> > > Please VOTE:
>> > >
>> > > [+1] yea, let's ship it!
>> > > [+0] meeeh, don't care
>> > > [-1] stop, I found a ${showstopper}
>> > >
>> > > The VOTE is open for 72h
>> > >
>> > > txs and LieGrue,
>> > > strub
>> >
>>
>

Re: behaviour of URLClassLoader#findResources

[Romain Manni-Bucau]

Hi Mark

Shouldnt delegate but if you add "arquillian context" we can need in some
environment to fake it. If so we can revisit our classloader config to makt
it assumed and not just a best effort exception (which came from tck needs)

Le 9 juil. 2017 12:47, "Mark Struberg"  a écrit :

> Hi!
>
> Should the URLClassLoader#findResources really delegate back to it's
> parent?
>
> It looks like getResources() should give all the resources found for the
> CL + it's parent chain and findResources should only return the resources
> from the 'local' path of the current CL.
> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on
> this :(
>
> With delegating to the parent in findResources we essentially picked the
> resources up twice.
>
> LieGrue,
> strub

behaviour of URLClassLoader#findResources

[Mark Struberg]

Hi!

Should the URLClassLoader#findResources really delegate back to it's parent?

It looks like getResources() should give all the resources found for the CL + 
it's parent chain and findResources should only return the resources from the 
'local' path of the current CL. 
Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on this :(

With delegating to the parent in findResources we essentially picked the 
resources up twice.

LieGrue,
strub

Re: OWB-2.0.0 to be released soon

[Mark Struberg]

Hi John!

I've now found a bit time to investigate OWB-2 behaviour in DeltaSpike.
I'm now down to just a few tests and they all seems to be caused by different 
behaviour of arquillian.

There is a test which checks that a resource must only be served a single time 
from the ClassPath.
In this test we package the resource into the ShrinkWrap war. And since the 
OWB-Arquillian adapter does it actually correct, we see this resource twice. 
The first time from the @Deployment of the test, the other time from the test 
classpath.
If i move the original test resource to e.g. testonly/myresource.properties 
then the test passes with OWB. But then it fails with older Weld and OWB 
arquillian versions as they do not properly serve resources from deployment 
archives :(

To sum it up: Yes, it's something we need to work on, but it's not an OWB core 
bug but simply an edge case and portability issue with the various Arquillian 
containers.

Anyway, thanks for catching it and bringing it up!

txs and LieGrue,
strub

> Am 19.06.2017 um 04:47 schrieb John D. Ament :
> 
> Hmm so DeltaSpike is seeing 11 test failures with OWB2.
> 
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20OWB%202.0.0/lastCompletedBuild/testReport/
> 
> CDI Ctrl Servlet - it looks like a weird error, the impl of this bean
> hasn't been changed in 2 years.  Not sure if this is a new validation in
> place.
> 
> ClasspathResourceTest - I'm not sure if the path is getting skewed due to
> duplicate resources, or the same resource being added multiple times.
> 
> JSF & Scheduler look like changes in the dependency structure.  If on
> purpose, I'll push up a fix sometime tomorrow.
> 
> On Sun, Jun 18, 2017 at 10:04 AM Romain Manni-Bucau 
> wrote:
> 
>> 2 things to check before the release:
>> 
>> 1. se API (not covered by tck and poorly covered by us ATM)
>> 2. the fastMatching flag should get removed if we can (created due to 1
>> tck)
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | JavaEE Factory
>> 
>> 
>> 2017-06-18 15:41 GMT+02:00 Mark Struberg :
>> 
>>> OWB itself did always ignore it and log a warning. This code did not get
>>> changed for a while.
>>> 
>>> But we have/had a bug in the arquillian connector which lead to blowing
>>> up on NoClassDefFound.
>>> I need to check whether we fixed this already with another commit.
>>> 
>>> The ticket is https://issues.apache.org/jira/browse/OWB-1179
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 18.06.2017 um 13:45 schrieb John D. Ament :
 
 Just wondering, did you change the behavior when a class isn't found to
 ignore the bean? Prior versions of OWB would throw an exception.
 
 John
 
 On Sat, Jun 17, 2017 at 4:43 PM Mark Struberg  Yes, it should 'just work' afaict.
> We even kept the SPI the same.
> We most likely will add an async event related API for better
>>> integration
> within TomEE in the future.
> But this should still be perfectly backward compatible as OWB will
>>> provide
> a default implementation anyway!
> 
> If you catch any (unexpected) problems then just ping us.
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 17.06.2017 um 22:36 schrieb John D. Ament :
>> 
>> So... just to confirm.  Outside of changing the geronimo specs,
>>> taking a
> OWB 1.x profile that I may have will just work with OWB 2?
>> 
>> John
>> 
>> On Sat, Jun 17, 2017 at 1:53 PM Mark Struberg
>>> 
> wrote:
>> Yes, it is 1:1 backward compatible.
>> 
>> The only thing you need to update is the jcdi and common-annotations
>>> API:
>> 
>> 
>>   org.apache.geronimo.specs
>>   geronimo-annotation_1.3_spec
>>   1.0-SNAPSHOT
>> 
>> 
>> 
>>   org.apache.geronimo.specs
>>   geronimo-jcdi_2.0_spec
>>   1.0-SNAPSHOT
>> 
>> 
>> They will be released this week as well.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 17.06.2017 um 19:41 schrieb Ludovic Pénet :
>>> 
>>> Is it a drop i' remplacement ?
>>> If yes, I would gladky test this works, before test driving the new
> features.
>>> 
>>> Ludovic
>>> 
>>> Le 17 juin 2017 19:38:01 GMT+02:00, Mark Struberg  a écrit :
>>> Hi folks!
>>> 
>>> We are finished with implementing all CDI-2.0 features and now
> successfully pass the standalone TCK!
>>> A recent owb-2.0.0-SNAPSHOT is deployed to the Apache Snapshots