Re: [DISCUSS] move OpenWebBeans core repo to GIT?

[John D. Ament]

+1 it makes life easier for all

On Fri, May 3, 2019, 07:31 Mark Struberg  wrote:

> hi folks!
>
> Do we want to move OWB core to GIT?
>
> wdyt?
>
> I'd be +1
>
> LieGrue,
> strub
>
>

Re: Consistent results for CDI.current().getBeanManager()

[John D. Ament]

This is what I was able to get working.
https://github.com/hammock-project/hammock/commit/8f50242634b370b12c1f291a1f3fc83e3d7533c2

However, I'll be honest and say it seems like a big gap that OWB isn't
dealing with this.  I haven't done thorough testing, but if I'm using SE
and an executor service, I could likely hit a similar issue right?

On Mon, Apr 9, 2018 at 11:10 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Yes but this will not work for you John since you will end up with 3
> classloaders instead of 1 still and no singleton service unifying it.
>
> What can work if you use the default singleton is to register the
> existing context for other classloaders:
>
> DefaultSingletonService.class.cast(singletonInstance).register(loader,
> context);
>
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-09 16:37 GMT+02:00 John D. Ament <johndam...@apache.org>:
> > Did you mean ClassLoaderLock in meecrowave?  Or something like the Rule
> > defined by MonoMeecrowave?
> >
> > John
> >
> > On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <strub...@yahoo.de.invalid>
> > wrote:
> >
> >> John, another proposal. I've implemented the same for the Meecrowave
> JUnit
> >> integration.
> >> Could you create a 'client' UrlClassLoader with no own URLs?
> >> And then per your 'slice' switch the TCCL accordingly?
> >>
> >> That way you will get perfect isolation.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> >:
> >> >
> >> > 2018-04-09 14:07 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >> >
> >> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >> >>>
> >> >>>> Yeah, I hit that.  I was able to get around the listener issue, but
> >> >> then
> >> >>>> this still occurred (its actually within OwbCDI where it fails
> next).
> >> >>>>
> >> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how
> OWB
> >> >>>> works.
> >> >>>>
> >> >>>
> >> >>> Hmm why? it is as important than in other cases.
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> Is there a way that CDI.current() could resolve to the OWBContainer
> >> >> that
> >> >>>> was used to bootstrap?  Since SeContainer implements Instance,
> most of
> >> >>> the
> >> >>>> work would be there already for the CDI object.
> >> >>>>
> >> >>>> Or should OWB somehow override the finder in OWBInitializer
> >> (initialize
> >> >>> or
> >> >>>> newContainer methods I had in mind).
> >> >>>>
> >> >>>
> >> >>> Think you really want to impl a finder for your particular case.
> Sounds
> >> >>> like you want a singleton and not a webapp instance but still
> >> deploying a
> >> >>> webapp, no?
> >> >>>
> >> >>>
> >> >> I was thinking its blocked by the spec, but you have
> >> >> your SeContainerSelector so I can replace with my own impl.  Not
> ideal,
> >> >> since SE really should just mean single container but I suppose it
> will
> >> >> work.
> >> >>
> >> >
> >> > Not sure, in meecrowave or tomee (to come) we support it for N
> contexts
> >> > potentially.
> >> > Spec allows to manipulate one context but still deploy N (N>1) which
> is
> >> > important for packaged apps (=including N elementary apps).
> >> >
> >> > If you don't respect the TCCL then you are probably broken with most
> >> > mainstream libs - it is sadly common to use the classloader as a key
> of a
> >> > cache - so maybe the first step is to fix that?
> >> > Forcing tomcat or jetty to reuse the launching classloader is quite
> easy
> >> so
> >> > maybe the way to go for your case?
> >> >
> >> >
> >> >>
> >> >>
> >

Re: Consistent results for CDI.current().getBeanManager()

[John D. Ament]

Did you mean ClassLoaderLock in meecrowave?  Or something like the Rule
defined by MonoMeecrowave?

John

On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> John, another proposal. I've implemented the same for the Meecrowave JUnit
> integration.
> Could you create a 'client' UrlClassLoader with no own URLs?
> And then per your 'slice' switch the TCCL accordingly?
>
> That way you will get perfect isolation.
>
> LieGrue,
> strub
>
>
> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > 2018-04-09 14:07 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >
> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >>>
> >>>> Yeah, I hit that.  I was able to get around the listener issue, but
> >> then
> >>>> this still occurred (its actually within OwbCDI where it fails next).
> >>>>
> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
> >>>> works.
> >>>>
> >>>
> >>> Hmm why? it is as important than in other cases.
> >>>
> >>>
> >>>>
> >>>> Is there a way that CDI.current() could resolve to the OWBContainer
> >> that
> >>>> was used to bootstrap?  Since SeContainer implements Instance, most of
> >>> the
> >>>> work would be there already for the CDI object.
> >>>>
> >>>> Or should OWB somehow override the finder in OWBInitializer
> (initialize
> >>> or
> >>>> newContainer methods I had in mind).
> >>>>
> >>>
> >>> Think you really want to impl a finder for your particular case. Sounds
> >>> like you want a singleton and not a webapp instance but still
> deploying a
> >>> webapp, no?
> >>>
> >>>
> >> I was thinking its blocked by the spec, but you have
> >> your SeContainerSelector so I can replace with my own impl.  Not ideal,
> >> since SE really should just mean single container but I suppose it will
> >> work.
> >>
> >
> > Not sure, in meecrowave or tomee (to come) we support it for N contexts
> > potentially.
> > Spec allows to manipulate one context but still deploy N (N>1) which is
> > important for packaged apps (=including N elementary apps).
> >
> > If you don't respect the TCCL then you are probably broken with most
> > mainstream libs - it is sadly common to use the classloader as a key of a
> > cache - so maybe the first step is to fix that?
> > Forcing tomcat or jetty to reuse the launching classloader is quite easy
> so
> > maybe the way to go for your case?
> >
> >
> >>
> >>
> >>>
> >>>>
> >>>> John
> >>>>
> >>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg
> <strub...@yahoo.de.invalid
> >>>
> >>>> wrote:
> >>>>
> >>>>> This is kind of a circular issue.
> >>>>>
> >>>>> Look at WebBeansContext#getInstance()
> >>>>>
> >>>>> public static WebBeansContext getInstance()
> >>>>> {
> >>>>>WebBeansContext webBeansContext =
> >>>>> WebBeansFinder.getSingletonInstance();
> >>>>>
> >>>>>
> >>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
> >> TCCL
> >>> to
> >>>>> look up the WebBeansContext.
> >>>>>
> >>>>> So even if you create a WebBeansContext with an explicit
> >> FinderService,
> >>>> it
> >>>>> would not make much difference I fear.
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> >>>> rmannibu...@gmail.com
> >>>>>> :
> >>>>>>
> >>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <johndam...@apache.org> a
> >>> écrit
> >>>> :
> >>>>>>
> >>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> >>>> r

Re: Consistent results for CDI.current().getBeanManager()

[John D. Ament]

Yeah, I hit that.  I was able to get around the listener issue, but then
this still occurred (its actually within OwbCDI where it fails next).

Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
works.

Is there a way that CDI.current() could resolve to the OWBContainer that
was used to bootstrap?  Since SeContainer implements Instance, most of the
work would be there already for the CDI object.

Or should OWB somehow override the finder in OWBInitializer (initialize or
newContainer methods I had in mind).

John

On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> This is kind of a circular issue.
>
> Look at WebBeansContext#getInstance()
>
> public static WebBeansContext getInstance()
> {
> WebBeansContext webBeansContext =
> WebBeansFinder.getSingletonInstance();
>
>
> And WebBeansFinder.getSingletonInstance() in turn again uses the TCCL to
> look up the WebBeansContext.
>
> So even if you create a WebBeansContext with an explicit FinderService, it
> would not make much difference I fear.
>
> LieGrue,
> strub
>
>
> > Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Le 9 avr. 2018 02:33, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> >
> >> Is it in hammock? Did you force the webapp container to use the
> >> appclassloader in case of a secontainer?
> >>
> >
> > How would I do that?  You mean inside of Tomcat?  I'd much rather put
> > together a solution that works independent of a container, and in SE
> since
> > I really want there to be a single context for the JVM.
> >
> >
> >
> > Yes. It is actually the cleanest if you dont support multi apps
> deployment
> > cause this way you unify all libs look ups (ds, beanutils, mp config,
> )
> >
> >
> > I've narrowed the issue down to the classloader used once the servlet
> > listener starts up.  It is in fact using the webapp classloader at that
> > point.
> >
> > I was thinking a cleaner solution would be to create an additional
> > constructor in WebBeansConfigurationListener that took the proper
> > WebBeansContext to look up, instead of relying on the singleton service
> to
> > look one up.
> >
> >
> > It is the same, you just have to set the singleton service matching your
> > environment.
> >
> > You can also delay the cdi startup to be done in the web context with the
> > right tccl.
> >
> >
> >
> >>
> >> Le 7 mars 2018 03:27, "John D. Ament" <johndam...@apache.org> a écrit :
> >>
> >>> That pretty much sums up the issue.
> >>>
> >>> When the app starts, the current thread is main.
> >>> When the webapp launches, it doesn't seem to load it properly.  The
> good
> >>> news is if I override to the main class's thread, it still doesn't
> work.
> >>> So there's some inherent flaws.  This was by overriding
> SingletonService
> >> to
> >>> use the same OWB container.
> >>>
> >>> I was able to replicate the issue using pain container start up using
> an
> >>> older pattern as well
> >>>
> >>> lifecycle =
> >>> WebBeansContext.currentInstance().getService(ContainerLifecycle.class);
> >>> lifecycle.startApplication(null);
> >>>
> >>> I'm going to test to see if I see this fixed on 1.x and broken on 2.x.
> >>>
> >>> John
> >>>
> >>> On Mon, Mar 5, 2018 at 8:04 AM Mark Struberg <strub...@yahoo.de.invalid
> >
> >>> wrote:
> >>>
> >>>> Hmm, that should not be necessary at all.
> >>>>
> >>>> The containers should resolve to the same BeanManager, UNLESS you have
> >> a
> >>>> different ClassLoader!
> >>>> But in that case almost everything will be broken anyways.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 05.03.2018 um 12:31 schrieb John D. Ament <johndam...@apache.org
> >>> :
> >>>>>
> >>>>> Yes, so that's basically what I'm seeing at issue.  The TCCL's are
> >>>> different, different hierarchies, and as a result it cannot find the
> >>>> BeanManagerImpl.
> >>>>>
> >>>>> So here's the tricky part.  I want to

Re: Consistent results for CDI.current().getBeanManager()

[John D. Ament]

On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Is it in hammock? Did you force the webapp container to use the
> appclassloader in case of a secontainer?
>

How would I do that?  You mean inside of Tomcat?  I'd much rather put
together a solution that works independent of a container, and in SE since
I really want there to be a single context for the JVM.

I've narrowed the issue down to the classloader used once the servlet
listener starts up.  It is in fact using the webapp classloader at that
point.

I was thinking a cleaner solution would be to create an additional
constructor in WebBeansConfigurationListener that took the proper
WebBeansContext to look up, instead of relying on the singleton service to
look one up.


>
> Le 7 mars 2018 03:27, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > That pretty much sums up the issue.
> >
> > When the app starts, the current thread is main.
> > When the webapp launches, it doesn't seem to load it properly.  The good
> > news is if I override to the main class's thread, it still doesn't work.
> > So there's some inherent flaws.  This was by overriding SingletonService
> to
> > use the same OWB container.
> >
> > I was able to replicate the issue using pain container start up using an
> > older pattern as well
> >
> > lifecycle =
> > WebBeansContext.currentInstance().getService(ContainerLifecycle.class);
> > lifecycle.startApplication(null);
> >
> > I'm going to test to see if I see this fixed on 1.x and broken on 2.x.
> >
> > John
> >
> > On Mon, Mar 5, 2018 at 8:04 AM Mark Struberg <strub...@yahoo.de.invalid>
> > wrote:
> >
> > > Hmm, that should not be necessary at all.
> > >
> > > The containers should resolve to the same BeanManager, UNLESS you have
> a
> > > different ClassLoader!
> > > But in that case almost everything will be broken anyways.
> > >
> > > LieGrue,
> > > strub
> > >
> > > > Am 05.03.2018 um 12:31 schrieb John D. Ament <johndam...@apache.org
> >:
> > > >
> > > > Yes, so that's basically what I'm seeing at issue.  The TCCL's are
> > > different, different hierarchies, and as a result it cannot find the
> > > BeanManagerImpl.
> > > >
> > > > So here's the tricky part.  I want to go from the SeContainer to the
> > > WebBeansContext.  Do I just use WebBeansContext.getCurrentInstance()
> and
> > > then override the SingletonService?
> > > >
> > > > On 2018/03/05 07:40:05, Mark Struberg <strub...@yahoo.de.INVALID>
> > wrote:
> > > >> +1
> > > >>
> > > >> The 'core' object in OWB is the WebBeansContext. This contains the 1
> > > BeanManager for the 'application'.
> > > >>
> > > >> The lookup is done through the Finder. By default it's basically a
> > > Map<ClassLoader, WebBeansContext>.
> > > >> But you can change this to a custom one.
> > > >>
> > > >> Btw CDI.current() will always give you an InjectableBeanManager
> which
> > > is basically a thin wrapper which is Serializable.
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >>> Am 05.03.2018 um 06:44 schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > > >>>
> > > >>> Hi John
> > > >>>
> > > >>> The lookup is done depending your finder impl. By default it is by
> > > >>> classloader which means, if you dont end up using the same
> > > beanmanagerimpl,
> > > >>> you dont have the right tccl in different places - which has
> impacts
> > as
> > > >>> well.
> > > >>>
> > > >>> The wrapper instance is not that important here, only the delegate
> > one
> > > >>>
> > > >>>
> > > >>> Le 5 mars 2018 02:19, "John D. Ament" <johndam...@apache.org> a
> > > écrit :
> > > >>>
> > > >>>> Hi
> > > >>>>
> > > >>>> So I'm noticing when CDI.current().getBeanManager() is called, it
> > > returns a
> > > >>>> new InjectableBeanManager instance.  I have a custom OWBListener (
> > > >>>> https://github.com/hammock-project/hammock/blob/master/
> > > >>>> bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/
> > > >>>> owb/OWBListener.java)
> > > >>>> which handles the lifecycle references in the servlet container.
> I
> > > don't
> > > >>>> want to start the application, because its already been started by
> > > the SE
> > > >>>> container so my custom version doesn't do that.
> > > >>>>
> > > >>>> However, I've noticed that the underlying BeanManager is not the
> > same
> > > as
> > > >>>> the one used by the SE initialization.  Is this on purpose?  Is
> > there
> > > >>>> something special that has to be done so that the underlying
> > > >>>> BeanManagerImpl on WebBeansContext.getInstance().
> > getBeanManagerImpl()
> > > >>>> returns the one created via SE?
> > > >>>>
> > > >>>> John
> > >
> > >
> >
>

Re: Consistent results for CDI.current().getBeanManager()

[John D . Ament]

Yes, so that's basically what I'm seeing at issue.  The TCCL's are different, 
different hierarchies, and as a result it cannot find the BeanManagerImpl.

So here's the tricky part.  I want to go from the SeContainer to the 
WebBeansContext.  Do I just use WebBeansContext.getCurrentInstance() and then 
override the SingletonService?

On 2018/03/05 07:40:05, Mark Struberg <strub...@yahoo.de.INVALID> wrote: 
> +1
> 
> The 'core' object in OWB is the WebBeansContext. This contains the 1 
> BeanManager for the 'application'.
> 
> The lookup is done through the Finder. By default it's basically a 
> Map<ClassLoader, WebBeansContext>.
> But you can change this to a custom one.
> 
> Btw CDI.current() will always give you an InjectableBeanManager which is 
> basically a thin wrapper which is Serializable.
> 
> LieGrue,
> strub
> 
> 
> 
> > Am 05.03.2018 um 06:44 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
> > 
> > Hi John
> > 
> > The lookup is done depending your finder impl. By default it is by
> > classloader which means, if you dont end up using the same beanmanagerimpl,
> > you dont have the right tccl in different places - which has impacts as
> > well.
> > 
> > The wrapper instance is not that important here, only the delegate one
> > 
> > 
> > Le 5 mars 2018 02:19, "John D. Ament" <johndam...@apache.org> a écrit :
> > 
> >> Hi
> >> 
> >> So I'm noticing when CDI.current().getBeanManager() is called, it returns a
> >> new InjectableBeanManager instance.  I have a custom OWBListener (
> >> https://github.com/hammock-project/hammock/blob/master/
> >> bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/
> >> owb/OWBListener.java)
> >> which handles the lifecycle references in the servlet container.  I don't
> >> want to start the application, because its already been started by the SE
> >> container so my custom version doesn't do that.
> >> 
> >> However, I've noticed that the underlying BeanManager is not the same as
> >> the one used by the SE initialization.  Is this on purpose?  Is there
> >> something special that has to be done so that the underlying
> >> BeanManagerImpl on WebBeansContext.getInstance().getBeanManagerImpl()
> >> returns the one created via SE?
> >> 
> >> John
> >> 
> 
> 

Consistent results for CDI.current().getBeanManager()

[John D. Ament]

Hi

So I'm noticing when CDI.current().getBeanManager() is called, it returns a
new InjectableBeanManager instance.  I have a custom OWBListener (
https://github.com/hammock-project/hammock/blob/master/bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/owb/OWBListener.java)
which handles the lifecycle references in the servlet container.  I don't
want to start the application, because its already been started by the SE
container so my custom version doesn't do that.

However, I've noticed that the underlying BeanManager is not the same as
the one used by the SE initialization.  Is this on purpose?  Is there
something special that has to be done so that the underlying
BeanManagerImpl on WebBeansContext.getInstance().getBeanManagerImpl()
returns the one created via SE?

John

Re: Meecrowave java 9 support

[John D. Ament]

If you explicitly add the dependencies that Ravi's mentioning, you'll get
the correct output without --add-modules.  However, it is a hard dependency
for CXF to include these dependencies.  Some of their core feature work is
based on JAX-WS features, so there's no way to avoid the dependency.

On Mon, Dec 18, 2017 at 8:52 AM Romain Manni-Bucau 
wrote:

> Hi
>
> I hope to get rid of the dependency completely since we shouldn't need it
> at all but for now the way to have it working is to use --add-modules. Feel
> free to do a PR to remove it completely if you want, it would be very
> welcomed.
>
> side note: we also need to upgrade OWB when released to support java 9.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn 
>
> 2017-12-18 12:08 GMT+01:00 Ravisankar Challa :
>
> > Meecrowave not working with java 9 (using latest snapshot of
> openwebbeans)
> >
> > Caused by: org.apache.webbeans.exception.WebBeansException:
> > java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> > at
> > org.apache.webbeans.event.ObserverMethodImpl.notify(
> > ObserverMethodImpl.java:371)
> > ~[openwebbeans-impl-2.0.3-SNAPSHOT.jar:2.0.3-SNAPSHOT]
> >
> > JEP - http://openjdk.java.net/jeps/320 - Removes the below modules
> >
> > java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services
> > Metadata)
> > java.xml.bind (JAXB)
> > java.activation (JAF)
> > java.xml.ws.annotation (Common Annotations)
> > java.corba (CORBA)
> > java.transaction (JTA)
> >
> > java.se.ee (Aggregator module for the six modules above)
> > jdk.xml.ws (Tools for JAX-WS)
> > jdk.xml.bind (Tools for JAXB)
> >
> > Adding --add-modules java.xml.bind or java.se.ee will work for now but
> it
> > would be nice if we have dependencies part of meecrowave.
> >
> > Starts after adding these below 2 dependencies to pom.xml
> >
> > 
> > javax.xml.bind
> > jaxb-api
> > 2.3.0
> > 
> > 
> > javax.activation
> > activation
> > 1.1.1
> > 
> >
> > 
> >
>

Re: Injecting Array types as fields

[John D. Ament]

We register a single bean per injection point.  That bean handles the look
up but only returns the type of the injection point.  But its still a bit
odd.

I added CDI.current().select(int[].class, new ConfigProperty...) to my test
to see what happens.  In Weld, I see it call the producer but fail (because
of missing annotations).  In OWB, it doesn't call the bean's create method
at all.  Which makes me think its an OWB issue.  I'll see if I can come up
with a local test case.

John

On Mon, Dec 18, 2017 at 8:50 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Isn't it cause we reuse a generic producer?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> 2017-12-18 13:01 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> > That's good that this works. However, I wonder if my issue is specific to
> > 3rd Party Bean creation?  Same problem seems to be on both OWB and Weld,
> > which makes me think it's an impl issue, but I can't think of anything
> else
> > required on the impl side.
> >
> > Bean.getTypes() correctly returns String[].class
> > qualifiers are correct
> >
> > The create method on the bean is never invoked, the injection point is
> > always null.
> >
> > John
> >
> > On Mon, Dec 18, 2017 at 3:59 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Works for me:
> > >
> > > public class ArrayProducerTest extends AbstractUnitTest
> > > {
> > >
> > > @Test
> > > public void test()
> > > {
> > > startContainer(StringProducer.class);
> > >
> > > final String[] produced1 = getInstance(String[].class);
> > > final StringProducer[] produced2 =
> > > getInstance(StringProducer[].class);
> > >
> > > Assert.assertEquals(1, produced1.length);
> > > Assert.assertEquals("string", produced1[0]);
> > >
> > > Assert.assertEquals(1, produced2.length);
> > > Assert.assertNotNull(produced2[0]);
> > >
> > > shutDownContainer();
> > >
> > > }
> > >
> > > public static class StringProducer
> > > {
> > > @Produces
> > > public String[] produces()
> > > {
> > > return new String[] { "string" };
> > > }
> > >
> > > @Produces
> > > public StringProducer[] produces2()
> > > {
> > > return new StringProducer[] { this };
> > > }
> > > }
> > >
> > > }
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau>
> > >
> > > 2017-12-18 9:15 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
> > >
> > > > I think it should work.
> > > >
> > > > Could you please create a ticket?
> > > >
> > > > txs and LieGrue,
> > > > strub
> > > >
> > > >
> > > > > Am 18.12.2017 um 03:47 schrieb John D. Ament <
> johndam...@apache.org
> > >:
> > > > >
> > > > > MP Config is adding arrays as a valid type for config properties.
> In
> > > > doing
> > > > > so, without making any changes to Geronimo Config I get this
> failure
> > > (not
> > > > > what I'm expecting, I'm expecting no valid beans at this point):
> > > > >
> > > > > arquillianBeforeClass(org.eclipse.microprofile.config.
> > > > tck.ClassConverterTest)
> > > > > Time elapsed: 0.022 sec  <<< FAILURE!
> > > > > org.apache.webbeans.exception.WebBeansConfigurationException:
> > > > > java.lang.IllegalArgumentException: Can't determine the type for
> > > Class > > > > extends Object>[]
> > > > > at org.apache.webbeans.config.BeansDeployer.deploy(
> > &

Re: Injecting Array types as fields

[John D. Ament]

That's good that this works. However, I wonder if my issue is specific to
3rd Party Bean creation?  Same problem seems to be on both OWB and Weld,
which makes me think it's an impl issue, but I can't think of anything else
required on the impl side.

Bean.getTypes() correctly returns String[].class
qualifiers are correct

The create method on the bean is never invoked, the injection point is
always null.

John

On Mon, Dec 18, 2017 at 3:59 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Works for me:
>
> public class ArrayProducerTest extends AbstractUnitTest
> {
>
> @Test
> public void test()
> {
> startContainer(StringProducer.class);
>
> final String[] produced1 = getInstance(String[].class);
> final StringProducer[] produced2 =
> getInstance(StringProducer[].class);
>
> Assert.assertEquals(1, produced1.length);
> Assert.assertEquals("string", produced1[0]);
>
> Assert.assertEquals(1, produced2.length);
> Assert.assertNotNull(produced2[0]);
>
> shutDownContainer();
>
> }
>
> public static class StringProducer
> {
> @Produces
> public String[] produces()
> {
> return new String[] { "string" };
> }
>
> @Produces
> public StringProducer[] produces2()
> {
> return new StringProducer[] { this };
> }
> }
>
> }
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> 2017-12-18 9:15 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
>
> > I think it should work.
> >
> > Could you please create a ticket?
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 18.12.2017 um 03:47 schrieb John D. Ament <johndam...@apache.org>:
> > >
> > > MP Config is adding arrays as a valid type for config properties.  In
> > doing
> > > so, without making any changes to Geronimo Config I get this failure
> (not
> > > what I'm expecting, I'm expecting no valid beans at this point):
> > >
> > > arquillianBeforeClass(org.eclipse.microprofile.config.
> > tck.ClassConverterTest)
> > > Time elapsed: 0.022 sec  <<< FAILURE!
> > > org.apache.webbeans.exception.WebBeansConfigurationException:
> > > java.lang.IllegalArgumentException: Can't determine the type for
> Class > > extends Object>[]
> > > at org.apache.webbeans.config.BeansDeployer.deploy(
> > BeansDeployer.java:351)
> > > at
> > > org.apache.webbeans.lifecycle.AbstractLifeCycle.bootstrapApplication(
> > AbstractLifeCycle.java:137)
> > > at
> > > org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(
> > AbstractLifeCycle.java:103)
> > > at
> > >
> org.apache.webbeans.arquillian.standalone.OwbStandaloneContainer.deploy(
> > OwbStandaloneContainer.java:118)
> > > 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)
> > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(
> > NativeMethodAccessorImpl.java:62)
> > > at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:498)
> > >
> > > It seems that OWB can't handle array types as fields for injection.  Is
> > > this in fact expected?  This is even though for any given class T,
> > > T[].class is a valid object.
> >
> >
>

Injecting Array types as fields

[John D. Ament]

MP Config is adding arrays as a valid type for config properties.  In doing
so, without making any changes to Geronimo Config I get this failure (not
what I'm expecting, I'm expecting no valid beans at this point):

arquillianBeforeClass(org.eclipse.microprofile.config.tck.ClassConverterTest)
Time elapsed: 0.022 sec  <<< FAILURE!
org.apache.webbeans.exception.WebBeansConfigurationException:
java.lang.IllegalArgumentException: Can't determine the type for Class[]
at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:351)
at
org.apache.webbeans.lifecycle.AbstractLifeCycle.bootstrapApplication(AbstractLifeCycle.java:137)
at
org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:103)
at
org.apache.webbeans.arquillian.standalone.OwbStandaloneContainer.deploy(OwbStandaloneContainer.java:118)
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)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)

It seems that OWB can't handle array types as fields for injection.  Is
this in fact expected?  This is even though for any given class T,
T[].class is a valid object.

Re: Different BeanManagers in use

[John D. Ament]

These are different BeanManagerimpls

On Oct 5, 2017 7:33 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:

> Hi John,
>
> you get a new InjectableBeanManager each time yes which is wrapping the
> same BeanManagerImpl.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> 2017-10-05 13:18 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Hi,
> >
> > I'm troubleshooting an issue in Hammock where when using OWB 2.0.1 +
> Tomcat
> > 9 M26, the results of CDI.current().getBeanManager() give back different
> > BeanManager instances.
> >
> > In fact, calling WebBeansContext.currentInstance() is returning a
> > different
> > instance on each invocation in separate threads.  It's almost as if the
> > parent OWB instance is shutting down and a new instance is being created.
> > Switching back to the main thread, I lose the original instance that I
> had.
> >
> > John
> >
>

Different BeanManagers in use

[John D. Ament]

Hi,

I'm troubleshooting an issue in Hammock where when using OWB 2.0.1 + Tomcat
9 M26, the results of CDI.current().getBeanManager() give back different
BeanManager instances.

In fact, calling WebBeansContext.currentInstance() is returning a different
instance on each invocation in separate threads.  It's almost as if the
parent OWB instance is shutting down and a new instance is being created.
Switching back to the main thread, I lose the original instance that I had.

John

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

Ok, I was able to get a decent reproducer on this, wrote up my notes in
https://issues.apache.org/jira/browse/OWB-1216

John

On Mon, Sep 11, 2017 at 8:21 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Well, the IP resolving is always done against getTypes().
> But I think this is uninamously understood the same in all impls, isn't?
>
> The only discussion I remembered was around the getTypes() vs
> getBeanClass() for proxing. Thus my answers.
>
> Again: test would be cool, then we could help much faster.
>
> txs and LieGrue,
> strub
>
>
> > Am 11.09.2017 um 12:36 schrieb John D. Ament <johndam...@apache.org>:
> >
> > So remember.  The question here is about injection point, not the bean
> > type.  Some of the problems described are deployment problems.  E.g. you
> > try to inject using a type that's forbidden because of @Typed, then that
> > should result in UnsatisfiedDependencies, at deployment time.
> >
> > On Mon, Sep 11, 2017 at 6:07 AM Arne Limburg <
> arne.limb...@openknowledge.de>
> > wrote:
> >
> >> Yes, that's interesting, you could get a proxy that directly extends
> >> Object. So you could invoke no method on that bean (except toString(),
> >> equals(...), hashCode(), ...)
> >>
> >>
> >> Does not seem to be usefull at all
> >>
> >> 
> >> Von: Mark Struberg <strub...@yahoo.de.INVALID>
> >> Gesendet: Montag, 11. September 2017 11:13:20
> >> An: openwebbeans-dev
> >> Betreff: Re: Odd behavior in InjectionPointProducer
> >>
> >> yes I'm also really sure it must get resolved as per the spec.
> >> The question is just which proxy you get once there is also a normal
> scope
> >> on the class
> >>
> >>
> >> @Named
> >> @Typed
> >> @ApplicationScoped
> >> public class MyBla extends SomeComplicatedThing implements
> AFewInterfaces {
> >> ...
> >> }
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 11.09.2017 um 09:41 schrieb Arne Limburg <
> >> arne.limb...@openknowledge.de>:
> >>>
> >>> Quick look into the spec
> >> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#name_resolution
> >>>
> >>> @Named
> >>>
> >>> @Typed()
> >>>
> >>> seems to be valid and the bean should be found by EL.
> >>>
> >>> 
> >>> Von: Romain Manni-Bucau <rmannibu...@gmail.com>
> >>> Gesendet: Montag, 11. September 2017 09:31:38
> >>> An: openwebbeans-dev
> >>> Betreff: Re: Odd behavior in InjectionPointProducer
> >>>
> >>> Not sure it is 100% related but looks like a bean without types so not
> >> even
> >>> sure @Named should be "matchable" since you dont match types at all (we
> >>> often used @Typed = @Vetoed in CDI 1.0)
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >>> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>>
> >>> 2017-09-11 9:29 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >>>
> >>>> Btw, what I've seen quite a few times is the following:
> >>>>
> >>>> @Named
> >>>> @Typed()
> >>>> public class MyBla extends SomeComplicatedThing implements
> >> AFewInterfaces {
> >>>> ...
> >>>> }
> >>>>
> >>>> Means the @Typed got purely used to not have it picked up by type but
> >> only
> >>>> via EL.
> >>>> And in that case the proxy in Weld is most likely not working?
> >>>> Is this a valid use case?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> Surely the one to test:
> >>>>> https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/
> >>>> main/java/o

[jira] [Created] (OWB-1216) InjectionPoint.getType() returns wrong type for produced beans

[John D. Ament (JIRA)]

John D. Ament created OWB-1216:
--

 Summary: InjectionPoint.getType() returns wrong type for produced 
beans
 Key: OWB-1216
 URL: https://issues.apache.org/jira/browse/OWB-1216
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


Assuming I have a producer (same thing happens for a custom registered 3rd 
party bean, this is just easier to demonstrate):

{code}
public class MyProducer {
@Produces
@SomeQualifier
public String doProducer(InjectionPoint ip) {
return ip.getType().toString();
}
}
{code}

As well as the following injection point (with test):

{code}
@Inject
@SomeQualifier
private String myString;

@Test
public void shouldBeStringType() {
assertThat(myString).isEqualTo(String.class.toString());
}
{code}

The expectation is that the value of {{myString}} is {{java.lang.String}} but 
actually the value is the producer {{MyProducer}}.  We should be relying on the 
injection point's value, not the producer class.  It seems that it uses the 
value of {{getBeanClass}}



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

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

Good catch.  We need a getInjectionPoint().getType() check on
https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java#L99

On Mon, Sep 11, 2017 at 3:23 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Surely the one to test:
>
> https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-09-11 9:20 GMT+02:00 Arne Limburg <arne.limb...@openknowledge.de>:
>
> > I'm with Mark here,
> >
> > InjectionPoint#getType() should return a ParameterizedType Instance
> >
> > So in the code below we simply should return parameterizedType I think.
> >
> > Would that pass the TCK? If yes, we definitely should file a TCK issue,
> > there seems to be a test missing.
> >
> >
> > Cheers,
> >
> > Arne
> >
> > 
> > Von: Mark Struberg <strub...@yahoo.de.INVALID>
> > Gesendet: Montag, 11. September 2017 09:04:41
> > An: openwebbeans-dev
> > Betreff: Re: Odd behavior in InjectionPointProducer
> >
> > Hmm, if you have a class
> >
> > public class Bla {
> >   private @Inject Instance myInstance;
> > }
> >
> > then I'd asssume that the InjectionPoint.getType for myInstance would be
> > Instance and not Foo alone.
> >
> > > The problem is that Bean.getBeanClass() can never be null, by
> definition,
> > > but also should not be used for type safe resolution (we actually had a
> > > discussion about this on the EG list as I had the opposite belief).
> >
> > Yes, there was a discussion which never got finished...
> >
> > Weld guys assume that they can infere the proxy type of a bean just by
> > getTypes().
> > I don't believe that. Especially if @Typed is involved or if the real
> > AnnotatedType got modified then it is definitely not possible.
> > At least it's pretty expensive to detect. Would get my head around it
> > again tbh.
> >
> > In OWB we introduced an own method getReturnType() in OwbBean.
> > This get's evaluated and cached based on a few criteria.
> > Most of the time it simply uses the getBeanClass() type.
> >
> > I'll have to dig deeper into your sample to understand what you wanted to
> > do with it.
> >
> > Could you probably put your use case in an OWB unit test and ship it as
> > patch?
> >
> > The only thing you have to do is to extend AbstractUnit test and then
> use:
> > startcontainer(ClassX.class, ClassY.class, ...);
> >
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
> >
> > LieGrue,
> > strub
> >
> > > Am 10.09.2017 um 22:54 schrieb John D. Ament <johndam...@apache.org>:
> > >
> > > Hi,
> > >
> > > I'm running some tests locally using OWB and Instance objects.  I
> noticed
> > > that when the injection point is Instance and I attempt to get an
> > > injectable reference to the InjectionPoint, I get a very odd value for
> > > InjectionPoint.getType().  As far as I understand it, this value should
> > be
> > > the type being injected into, e.g. Foo in my case.  What I actually get
> > > back is the value of Bean.getBeanClass().  That makes very little
> sense.
> > > As best as I can tell, the following code snippet is the cause:
> > >
> > >if (ParameterizedType.class.isInstance(type))
> > >{
> > >ParameterizedType parameterizedType =
> > > ParameterizedType.class.cast(type);
> > >if (parameterizedType.getRawType() == Instance.class)
> > >{
> > >Bean bean =
> > > creationalContextImpl.getBean();
> > >return new InjectionPointDelegate(
> > >injectionPoint,
> > >bean.getBeanClass() != null ?
> > > bean.getBeanClass() : parameterizedType.getActualTypeArguments()[0]);
> > >}
> > >}
> > >
> > > The problem is that Bean.getBeanClass() can never be null, by
> definition,
> > > but also should not be used for type safe resolution (we actually had a
> > > discussion about this on the EG list as I had the opposite belief).
> But
> > I
> > > do believe that the else value is in fact what should always be used, I
> > > always should be getting the expected parameterized value.
> > >
> > > If you guys agree, I can submit a patch to fix this.
> > >
> > > John
> >
> >
> > .
> >
>

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

ber 2017 09:04:41
> >>>> An: openwebbeans-dev
> >>>> Betreff: Re: Odd behavior in InjectionPointProducer
> >>>>
> >>>> Hmm, if you have a class
> >>>>
> >>>> public class Bla {
> >>>> private @Inject Instance myInstance;
> >>>> }
> >>>>
> >>>> then I'd asssume that the InjectionPoint.getType for myInstance would
> be
> >>>> Instance and not Foo alone.
> >>>>
> >>>>> The problem is that Bean.getBeanClass() can never be null, by
> >> definition,
> >>>>> but also should not be used for type safe resolution (we actually
> had a
> >>>>> discussion about this on the EG list as I had the opposite belief).
> >>>>
> >>>> Yes, there was a discussion which never got finished...
> >>>>
> >>>> Weld guys assume that they can infere the proxy type of a bean just by
> >>>> getTypes().
> >>>> I don't believe that. Especially if @Typed is involved or if the real
> >>>> AnnotatedType got modified then it is definitely not possible.
> >>>> At least it's pretty expensive to detect. Would get my head around it
> >>>> again tbh.
> >>>>
> >>>> In OWB we introduced an own method getReturnType() in OwbBean.
> >>>> This get's evaluated and cached based on a few criteria.
> >>>> Most of the time it simply uses the getBeanClass() type.
> >>>>
> >>>> I'll have to dig deeper into your sample to understand what you wanted
> >> to
> >>>> do with it.
> >>>>
> >>>> Could you probably put your use case in an OWB unit test and ship it
> as
> >>>> patch?
> >>>>
> >>>> The only thing you have to do is to extend AbstractUnit test and then
> >> use:
> >>>> startcontainer(ClassX.class, ClassY.class, ...);
> >>>>
> >>>>
> >>>> txs and LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 10.09.2017 um 22:54 schrieb John D. Ament <johndam...@apache.org
> >:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm running some tests locally using OWB and Instance objects.  I
> >> noticed
> >>>>> that when the injection point is Instance and I attempt to get
> an
> >>>>> injectable reference to the InjectionPoint, I get a very odd value
> for
> >>>>> InjectionPoint.getType().  As far as I understand it, this value
> should
> >>>> be
> >>>>> the type being injected into, e.g. Foo in my case.  What I actually
> get
> >>>>> back is the value of Bean.getBeanClass().  That makes very little
> >> sense.
> >>>>> As best as I can tell, the following code snippet is the cause:
> >>>>>
> >>>>>  if (ParameterizedType.class.isInstance(type))
> >>>>>  {
> >>>>>  ParameterizedType parameterizedType =
> >>>>> ParameterizedType.class.cast(type);
> >>>>>  if (parameterizedType.getRawType() == Instance.class)
> >>>>>  {
> >>>>>  Bean bean =
> >>>>> creationalContextImpl.getBean();
> >>>>>  return new InjectionPointDelegate(
> >>>>>  injectionPoint,
> >>>>>  bean.getBeanClass() != null ?
> >>>>> bean.getBeanClass() : parameterizedType.getActualTypeArguments()[0]);
> >>>>>  }
> >>>>>  }
> >>>>>
> >>>>> The problem is that Bean.getBeanClass() can never be null, by
> >> definition,
> >>>>> but also should not be used for type safe resolution (we actually
> had a
> >>>>> discussion about this on the EG list as I had the opposite belief).
> >> But
> >>>> I
> >>>>> do believe that the else value is in fact what should always be
> used, I
> >>>>> always should be getting the expected parameterized value.
> >>>>>
> >>>>> If you guys agree, I can submit a patch to fix this.
> >>>>>
> >>>>> John
> >>>>
> >>>>
> >>>> .
> >>>>
> >>
> >>
>
>

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

On Mon, Sep 11, 2017 at 3:05 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Hmm, if you have a class
>
> public class Bla {
>   private @Inject Instance myInstance;
> }
>
> then I'd asssume that the InjectionPoint.getType for myInstance would be
> Instance and not Foo alone.
>
>
Agreed, simply trying to make sense of what the code's trying to do.


> > The problem is that Bean.getBeanClass() can never be null, by definition,
> > but also should not be used for type safe resolution (we actually had a
> > discussion about this on the EG list as I had the opposite belief).
>
> Yes, there was a discussion which never got finished...
>
> Weld guys assume that they can infere the proxy type of a bean just by
> getTypes().
> I don't believe that. Especially if @Typed is involved or if the real
> AnnotatedType got modified then it is definitely not possible.
> At least it's pretty expensive to detect. Would get my head around it
> again tbh.
>
> In OWB we introduced an own method getReturnType() in OwbBean.
> This get's evaluated and cached based on a few criteria.
> Most of the time it simply uses the getBeanClass() type.
>
> I'll have to dig deeper into your sample to understand what you wanted to
> do with it.
>
> Could you probably put your use case in an OWB unit test and ship it as
> patch?
>
> The only thing you have to do is to extend AbstractUnit test and then use:
> startcontainer(ClassX.class, ClassY.class, ...);
>
>
> txs and LieGrue,
> strub
>
>
>
>
> LieGrue,
> strub
>
> > Am 10.09.2017 um 22:54 schrieb John D. Ament <johndam...@apache.org>:
> >
> > Hi,
> >
> > I'm running some tests locally using OWB and Instance objects.  I noticed
> > that when the injection point is Instance and I attempt to get an
> > injectable reference to the InjectionPoint, I get a very odd value for
> > InjectionPoint.getType().  As far as I understand it, this value should
> be
> > the type being injected into, e.g. Foo in my case.  What I actually get
> > back is the value of Bean.getBeanClass().  That makes very little sense.
> > As best as I can tell, the following code snippet is the cause:
> >
> >if (ParameterizedType.class.isInstance(type))
> >{
> >ParameterizedType parameterizedType =
> > ParameterizedType.class.cast(type);
> >if (parameterizedType.getRawType() == Instance.class)
> >{
> >Bean bean =
> > creationalContextImpl.getBean();
> >return new InjectionPointDelegate(
> >injectionPoint,
> >bean.getBeanClass() != null ?
> > bean.getBeanClass() : parameterizedType.getActualTypeArguments()[0]);
> >}
> >}
> >
> > The problem is that Bean.getBeanClass() can never be null, by definition,
> > but also should not be used for type safe resolution (we actually had a
> > discussion about this on the EG list as I had the opposite belief).  But
> I
> > do believe that the else value is in fact what should always be used, I
> > always should be getting the expected parameterized value.
> >
> > If you guys agree, I can submit a patch to fix this.
> >
> > John
>
>
> .
>

Re: [VOTE] Release Apache OpenWebBeans-2.0.1

[John D. Ament]

Looks good to me, ship it +1

Tested with Hammock + Geronimo Config, both passing fine at this point.

On Tue, Aug 29, 2017 at 5:17 AM Mark Struberg  wrote:

> Hi folks!
>
> I did run the necessary steps to ship OWB-2.0.1 from trunk, which is our
> CDI-2.0 implementation.
> We improved the SE support (hope to finish it soon and ship all in 2.0.2)
> and a few Instance and Event fixes.
>
> This build passes the standalone CDI TCK and we already fixed a few EE
> integration bugs as well while integrating OWB in the upcoming TomEE8.
>
> The following bugs and enhancements got fixed:
>
> Bug
> • [OWB-1199] - CDISeScannerService.autoScanning should be true by
> default
> • [OWB-1203] - GProcessSyntheticBean not handled correctly for
> extensions leading to incorrect ProcessBean behavior
> • [OWB-1204] - Interceptor and Decorator ignored in annotated mode
> if not decorated with @Dependent
> • [OWB-1205] - We should not fire ProcessInjectionPoint for CDI
> Extension Observers
> • [OWB-1207] - Inconsistent behavior of the instance behind
> CDI.current()
> • [OWB-1209] - Custom bean with isAlternative()=true should not be
> automatically enabled
> • [OWB-1210] - Providing an own alternative implementation of
> Provider might disable some Instance resolving
> • [OWB-1211] - OWB is not firing BeforeDestroyed on contexts
> • [OWB-1213] - producer of URI or other classes with private ct
> blow up with a NPE
> Task
> • [OWB-1086] - initial setup for cdi-2.0
>
>
> The staging repo can be found here:
>
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1031/
>
> The source release is under
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1031/org/apache/openwebbeans/openwebbeans/2.0.1/
>
>
> Please VOTE
>
> [+1] go for it!
> [+0] meh, don't care
> [-1] stop because there is a ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>
>
>

Re: [DISCUSS] Release OWB-2.0.1 ?

[John D. Ament]

Ok, both tickets are in.

On Wed, Aug 16, 2017 at 12:17 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> That would be really great if you could create Tickets and attach patches,
> txs John
>
> LieGrue,
> strub
>
>
> > Am 16.08.2017 um 01:25 schrieb John D. Ament <johndam...@apache.org>:
> >
> > A 2.0.1 based on the current would be good, however I would recommend
> > bringing in these two commits independent of the remaining work, since
> they
> > fix core issues.
> >
> > - OWB isn't firing a before destroyed event -
> >
> https://github.com/johnament/openwebbeans/commit/10d62fca523f60a88616b8828cf4efccd845fadc
> > - OWB isn't honoring javax.enterprise.inject.scan.implicit flags -
> >
> https://github.com/johnament/openwebbeans/commit/696e4ba168124ac089e98392bf65c09fe002749d
> >
> > If you want I can create tickets and attach specific patches to those
> > tickets.
> >
> > John
> >
> > On Tue, Aug 15, 2017 at 3:22 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> +1 for se in 2.0.2 and 2.0.1 sooner
> >>
> >> If you nees help for SE on something specific, feel free to ping me.
> >>
> >> Le 15 août 2017 14:37, "Mark Struberg" <strub...@yahoo.de.invalid> a
> >> écrit :
> >>
> >>> Oki, that seems to be a bit more work to be left still.
> >>>
> >>> I'd then suggest to go on with the immanent features and release
> >> OWB-2.0.1
> >>> pretty soon while targetting 2.0.2 for the SE work.
> >>>
> >>> txs and LieGrue,
> >>> strub
> >>>
> >>>
> >>>> Am 15.08.2017 um 13:48 schrieb John D. Ament <johndam...@apache.org>:
> >>>>
> >>>> Mark,
> >>>>
> >>>> SE support is still a long ways from being done.  Most of the issues
> >> are
> >>>> resolved, all of the remaining problems are related to OWB not
> honoring
> >>>> when the container's been shutdown.
> >>>>
> >>>> The good news, by removing the automatic starting of request context
> >> and
> >>>> properly shutting down app context in the SELifeCycle class, OWB is
> >>> finally
> >>>> marking the proxies as invalid, but it seems like we still need to add
> >> an
> >>>> isRunning check somewhere.
> >>>>
> >>>> John
> >>>>
> >>>> On Tue, Aug 15, 2017 at 7:19 AM Mark Struberg
> >> <strub...@yahoo.de.invalid
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Hi folks!
> >>>>>
> >>>>> I'd love to fix OWB-1209 and get Johns SE changes in.
> >>>>> I think we are then ready to roll a 2.0.1 release, isn't?
> >>>>>
> >>>>> John, I'll be available on IRC to coordinate and review your proposed
> >> SE
> >>>>> changes.
> >>>>> Of course we could also discuss it via IRC, but might be easier to
> >> give
> >>>>> that feedback via a shared hangout screen.
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>> .
> >>>>>
> >>>
> >>>
> >>
>
>

[jira] [Created] (OWB-1212) OWB not honoring implicit scanning flag

[John D. Ament (JIRA)]

John D. Ament created OWB-1212:
--

 Summary: OWB not honoring implicit scanning flag
 Key: OWB-1212
 URL: https://issues.apache.org/jira/browse/OWB-1212
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament
 Attachments: implicit-scanning.patch

CDI 2.0 adds an implicit scan option in SE mode.  If on, it scans bean archives 
without beans.xml.  This is a change to add support for that flag.



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

[jira] [Created] (OWB-1211) OWB is not firing BeforeDestroyed on contexts

[John D. Ament (JIRA)]

John D. Ament created OWB-1211:
--

 Summary: OWB is not firing BeforeDestroyed on contexts
 Key: OWB-1211
 URL: https://issues.apache.org/jira/browse/OWB-1211
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament
 Attachments: BeforeDestroyed.patch

Per the spec, in CDI 2, a new event "BeforeDestroyed" was added in the context 
destruction life cycle that is fired before the destruction of that context.  
OWB isn't firing it yet, attached is a patch that does it.



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

Re: [DISCUSS] Release OWB-2.0.1 ?

[John D. Ament]

A 2.0.1 based on the current would be good, however I would recommend
bringing in these two commits independent of the remaining work, since they
fix core issues.

- OWB isn't firing a before destroyed event -
https://github.com/johnament/openwebbeans/commit/10d62fca523f60a88616b8828cf4efccd845fadc
- OWB isn't honoring javax.enterprise.inject.scan.implicit flags -
https://github.com/johnament/openwebbeans/commit/696e4ba168124ac089e98392bf65c09fe002749d

If you want I can create tickets and attach specific patches to those
tickets.

John

On Tue, Aug 15, 2017 at 3:22 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> +1 for se in 2.0.2 and 2.0.1 sooner
>
> If you nees help for SE on something specific, feel free to ping me.
>
> Le 15 août 2017 14:37, "Mark Struberg" <strub...@yahoo.de.invalid> a
> écrit :
>
> > Oki, that seems to be a bit more work to be left still.
> >
> > I'd then suggest to go on with the immanent features and release
> OWB-2.0.1
> > pretty soon while targetting 2.0.2 for the SE work.
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 15.08.2017 um 13:48 schrieb John D. Ament <johndam...@apache.org>:
> > >
> > > Mark,
> > >
> > > SE support is still a long ways from being done.  Most of the issues
> are
> > > resolved, all of the remaining problems are related to OWB not honoring
> > > when the container's been shutdown.
> > >
> > > The good news, by removing the automatic starting of request context
> and
> > > properly shutting down app context in the SELifeCycle class, OWB is
> > finally
> > > marking the proxies as invalid, but it seems like we still need to add
> an
> > > isRunning check somewhere.
> > >
> > > John
> > >
> > > On Tue, Aug 15, 2017 at 7:19 AM Mark Struberg
> <strub...@yahoo.de.invalid
> > >
> > > wrote:
> > >
> > >> Hi folks!
> > >>
> > >> I'd love to fix OWB-1209 and get Johns SE changes in.
> > >> I think we are then ready to roll a 2.0.1 release, isn't?
> > >>
> > >> John, I'll be available on IRC to coordinate and review your proposed
> SE
> > >> changes.
> > >> Of course we could also discuss it via IRC, but might be easier to
> give
> > >> that feedback via a shared hangout screen.
> > >>
> > >> LieGrue,
> > >> strub
> > >> .
> > >>
> >
> >
>

Re: [DISCUSS] Release OWB-2.0.1 ?

[John D. Ament]

Mark,

SE support is still a long ways from being done.  Most of the issues are
resolved, all of the remaining problems are related to OWB not honoring
when the container's been shutdown.

The good news, by removing the automatic starting of request context and
properly shutting down app context in the SELifeCycle class, OWB is finally
marking the proxies as invalid, but it seems like we still need to add an
isRunning check somewhere.

John

On Tue, Aug 15, 2017 at 7:19 AM Mark Struberg 
wrote:

> Hi folks!
>
> I'd love to fix OWB-1209 and get Johns SE changes in.
> I think we are then ready to roll a 2.0.1 release, isn't?
>
> John, I'll be available on IRC to coordinate and review your proposed SE
> changes.
> Of course we could also discuss it via IRC, but might be easier to give
> that feedback via a shared hangout screen.
>
> LieGrue,
> strub
> .
>

Re: Update on SE support

[John D. Ament]

On Mon, Aug 14, 2017 at 8:19 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> 2017-08-14 13:50 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le 14 août 2017 04:31, "John D. Ament" <john.d.am...@gmail.com> a
> écrit
> > :
> > >
> > > Hey guys
> > >
> > > Good news on the SE support front.  Looks like there were two features
> > just
> > > missing outright in OWB 2 from CDI 2.0.
> > >
> > > - Support for a config property javax.enterprise.inject.implicit.scan
> > which
> > > works the opposite of org.apache.webbeans.scanBeansXmlOnly
> > > - Firing BeforeDestroyed when destroying a context
> > >
> > > After getting those done, and ignoring issues with manual request
> context
> > > activation, we're down to only a few failing TCK tests
> > >
> > > Failed tests:
> > >
> > > BootstrapSEContainerTest.instanceSelectAnnotationThrows
> > > ISEWhenAccessedAfterShutdown
> > > » Test
> > >
> > > BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> > > enAccessedAfterShutdown
> > > » Test
> > >
> > > BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> > > ingBmAtShutdownContainer
> > > » Test
> > >   BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> > > expected [true] but found [false]
> > >   BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
> > > expected [true] but found [false]
> > >   BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
> > > expected [Circle] but found [Square]
> > >
> > > BootstrapSEContainerTest.testContainerCloseMethodOnNotI
> > nitializedContainer
> > > » Test
> > >
> > > BootstrapSEContainerTest>Arquillian.run:164->
> > testInvocationOfInitializedMet
> > > hodReturnsNewSeContainerInstance:103
> > > » WebBeansDeployment
> > >
>  BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253
> > »
> > > IllegalArgument
> > >   BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114
> > »
> > > IllegalArgument
> > >
>  InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown
> > »
> > > Test ...
> > >   CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77
> »
> > > UnsatisfiedResolution
> > >
> > > RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
> > > stConstructCallback:72
> > > null
> > >   CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> > > expected [null] but found
> [org.apache.webbeans.container.OwbCDI@7755e503
> > ]
> > >
> > > Most of them are caused by OWB not destroying contextual references
> when
> > > the container shuts down, its almost like OWB never actually stops when
> > you
> > > call close on the SE Container.
> > >
> > > The two interesting ones I dug into are CustomCDIProviderTest and
> > > RequestContextTest.
> > >
> > > For the custom CDI provider, it's actually a bug in the geronimo spec,
> > its
> > > treating a null returned from the CDIProvider as being not set, but the
> > TCK
> > > is implying that its fine, and instead should just be null because the
> > > provider was set.
> > >
> > > The Request context one is a bit trickier.  It looks like OWB's
> behavior
> > is
> > > to start all contexts where the SE container behavior is to only start
> an
> > > application context.  There's already StandaloneLifeCycle which I think
> > we
> > > should leave alone, and instead create a special SELifeCycle in the se
> > > module to better align to the spec's requirements.  Thoughts?
> > >
> > >
> > > Still thinking but what about keeping our defaults based on past usage
> > > experience and having properties to tune it?
> > >
> > >
> > >
> > Romain, I'm not sure if your response is to the whole email or this last
> > section.
> >
>
> last section only, other parts was clear and didnt ask much comment from me
> ;)
>
>
> >
> > If it's about this last section, that's why I'm thinking to create a new
> > lifecycle.  This way by default yo

Re: Update on SE support

[John D. Ament]

On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 14 août 2017 04:31, "John D. Ament" <john.d.am...@gmail.com> a écrit :
>
> Hey guys
>
> Good news on the SE support front.  Looks like there were two features just
> missing outright in OWB 2 from CDI 2.0.
>
> - Support for a config property javax.enterprise.inject.implicit.scan which
> works the opposite of org.apache.webbeans.scanBeansXmlOnly
> - Firing BeforeDestroyed when destroying a context
>
> After getting those done, and ignoring issues with manual request context
> activation, we're down to only a few failing TCK tests
>
> Failed tests:
>
> BootstrapSEContainerTest.instanceSelectAnnotationThrows
> ISEWhenAccessedAfterShutdown
> » Test
>
> BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> enAccessedAfterShutdown
> » Test
>
> BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> ingBmAtShutdownContainer
> » Test
>   BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> expected [true] but found [false]
>   BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
> expected [true] but found [false]
>   BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
> expected [Circle] but found [Square]
>
> BootstrapSEContainerTest.testContainerCloseMethodOnNotInitializedContainer
> » Test
>
> BootstrapSEContainerTest>Arquillian.run:164->testInvocationOfInitializedMet
> hodReturnsNewSeContainerInstance:103
> » WebBeansDeployment
>   BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253 »
> IllegalArgument
>   BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114 »
> IllegalArgument
>   InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown »
> Test ...
>   CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77 »
> UnsatisfiedResolution
>
> RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
> stConstructCallback:72
> null
>   CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> expected [null] but found [org.apache.webbeans.container.OwbCDI@7755e503]
>
> Most of them are caused by OWB not destroying contextual references when
> the container shuts down, its almost like OWB never actually stops when you
> call close on the SE Container.
>
> The two interesting ones I dug into are CustomCDIProviderTest and
> RequestContextTest.
>
> For the custom CDI provider, it's actually a bug in the geronimo spec, its
> treating a null returned from the CDIProvider as being not set, but the TCK
> is implying that its fine, and instead should just be null because the
> provider was set.
>
> The Request context one is a bit trickier.  It looks like OWB's behavior is
> to start all contexts where the SE container behavior is to only start an
> application context.  There's already StandaloneLifeCycle which I think we
> should leave alone, and instead create a special SELifeCycle in the se
> module to better align to the spec's requirements.  Thoughts?
>
>
> Still thinking but what about keeping our defaults based on past usage
> experience and having properties to tune it?
>
>
>
Romain, I'm not sure if your response is to the whole email or this last
section.

If it's about this last section, that's why I'm thinking to create a new
lifecycle.  This way by default you get the SELifeCycle which operates
based on the spec, but you can easily override it in
openwebbeans.properties to use the StandaloneLifeCycle to make a bit more
sense (however, when we talked about how to activate the other contexts in
the EG there was a lot of confusion and problems uncovered, e.g. what is
the underlying bean store for session scoped across multiple "requests" and
how do I get that same store each time?)

We could even name it "JSR365SELifeCycle" to make it extremely clear that
this is in to satisfy the requirements of the JSR only.


>
> I'll keep hacking away.  I did start a branch on github
> https://github.com/johnament/openwebbeans/tree/se-updates .
>
> John
>

Re: Bean Validation for Meecrowave JSON-B/JAX-RS

[John D. Ament]

JAX-RS Defines Bean Val integration, if you add @Valid to resource methods
(params and return value) they should get validated on the way in or the
way out.

On Mon, Aug 7, 2017 at 8:16 AM Mark Struberg 
wrote:

> Hi!
>
> Not sure whether I should post this in Johnzon, CXF or here.
>
> My colleagues have the following question:
> They would like to have an e.g. @NotNull field in a data structure which
> gets serialised as @Produces(MediaType.APPLICATION_JSON)
>
> Means JAX-RS uses JSON-B for serialisation. Ond of course it should also
> work for @Consumes
>
> Obviously this does _not_ work right now, simply because neither JSON-B
> nor JAX-RS defines any Bean Validation integration, right?
>
> Now my question: where in the stack would it make the most sense to
> integrate it? I assume in JSON-B, isn't?
>
> Any thoughts?
>
> LieGrue,
> strub

[jira] [Commented] (OWB-1208) Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116393#comment-16116393
 ] 

John D. Ament commented on OWB-1208:


The CXFCdiServlet is just an example.  I actually had been using Unmanaged to 
create the behavior of injecting into fields without creating a proxy.  

> Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives
> 
>
> Key: OWB-1208
> URL: https://issues.apache.org/jira/browse/OWB-1208
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Take for instance the Apache CXF CDI Extension.  There's a `CXFCdiServlet` 
> class which has no bean defining annotations, but has a valid CDI 1.1 
> [beans.xml|https://github.com/apache/cxf/blob/master/integration/cdi/src/main/resources/META-INF/beans.xml].
>   If I start OWB from a main that has CDI 2.0's trimmed bean archive, this 
> servlet is not available as a CDI bean, and hence cannot be used within 
> Unmanaged.
> I'm not sure if the solution is that it should be a CDI bean, or if Unmanaged 
> should be able to look at non-beans.  This issue does not replicate on Weld 3.



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

[jira] [Created] (OWB-1208) Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives

[John D. Ament (JIRA)]

John D. Ament created OWB-1208:
--

 Summary: Unable to use Unmanaged with mixed CDI 2.0/1.1 bean 
archives
 Key: OWB-1208
 URL: https://issues.apache.org/jira/browse/OWB-1208
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


Take for instance the Apache CXF CDI Extension.  There's a `CXFCdiServlet` 
class which has no bean defining annotations, but has a valid CDI 1.1 
[beans.xml|https://github.com/apache/cxf/blob/master/integration/cdi/src/main/resources/META-INF/beans.xml].
  If I start OWB from a main that has CDI 2.0's trimmed bean archive, this 
servlet is not available as a CDI bean, and hence cannot be used within 
Unmanaged.

I'm not sure if the solution is that it should be a CDI bean, or if Unmanaged 
should be able to look at non-beans.  This issue does not replicate on Weld 3.



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

[jira] [Created] (OWB-1207) Inconsistent behavior of the instance behind CDI.current()

[John D. Ament (JIRA)]

John D. Ament created OWB-1207:
--

 Summary: Inconsistent behavior of the instance behind CDI.current()
 Key: OWB-1207
 URL: https://issues.apache.org/jira/browse/OWB-1207
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


The behavior of CDI.current() is a bit odd, and seems to have a bug in it.

Suppose I have the following:

{code}
Instance x = CDI.current().select(SomeClass, someQualifiers);
Instance y = CDI.current().select(SomeClass).select(someQualifiers)
{code}

Those two instances should be pointing to same set of beans, have the same set 
of qualifiers, but they do not.  x will in fact have an extra Default qualifier 
that y does not have.  The default qualifier is not expected here.  This 
happens because the return value of `instance()` in `OwbCDI` selects a default 
qualifier, and the method taking var args for type and annotations does a 
merge, whereas the second method of selecting just qualifiers does a 
replacement.



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

Re: Why does CDI.current() include a Default Qualifier?

[John D. Ament]

Ok, yes that sounds vaguely familiar.  Basically, if no qualifiers are
chosen then default should be used, but as soon as you add a qualifier
Default should be removed.

On Sun, Aug 6, 2017 at 10:03 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Dont recall the whole details and 90% sure spec is not that closed on that
> point but if you dont have an implicit default, direct type lookup doesnt
> work but if another qualifier is set the *implicit* one (not default, only
> default when implicit) should be stripped IMHO.
>
> Le 6 août 2017 14:46, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > Another issue, which may be related.
> >
> > When I use the following to look up a bean, the bean doesn't have a
> default
> > qualifier but BeanManager.getReference is attempting to add one
> >
> > beanManager.getReference(bean, bean.getBeanClass(),
> > beanManager.createCreationalContext(bean))
> >
> > This was just a regular bean, not a third party bean.
> >
> > On Sun, Aug 6, 2017 at 8:07 AM John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > Hey guys
> > >
> > > Before I create a ticket, I wanted to understand from your POV.  I'm
> not
> > > sure if it's a spec issue.
> > >
> > > I noticed in OWB when I do CDI.current().select(SomeClass,
> > someQualifiers)
> > > the resulting instance includes a Default qualifier.  However, when I
> do
> > > CDI.current().select(SomeClass).select(someQualifiers) it does not.
> > >
> > > I noticed that adding the Default qualifier was done in this commit
> [1].
> > > However, I don't believe this is correct.  I looked through the spec, I
> > > can't find any reference that the instance should have a default
> > qualifier
> > > on it.
> > >
> > > This causes an issue with 3rd party beans.  If I try to do something
> like
> > > programmatically lookup a bean where the qualifiers don't include a
> > default
> > > qualifier, then the lookup fails.
> > >
> > > John
> > >
> >
>

Re: Why does CDI.current() include a Default Qualifier?

[John D. Ament]

Another issue, which may be related.

When I use the following to look up a bean, the bean doesn't have a default
qualifier but BeanManager.getReference is attempting to add one

beanManager.getReference(bean, bean.getBeanClass(),
beanManager.createCreationalContext(bean))

This was just a regular bean, not a third party bean.

On Sun, Aug 6, 2017 at 8:07 AM John D. Ament <johndam...@apache.org> wrote:

> Hey guys
>
> Before I create a ticket, I wanted to understand from your POV.  I'm not
> sure if it's a spec issue.
>
> I noticed in OWB when I do CDI.current().select(SomeClass, someQualifiers)
> the resulting instance includes a Default qualifier.  However, when I do
> CDI.current().select(SomeClass).select(someQualifiers) it does not.
>
> I noticed that adding the Default qualifier was done in this commit [1].
> However, I don't believe this is correct.  I looked through the spec, I
> can't find any reference that the instance should have a default qualifier
> on it.
>
> This causes an issue with 3rd party beans.  If I try to do something like
> programmatically lookup a bean where the qualifiers don't include a default
> qualifier, then the lookup fails.
>
> John
>

How to handle javax.enterprise.inject.scan.implicit

[John D. Ament]

There's an open CDI spec ticket https://issues.jboss.org/browse/CDI-632

But it seems that this property isn't handled presently in OWB.  Its
basically whether to turn on whether JARs without any beans.xml should be
CDI archives.  It probably makes sense to handle this property in
CDISeScannerService and override the resulting scanOnlyBeansXmlJars to be
true/false depending on this property being set.

John

[jira] [Updated] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

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

John D. Ament updated OWB-1206:
---
Attachment: OWB_1206_v2.patch

Here's a better patch, created an owb-se-tck package to run.  It's a bit of a 
pain but the test harness will end up being the simple part.

I excluded the request context activation tests until those are in.

17/27 tests are failing

{code}
Tests run: 27, Failures: 17, Errors: 0, Skipped: 0, Time elapsed: 16.639 sec 
<<< FAILURE! - in TestSuite
instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.523 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException

instanceSelectClassThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.072 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException

seContainerThrowsISEWhenAccessingBmAtShutdownContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.074 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException

testAddDecorator(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest) 
 Time elapsed: 0.062 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddDecorator(BootstrapSEContainerTest.java:244)

testAddInterceptor(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.048 sec  <<< FAILURE!
java

Re: XBean & ShrinkWrap archives

[John D. Ament]

Ok, just chatted with Mark.  I'm going to get the SE TCK running in a new
module, webbeans-se-tck.  There's a different arquillian container to use
(the SE container) which is what Weld's doing to run these tests.  I'll
hopefully get a patch out for this tonight.

John

On Sun, Jul 30, 2017 at 6:29 PM John D. Ament <johndam...@apache.org> wrote:

> I have a local test working.
>
> It's not going to work too cleanly, but its doable.
>
> If you look at this test for instance:
> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/se/discovery/trimmed/TrimmedBeanArchiveSETest.java
>  ,
> its dependent on having a bean archive with this beans.xml file
> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/resources/org/jboss/cdi/tck/tests/se/discovery/trimmed/beans.xml
>
> Maybe we'll get lucky and this is the only case of a special beans.xml,
> but we may need multiple test projects to accomplish it (maybe some
> examples?)
>
> John
>
>
> On Sun, Jul 30, 2017 at 6:19 PM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
>> Well, we would need to keep the JBoss copyright.
>> Which is something I'd rather like to avoid because it's essentially just
>> a test.
>>
>> I'm currently moving from the tomcat7-m-p to cargo-maven2-plugin.
>> I can help and take a look into those SE parts affter all that is running
>> again.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 31.07.2017 um 00:11 schrieb John D. Ament <johndam...@apache.org>:
>> >
>> > Agreed, when I first looked at it.  Not so much afterwards.  Andrew
>> (ALR)
>> > was working on an idea a long time ago of having an "SE Container"
>> where it
>> > was a fully isolated JVM that you could just push classes to.  I think
>> > that's what they were trying to do here.
>> >
>> > I raised my first TCK issue today :-) I'll raise another for this (was
>> > thinking about it anyways), since I'm really not sure what they were
>> going
>> > for with this test.
>> >
>> > Would it be an issue to just duplicate the tests here?
>> >
>> > John
>> >
>> > On Sun, Jul 30, 2017 at 6:01 PM Mark Struberg <strub...@yahoo.de.invalid
>> >
>> > wrote:
>> >
>> >> With other words: this part of the TCK should not have been using
>> >> Arquillian in the first place.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>> Am 30.07.2017 um 23:59 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> >>> :
>> >>>
>> >>> Just exclude these tests and remplace them by webbeans-se normal
>> tests.
>> >>> This is good enough and doesnt require arquillian hacks.
>> >>>
>> >>> Le 30 juil. 2017 23:56, "John D. Ament" <johndam...@apache.org> a
>> écrit
>> >> :
>> >>>
>> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
>> >> rmannibu...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Se code can work with arquillian tuning the scanner in owb.props but
>> not
>> >>>> sure it does wirrh it if we cover the tests in standalone already.
>> Wdyt?
>> >>>>
>> >>>
>> >>> Romain, I have no idea what you're asking here.
>> >>>
>> >>>
>> >>>>
>> >>>> Le 30 juil. 2017 22:29, "John D. Ament" <johndam...@apache.org> a
>> >> écrit :
>> >>>>
>> >>>>> Mark,
>> >>>>>
>> >>>>> Sure, its this TCK test in particular:
>> >>>>> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/
>> >>>>> src/main/java/org/jboss/cdi/tck/tests/se/container/
>> >>>>> BootstrapSEContainerTest.java#L57
>> >>>>>
>> >>>>> From looking at what they're doing, it seems like they're trying to
>> >>>> create
>> >>>>> an isolated classpath using the Arquillian SE container, and
>> expecting
>> >>>> the
>> >>>>> beans to be discovered from there.  However, the SE container OWB is
>> >>>>> initializing ends up mixing ShrinkWrap and XBean behavior, which
>> causes
>> >>>> JAR
>> >>>>> discovery to behave a bit di

Re: XBean & ShrinkWrap archives

[John D. Ament]

I have a local test working.

It's not going to work too cleanly, but its doable.

If you look at this test for instance:
https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/se/discovery/trimmed/TrimmedBeanArchiveSETest.java
,
its dependent on having a bean archive with this beans.xml file
https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/resources/org/jboss/cdi/tck/tests/se/discovery/trimmed/beans.xml

Maybe we'll get lucky and this is the only case of a special beans.xml, but
we may need multiple test projects to accomplish it (maybe some examples?)

John

On Sun, Jul 30, 2017 at 6:19 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Well, we would need to keep the JBoss copyright.
> Which is something I'd rather like to avoid because it's essentially just
> a test.
>
> I'm currently moving from the tomcat7-m-p to cargo-maven2-plugin.
> I can help and take a look into those SE parts affter all that is running
> again.
>
> LieGrue,
> strub
>
>
> > Am 31.07.2017 um 00:11 schrieb John D. Ament <johndam...@apache.org>:
> >
> > Agreed, when I first looked at it.  Not so much afterwards.  Andrew (ALR)
> > was working on an idea a long time ago of having an "SE Container" where
> it
> > was a fully isolated JVM that you could just push classes to.  I think
> > that's what they were trying to do here.
> >
> > I raised my first TCK issue today :-) I'll raise another for this (was
> > thinking about it anyways), since I'm really not sure what they were
> going
> > for with this test.
> >
> > Would it be an issue to just duplicate the tests here?
> >
> > John
> >
> > On Sun, Jul 30, 2017 at 6:01 PM Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> >> With other words: this part of the TCK should not have been using
> >> Arquillian in the first place.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 30.07.2017 um 23:59 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Just exclude these tests and remplace them by webbeans-se normal tests.
> >>> This is good enough and doesnt require arquillian hacks.
> >>>
> >>> Le 30 juil. 2017 23:56, "John D. Ament" <johndam...@apache.org> a
> écrit
> >> :
> >>>
> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >>> wrote:
> >>>
> >>>> Se code can work with arquillian tuning the scanner in owb.props but
> not
> >>>> sure it does wirrh it if we cover the tests in standalone already.
> Wdyt?
> >>>>
> >>>
> >>> Romain, I have no idea what you're asking here.
> >>>
> >>>
> >>>>
> >>>> Le 30 juil. 2017 22:29, "John D. Ament" <johndam...@apache.org> a
> >> écrit :
> >>>>
> >>>>> Mark,
> >>>>>
> >>>>> Sure, its this TCK test in particular:
> >>>>> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/
> >>>>> src/main/java/org/jboss/cdi/tck/tests/se/container/
> >>>>> BootstrapSEContainerTest.java#L57
> >>>>>
> >>>>> From looking at what they're doing, it seems like they're trying to
> >>>> create
> >>>>> an isolated classpath using the Arquillian SE container, and
> expecting
> >>>> the
> >>>>> beans to be discovered from there.  However, the SE container OWB is
> >>>>> initializing ends up mixing ShrinkWrap and XBean behavior, which
> causes
> >>>> JAR
> >>>>> discovery to behave a bit different.
> >>>>>
> >>>>> BTW, I did try changing the protocol, no luck as the JAR generated
> >> isn't
> >>>> a
> >>>>> real JAR.
> >>>>>
> >>>>> John
> >>>>>
> >>>>> On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg
> >> <strub...@yahoo.de.invalid
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi John!
> >>>>>>
> >>>>>> We actually don't use xbean at all in the arquillian adapter.
> >>>>>> The scanning is done manually. You can dig that in the
> >>>>>> OwbArquillianScannerService.
> >>>>&g

Re: XBean & ShrinkWrap archives

[John D. Ament]

Agreed, when I first looked at it.  Not so much afterwards.  Andrew (ALR)
was working on an idea a long time ago of having an "SE Container" where it
was a fully isolated JVM that you could just push classes to.  I think
that's what they were trying to do here.

I raised my first TCK issue today :-) I'll raise another for this (was
thinking about it anyways), since I'm really not sure what they were going
for with this test.

Would it be an issue to just duplicate the tests here?

John

On Sun, Jul 30, 2017 at 6:01 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> With other words: this part of the TCK should not have been using
> Arquillian in the first place.
>
> LieGrue,
> strub
>
> > Am 30.07.2017 um 23:59 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Just exclude these tests and remplace them by webbeans-se normal tests.
> > This is good enough and doesnt require arquillian hacks.
> >
> > Le 30 juil. 2017 23:56, "John D. Ament" <johndam...@apache.org> a écrit
> :
> >
> > On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Se code can work with arquillian tuning the scanner in owb.props but not
> >> sure it does wirrh it if we cover the tests in standalone already. Wdyt?
> >>
> >
> > Romain, I have no idea what you're asking here.
> >
> >
> >>
> >> Le 30 juil. 2017 22:29, "John D. Ament" <johndam...@apache.org> a
> écrit :
> >>
> >>> Mark,
> >>>
> >>> Sure, its this TCK test in particular:
> >>> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/
> >>> src/main/java/org/jboss/cdi/tck/tests/se/container/
> >>> BootstrapSEContainerTest.java#L57
> >>>
> >>> From looking at what they're doing, it seems like they're trying to
> >> create
> >>> an isolated classpath using the Arquillian SE container, and expecting
> >> the
> >>> beans to be discovered from there.  However, the SE container OWB is
> >>> initializing ends up mixing ShrinkWrap and XBean behavior, which causes
> >> JAR
> >>> discovery to behave a bit different.
> >>>
> >>> BTW, I did try changing the protocol, no luck as the JAR generated
> isn't
> >> a
> >>> real JAR.
> >>>
> >>> John
> >>>
> >>> On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg
> <strub...@yahoo.de.invalid
> >>>
> >>> wrote:
> >>>
> >>>> Hi John!
> >>>>
> >>>> We actually don't use xbean at all in the arquillian adapter.
> >>>> The scanning is done manually. You can dig that in the
> >>>> OwbArquillianScannerService.
> >>>> Can you share your setup? Probably might help a bit later.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 30.07.2017 um 20:23 schrieb John D. Ament <johndam...@apache.org
> >>> :
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> So I've been trying to dig into why OWB's CDI TCK tests are
> >> failing.  I
> >>>>> have it down to 22 failures that should mostly be passing (or are
> >>> failing
> >>>>> in the wrong spot).  The most common failure is because of this:
> >>>>>
> >>>>> Caused by: java.lang.UnsupportedOperationException: unsupported
> >>> archive
> >>>>> type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/
> >>>>> at
> >>>>>
> >>>> org.apache.xbean.finder.archive.ClasspathArchive.
> >>> archive(ClasspathArchive.java:87)
> >>>>> at
> >>>>>
> >>>> org.apache.webbeans.corespi.scanner.xbean.CdiArchive.<
> >>> init>(CdiArchive.java:67)
> >>>>>
> >>>>> I'm not sure if this is an XBean issue or an OWB issue.  Basically,
> >>> when
> >>>>> bootstrapping CDI SE, we're getting some shrinkwrap JARs on the
> >>> classpath
> >>>>> (which is on purpose, I think they're trying to make a CDI bean
> >> archive
> >>>> in
> >>>>> addition to what's in the SE container).  XBean doesn't know what
> > the
> >>>>> "archive" protocol means.  I suspect if the first if statement in
> >>>>> ClasspathArchive were changed to (line
> >>>>> 53): if(location.getProtocol().equals("jar") ||
> >>>>> location.getProtocol().equals("archive")) { then it would fix it,
> > but
> >>> not
> >>>>> 100% sure.
> >>>>>
> >>>>> John
> >>>>
> >>>>
> >>>
> >>
>
>

Re: XBean & ShrinkWrap archives

[John D. Ament]

On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Se code can work with arquillian tuning the scanner in owb.props but not
> sure it does wirrh it if we cover the tests in standalone already. Wdyt?
>

Romain, I have no idea what you're asking here.


>
> Le 30 juil. 2017 22:29, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > Mark,
> >
> > Sure, its this TCK test in particular:
> > https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/
> > src/main/java/org/jboss/cdi/tck/tests/se/container/
> > BootstrapSEContainerTest.java#L57
> >
> > From looking at what they're doing, it seems like they're trying to
> create
> > an isolated classpath using the Arquillian SE container, and expecting
> the
> > beans to be discovered from there.  However, the SE container OWB is
> > initializing ends up mixing ShrinkWrap and XBean behavior, which causes
> JAR
> > discovery to behave a bit different.
> >
> > BTW, I did try changing the protocol, no luck as the JAR generated isn't
> a
> > real JAR.
> >
> > John
> >
> > On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> > > Hi John!
> > >
> > > We actually don't use xbean at all in the arquillian adapter.
> > > The scanning is done manually. You can dig that in the
> > > OwbArquillianScannerService.
> > > Can you share your setup? Probably might help a bit later.
> > >
> > > LieGrue,
> > > strub
> > >
> > > > Am 30.07.2017 um 20:23 schrieb John D. Ament <johndam...@apache.org
> >:
> > > >
> > > > Hi All,
> > > >
> > > > So I've been trying to dig into why OWB's CDI TCK tests are
> failing.  I
> > > > have it down to 22 failures that should mostly be passing (or are
> > failing
> > > > in the wrong spot).  The most common failure is because of this:
> > > >
> > > > Caused by: java.lang.UnsupportedOperationException: unsupported
> > archive
> > > > type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/
> > > > at
> > > >
> > > org.apache.xbean.finder.archive.ClasspathArchive.
> > archive(ClasspathArchive.java:87)
> > > > at
> > > >
> > > org.apache.webbeans.corespi.scanner.xbean.CdiArchive.<
> > init>(CdiArchive.java:67)
> > > >
> > > > I'm not sure if this is an XBean issue or an OWB issue.  Basically,
> > when
> > > > bootstrapping CDI SE, we're getting some shrinkwrap JARs on the
> > classpath
> > > > (which is on purpose, I think they're trying to make a CDI bean
> archive
> > > in
> > > > addition to what's in the SE container).  XBean doesn't know what the
> > > > "archive" protocol means.  I suspect if the first if statement in
> > > > ClasspathArchive were changed to (line
> > > > 53): if(location.getProtocol().equals("jar") ||
> > > > location.getProtocol().equals("archive")) { then it would fix it, but
> > not
> > > > 100% sure.
> > > >
> > > > John
> > >
> > >
> >
>

Re: XBean & ShrinkWrap archives

[John D. Ament]

Mark,

Sure, its this TCK test in particular:
https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/se/container/BootstrapSEContainerTest.java#L57

>From looking at what they're doing, it seems like they're trying to create
an isolated classpath using the Arquillian SE container, and expecting the
beans to be discovered from there.  However, the SE container OWB is
initializing ends up mixing ShrinkWrap and XBean behavior, which causes JAR
discovery to behave a bit different.

BTW, I did try changing the protocol, no luck as the JAR generated isn't a
real JAR.

John

On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Hi John!
>
> We actually don't use xbean at all in the arquillian adapter.
> The scanning is done manually. You can dig that in the
> OwbArquillianScannerService.
> Can you share your setup? Probably might help a bit later.
>
> LieGrue,
> strub
>
> > Am 30.07.2017 um 20:23 schrieb John D. Ament <johndam...@apache.org>:
> >
> > Hi All,
> >
> > So I've been trying to dig into why OWB's CDI TCK tests are failing.  I
> > have it down to 22 failures that should mostly be passing (or are failing
> > in the wrong spot).  The most common failure is because of this:
> >
> > Caused by: java.lang.UnsupportedOperationException: unsupported archive
> > type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/
> > at
> >
> org.apache.xbean.finder.archive.ClasspathArchive.archive(ClasspathArchive.java:87)
> > at
> >
> org.apache.webbeans.corespi.scanner.xbean.CdiArchive.(CdiArchive.java:67)
> >
> > I'm not sure if this is an XBean issue or an OWB issue.  Basically, when
> > bootstrapping CDI SE, we're getting some shrinkwrap JARs on the classpath
> > (which is on purpose, I think they're trying to make a CDI bean archive
> in
> > addition to what's in the SE container).  XBean doesn't know what the
> > "archive" protocol means.  I suspect if the first if statement in
> > ClasspathArchive were changed to (line
> > 53): if(location.getProtocol().equals("jar") ||
> > location.getProtocol().equals("archive")) { then it would fix it, but not
> > 100% sure.
> >
> > John
>
>

XBean & ShrinkWrap archives

[John D. Ament]

Hi All,

So I've been trying to dig into why OWB's CDI TCK tests are failing.  I
have it down to 22 failures that should mostly be passing (or are failing
in the wrong spot).  The most common failure is because of this:

Caused by: java.lang.UnsupportedOperationException: unsupported archive
type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/
at
org.apache.xbean.finder.archive.ClasspathArchive.archive(ClasspathArchive.java:87)
at
org.apache.webbeans.corespi.scanner.xbean.CdiArchive.(CdiArchive.java:67)

I'm not sure if this is an XBean issue or an OWB issue.  Basically, when
bootstrapping CDI SE, we're getting some shrinkwrap JARs on the classpath
(which is on purpose, I think they're trying to make a CDI bean archive in
addition to what's in the SE container).  XBean doesn't know what the
"archive" protocol means.  I suspect if the first if statement in
ClasspathArchive were changed to (line
53): if(location.getProtocol().equals("jar") ||
location.getProtocol().equals("archive")) { then it would fix it, but not
100% sure.

John

[jira] [Commented] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106520#comment-16106520
 ] 

John D. Ament commented on OWB-1206:


Well, the reason being that SE and Arquillian should work together without any 
issue.  Right now it's assuming that the configured scanner is the default 
scanner, which may not be the case.  So it makes sense to move register to the 
base interface and require it to always implement it.

> Enable CDI 2.0 TCK SE Tests
> ---
>
> Key: OWB-1206
> URL: https://issues.apache.org/jira/browse/OWB-1206
> Project: OpenWebBeans
>  Issue Type: Improvement
>        Reporter: John D. Ament
> Attachments: OWB_1206.patch
>
>
> The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
> ticket to:
> - Enable the suite
> - Fix whatever tests may fail



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

[jira] [Commented] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106516#comment-16106516
 ] 

John D. Ament commented on OWB-1206:


Many of the errors seem to originate from xbean, and it's odd because what the 
TCK is doing is mixing arquillian and SeContainer.  

{code}
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:0746a2d5-82fa-4d58-8c31-67e9098d07d2.jar/
at 
org.apache.xbean.finder.archive.ClasspathArchive.archive(ClasspathArchive.java:87)
at 
org.apache.webbeans.corespi.scanner.xbean.CdiArchive.(CdiArchive.java:67)
at 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:113)
at 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:153)
... 100 more
{code}

This combination seems to be creating archives that xbean can't understand.  

> Enable CDI 2.0 TCK SE Tests
> ---
>
> Key: OWB-1206
> URL: https://issues.apache.org/jira/browse/OWB-1206
> Project: OpenWebBeans
>  Issue Type: Improvement
>        Reporter: John D. Ament
> Attachments: OWB_1206.patch
>
>
> The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
> ticket to:
> - Enable the suite
> - Fix whatever tests may fail



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

[jira] [Updated] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

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

John D. Ament updated OWB-1206:
---
Attachment: OWB_1206.patch

The following tests fail after making the attached changes

{code}
instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.043 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:277)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:277)

instanceSelectClassThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.012 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:270)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:270)

seContainerThrowsISEWhenAccessingBmAtShutdownContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.009 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer(BootstrapSEContainerTest.java:263)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer(BootstrapSEContainerTest.java:263)

testAddDecorator(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest) 
 Time elapsed: 0.02 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddDecorator(BootstrapSEContainerTest.java:244)

testAddInterceptor(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.005 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddInterceptor(BootstrapSEContainerTest.java:227)

testAlternativesInSE(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.014 sec  <<< FAILURE!
java.lang.AssertionError: expected [Circle] but found [Square]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAlternativesInSE(BootstrapSEContainerTest.java:138)

testContainerCloseMethodOnNotInitializedContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.012 sec  <<< FAILURE!
org.testng.TestExceptio

[jira] [Created] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

John D. Ament created OWB-1206:
--

 Summary: Enable CDI 2.0 TCK SE Tests
 Key: OWB-1206
 URL: https://issues.apache.org/jira/browse/OWB-1206
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: John D. Ament


The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
ticket to:

- Enable the suite
- Fix whatever tests may fail



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

[jira] [Commented] (OWB-1191) implement api for manual request-context handling

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106496#comment-16106496
 ] 

John D. Ament commented on OWB-1191:


Oh , I see.  OWB's ignoring the SE tests..

{code}





{code}

> implement api for manual request-context handling
> -
>
> Key: OWB-1191
> URL: https://issues.apache.org/jira/browse/OWB-1191
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Context and Scopes
>Reporter: Gerhard Petracek
> Fix For: 2.0.1
>
> Attachments: OWB_1191.patch
>
>
> new parts:
>  * ActivateRequestContext
>  * RequestContextController



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

[jira] [Updated] (OWB-1191) implement api for manual request-context handling

[John D. Ament (JIRA)]

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

John D. Ament updated OWB-1191:
---
Attachment: OWB_1191.patch

Here's a patch, untested, but looks logically right.  

I'm not sure yet how to bind an interceptor the same way, but this should at 
least add the built in bean.

> implement api for manual request-context handling
> -
>
> Key: OWB-1191
> URL: https://issues.apache.org/jira/browse/OWB-1191
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Context and Scopes
>Reporter: Gerhard Petracek
> Fix For: 2.0.1
>
> Attachments: OWB_1191.patch
>
>
> new parts:
>  * ActivateRequestContext
>  * RequestContextController



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

Re: do a 2.0.1 release?

[John D. Ament]

Hi,

Looks like there's still a couple of issues open in 2.0.1 [1].  I'm
surprised there's no testing for [2], I'm guessing it's ignored in the
TCK?  If you can wait until tomorrow I should be able to get a patch
together for it, if not go for it.

[1]: https://issues.apache.org/jira/projects/OWB/versions/12341073
[2]: https://issues.apache.org/jira/browse/OWB-1191


On Sun, Jul 30, 2017 at 7:37 AM Mark Struberg 
wrote:

> Well, I was thinking about a OWB-2.0.1 release.
> And of course then do a MW-2.0.0 or MW-1.1.0 (not sure anymore on what we
> settled and which is better for MW).
>
> LieGrue,
> strub
>
> > Am 30.07.2017 um 12:10 schrieb Romain Manni-Bucau  >:
> >
> > Hi Mark,
> >
> > I would include the coming johnzon release and maybe do a 2.0.0 before
> the
> > 2.0.1 ;)
> >
> > But overall +1 to release
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-07-30 10:47 GMT+02:00 Mark Struberg :
> >
> >> Hi folks!
> >>
> >> We've fixed a few important bugs in trunk. Should we do a 2.0.1 release?
> >> Could start it in the afternoon.
> >>
> >> LieGrue,
> >> strub
> >>
>
>

Re: OWB 2 not firing ProcessAnnotatedType for all bean classes

[John D. Ament]

We should probably review on cdi-dev.  I believe the intention behind
saying "classes discovered"  [1] is to indicate that its for all classes,
not just eligible beans.  Here's a use case: I have framework specific
classes, where the developer isn't required to add a scope.  Framework adds
the scope for them.  To do that, they use bean-discovery-mode=annotated and
PAT will add the dependent or other scope as appropriate.

[1]:
https://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#process_annotated_type

On Sat, Jul 22, 2017 at 5:40 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> In that case Romain is right.
>
> In an implicit BDA you only get PAT if the class has a bean defining
> annotation.
> Thats the reason we introduced all+trim.
>
> LieGrue,
> Strub
>
> > Am 21.07.2017 um 21:37 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Cause the scanning by itself is undefined, you can not scan skip not bean
> > types and be spec compliant.
> >
> >
> > Le 21 juil. 2017 21:26, "John D. Ament" <johndam...@apache.org> a écrit
> :
> >
> >> Errr I'm not sure what you mean.  The spec states this "before it reads
> the
> >> declared annotations" so I'm not sure why you think it needs to have a
> bean
> >> defining annotation.
> >>
> >> John
> >>
> >> On Fri, Jul 21, 2017 at 3:21 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Hmm, interesting edge case. For me it should be ignored until you make
> it
> >>> scanned using @Dependent or so. But fear it is quite undefined or
> >>> "interpretable"
> >>>
> >>> Le 21 juil. 2017 21:10, "John D. Ament" <johndam...@apache.org> a
> écrit
> >> :
> >>>
> >>>> I do something really lazy, I have an extension that has this method
> on
> >>> it:
> >>>>
> >>>> public void findEntities(@Observes @WithAnnotations(Entity.class)
> >>>> ProcessAnnotatedType pat)
> >>>>
> >>>> which just looks for entity classes.  They're not going to be CDI
> >> beans,
> >>>> but they are annotated types.  Per the spec,
> >>>> https://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/
> >>>> ProcessAnnotatedType.html
> >>>> ,
> >>>> the event should get fired, even if there are no bean defining
> >>> annotations.
> >>>>
> >>>> Switching beans.xml to use bean-discovery-mode=all fixes it, but I'd
> >>> prefer
> >>>> to not discover these as beans.
> >>>>
> >>>> Using a 
> >>> does
> >>>> fix it. But either way, my understanding is that PAT is always fired,
> >> for
> >>>> all classes found within a bean archive.
> >>>>
> >>>> John
> >>>>
> >>>
> >>
>
>

Re: Interceptor discovery

[John D. Ament]

The interceptor is intended to be enabled just because of the @Priority
annotation.  Nothing else should be required.  Please review 9.4 of the
spec http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#enabled_interceptors

John

On Fri, Jul 21, 2017 at 3:22 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Misses @Dependent yes.
>
> Le 21 juil. 2017 19:35, "John D. Ament" <johndam...@apache.org> a écrit :
>
> I have an interceptor defined as:
>
> @Interceptor
> @LoggedIn
> @Priority(Interceptor.Priority.APPLICATION + 100)
> public class LoggedInInterceptor {
>
> and a beans.xml with
>
> 
>
> This interceptor isn't being discovered.  It is discovered when beans.xml
> is an empty file.  This same interceptor is discovered on OWB 1.7, but not
> in 2.0.1-SNAPSHOT.
>
> John
>

Re: OWB 2 not firing ProcessAnnotatedType for all bean classes

[John D. Ament]

Errr I'm not sure what you mean.  The spec states this "before it reads the
declared annotations" so I'm not sure why you think it needs to have a bean
defining annotation.

John

On Fri, Jul 21, 2017 at 3:21 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hmm, interesting edge case. For me it should be ignored until you make it
> scanned using @Dependent or so. But fear it is quite undefined or
> "interpretable"
>
> Le 21 juil. 2017 21:10, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > I do something really lazy, I have an extension that has this method on
> it:
> >
> > public void findEntities(@Observes @WithAnnotations(Entity.class)
> > ProcessAnnotatedType pat)
> >
> > which just looks for entity classes.  They're not going to be CDI beans,
> > but they are annotated types.  Per the spec,
> > https://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/
> > ProcessAnnotatedType.html
> > ,
> > the event should get fired, even if there are no bean defining
> annotations.
> >
> > Switching beans.xml to use bean-discovery-mode=all fixes it, but I'd
> prefer
> > to not discover these as beans.
> >
> > Using a 
> does
> > fix it. But either way, my understanding is that PAT is always fired, for
> > all classes found within a bean archive.
> >
> > John
> >
>

OWB 2 not firing ProcessAnnotatedType for all bean classes

[John D. Ament]

I do something really lazy, I have an extension that has this method on it:

public void findEntities(@Observes @WithAnnotations(Entity.class)
ProcessAnnotatedType pat)

which just looks for entity classes.  They're not going to be CDI beans,
but they are annotated types.  Per the spec,
https://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/ProcessAnnotatedType.html
,
the event should get fired, even if there are no bean defining annotations.

Switching beans.xml to use bean-discovery-mode=all fixes it, but I'd prefer
to not discover these as beans.

Using a  does
fix it. But either way, my understanding is that PAT is always fired, for
all classes found within a bean archive.

John

Re: ProcessBean being called regardless of type

[John D. Ament]

Yes sorry, pointed to the wrong error.  This looks much better now, thanks!

On Wed, Jul 19, 2017 at 3:41 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> PS: created https://issues.apache.org/jira/browse/OWB-1203
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-19 9:24 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > oops, was just another failing test in hammock.
> >
> > The one you originally mentionned - datasource one right? - looks
> accurate. Will
> > check it but just looks like we don't unwrap properly container events.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-19 9:15 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> >> Hi John
> >>
> >> just looks like your DefaultListener misses @Dependent in annotated mode
> >> to me.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2017-07-19 4:48 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >>
> >>> Hi,
> >>>
> >>> I have a portable extension that registers an observer method like so:
> >>>
> >>> public void findSpecialBeans(@Observes ProcessBean
> >>> processBean)
> >>>
> >>> In Weld, this gets invoked once in my test application, only for beans
> of
> >>> type SpecialBean.  In OWB 2, this is getting invoked once for that same
> >>> bean, but then again for each additional bean registered in my
> >>> corresponding AfterBeanDiscovery (which none of these beans match
> >>> SpecialBean). The weird part is that I don't see this behavior in OWB
> >>> 1.7,
> >>> and I don't see it happening within other extensions (e.g. another
> >>> ExtensionB also have AfterBeanDiscovery, those beans don't invoke this
> >>> extension).
> >>>
> >>> You can see Travis complaining about this issue at
> >>> https://travis-ci.org/hammock-project/hammock/jobs/254409046
> >>>
> >>> John
> >>>
> >>
> >>
> >
>

Interceptor discovery

[John D. Ament]

I have an interceptor defined as:

@Interceptor
@LoggedIn
@Priority(Interceptor.Priority.APPLICATION + 100)
public class LoggedInInterceptor {

and a beans.xml with



This interceptor isn't being discovered.  It is discovered when beans.xml
is an empty file.  This same interceptor is discovered on OWB 1.7, but not
in 2.0.1-SNAPSHOT.

John

ProcessBean being called regardless of type

[John D. Ament]

Hi,

I have a portable extension that registers an observer method like so:

public void findSpecialBeans(@Observes ProcessBean processBean)

In Weld, this gets invoked once in my test application, only for beans of
type SpecialBean.  In OWB 2, this is getting invoked once for that same
bean, but then again for each additional bean registered in my
corresponding AfterBeanDiscovery (which none of these beans match
SpecialBean). The weird part is that I don't see this behavior in OWB 1.7,
and I don't see it happening within other extensions (e.g. another
ExtensionB also have AfterBeanDiscovery, those beans don't invoke this
extension).

You can see Travis complaining about this issue at
https://travis-ci.org/hammock-project/hammock/jobs/254409046

John

[jira] [Resolved] (OWB-1200) OWB 2 skips producer methods defined in annotated bean archives in SE

[John D. Ament (JIRA)]

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

John D. Ament resolved OWB-1200.

Resolution: Invalid

Non issue, see OWB-1201 for more details.

> OWB 2 skips producer methods defined in annotated bean archives in SE
> -
>
> Key: OWB-1200
> URL: https://issues.apache.org/jira/browse/OWB-1200
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Here's a code sample that fails for me
> https://github.com/astefanutti/metrics-cdi/blob/29e7bac497513de420543497612180331cc5d1b3/impl/src/main/java/io/astefanutti/metrics/cdi/MetricNameFactory.java#L24
> Basically, from what I can tell OWB 2 misses this producer method, I believe 
> because it doesn't have a scope but the outer bean class does have a scope.
> AFAIK, per the spec, this is implicitly a `@Dependent` producer and should 
> have been picked up because the outer bean is defined as a dependent scoped 
> bean.



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

[jira] [Commented] (OWB-1199) CDISeScannerService.autoScanning should be true by default

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088926#comment-16088926
 ] 

John D. Ament commented on OWB-1199:


LGTM thanks.  Just want to make sure we don't end up with regressions :-)

> CDISeScannerService.autoScanning should be true by default
> --
>
> Key: OWB-1199
> URL: https://issues.apache.org/jira/browse/OWB-1199
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>    Reporter: John D. Ament
> Fix For: 2.0.1
>
> Attachments: OWB_1199.patch
>
>
> The value of CDISeScannerService.autoScanning should be true by default.  
> There's no setter for this property, and the default value is false in java 
> so... this means this never does scanning.
> Here's a very simple patch to fix
> {code}
> Index: 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java
> ===
> --- 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (revision 1801946)
> +++ 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (working copy)
> @@ -44,7 +44,7 @@
>  
>  public class CDISeScannerService extends AbstractMetaDataDiscovery
>  {
> -private boolean autoScanning;
> +private boolean autoScanning = true;
>  private final Collection<Class> classes = new ArrayList<>();
>  
>  public OwbAnnotationFinder getFinder()
> {code}



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

[jira] [Comment Edited] (OWB-1201) OWB Not discovering JARs in a Capsule packaged JAR

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088925#comment-16088925
 ] 

John D. Ament edited comment on OWB-1201 at 7/16/17 1:09 PM:
-

I did just give it a shot, if I use the old style bootstrap, e.g.

{code}
lifecycle = 
WebBeansContext.currentInstance().getService(ContainerLifecycle.class);
lifecycle.startApplication(null);
{code}

It works exactly as in 1.7.x, so the issue has something to do with 
SeContainerInitializer's behavior.  I'll continue to dig into it.

*And* the issues in OWB-1200 don't replicate.


was (Author: johndament):
I did just give it a shot, if I use the old style bootstrap, e.g.

{code}
lifecycle = 
WebBeansContext.currentInstance().getService(ContainerLifecycle.class);
lifecycle.startApplication(null);
{code}

It works exactly as in 1.7.x, so the issue has something to do with 
SeContainerInitializer's behavior.  I'll continue to dig into it.

> OWB Not discovering JARs in a Capsule packaged JAR
> --
>
> Key: OWB-1201
> URL: https://issues.apache.org/jira/browse/OWB-1201
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Note: this may be the root of OWB-1200
> OWB doesn't seem to discover JARs within a capsule JAR.  I package my app 
> using a bunch of dependencies, and wrap it in a capsule JAR to simplify 
> deployment (rather than having all of the JARs dumped out onto the file 
> system).
> I noticed when using OWB 1.7.3 I get this output when starting:
> {code}
> Jul 15, 2017 10:41:55 PM org.apache.webbeans.lifecycle.AbstractLifeCycle 
> bootstrapApplication
> INFO: OpenWebBeans Container is starting...
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-microprofile-1.0-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-api-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-impl-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-brave-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-spi-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-core-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/rest-cxf-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-tomcat-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-metrics-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/cxf-integration-cdi-3.1.12.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscov

[jira] [Commented] (OWB-1201) OWB Not discovering JARs in a Capsule packaged JAR

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088925#comment-16088925
 ] 

John D. Ament commented on OWB-1201:


I did just give it a shot, if I use the old style bootstrap, e.g.

{code}
lifecycle = 
WebBeansContext.currentInstance().getService(ContainerLifecycle.class);
lifecycle.startApplication(null);
{code}

It works exactly as in 1.7.x, so the issue has something to do with 
SeContainerInitializer's behavior.  I'll continue to dig into it.

> OWB Not discovering JARs in a Capsule packaged JAR
> --
>
> Key: OWB-1201
> URL: https://issues.apache.org/jira/browse/OWB-1201
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Note: this may be the root of OWB-1200
> OWB doesn't seem to discover JARs within a capsule JAR.  I package my app 
> using a bunch of dependencies, and wrap it in a capsule JAR to simplify 
> deployment (rather than having all of the JARs dumped out onto the file 
> system).
> I noticed when using OWB 1.7.3 I get this output when starting:
> {code}
> Jul 15, 2017 10:41:55 PM org.apache.webbeans.lifecycle.AbstractLifeCycle 
> bootstrapApplication
> INFO: OpenWebBeans Container is starting...
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-microprofile-1.0-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-api-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-impl-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-brave-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-spi-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-core-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/rest-cxf-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-tomcat-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-metrics-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/cxf-integration-cdi-3.1.12.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/metrics-cdi-1.3.6.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/joda-time-2.9.

[jira] [Commented] (OWB-1200) OWB 2 skips producer methods defined in annotated bean archives in SE

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1603#comment-1603
 ] 

John D. Ament commented on OWB-1200:


Agreed, this wouldn't work in an implicit bean archive.  However, this JAR is 
an explicit bean archive.  It has a beans.xml just with 
bean-discovery-mode=annotated.

> OWB 2 skips producer methods defined in annotated bean archives in SE
> -
>
> Key: OWB-1200
> URL: https://issues.apache.org/jira/browse/OWB-1200
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Here's a code sample that fails for me
> https://github.com/astefanutti/metrics-cdi/blob/29e7bac497513de420543497612180331cc5d1b3/impl/src/main/java/io/astefanutti/metrics/cdi/MetricNameFactory.java#L24
> Basically, from what I can tell OWB 2 misses this producer method, I believe 
> because it doesn't have a scope but the outer bean class does have a scope.
> AFAIK, per the spec, this is implicitly a `@Dependent` producer and should 
> have been picked up because the outer bean is defined as a dependent scoped 
> bean.



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

[jira] [Commented] (OWB-1201) OWB Not discovering JARs in a Capsule packaged JAR

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1602#comment-1602
 ] 

John D. Ament commented on OWB-1201:


Hi,

The exact same sample works correctly w/ OWB 1.7.3.  I was planning to retry w/ 
1.7.4

There's not an easy sample to debug through, but something..

1. Checkout https://github.com/hammock-project/hammock/
2. Change dist-microprofile-cochise to include owb2 instead of owb bootstrap 
module
3. Build the project
4. Then run this example: 
https://github.com/hammock-project/hammock-examples/tree/master/hammock-microprofile
 using mvn clean install -Powb and running the output capsule JAR.

> OWB Not discovering JARs in a Capsule packaged JAR
> --
>
> Key: OWB-1201
> URL: https://issues.apache.org/jira/browse/OWB-1201
> Project: OpenWebBeans
>  Issue Type: Bug
>        Reporter: John D. Ament
>
> Note: this may be the root of OWB-1200
> OWB doesn't seem to discover JARs within a capsule JAR.  I package my app 
> using a bunch of dependencies, and wrap it in a capsule JAR to simplify 
> deployment (rather than having all of the JARs dumped out onto the file 
> system).
> I noticed when using OWB 1.7.3 I get this output when starting:
> {code}
> Jul 15, 2017 10:41:55 PM org.apache.webbeans.lifecycle.AbstractLifeCycle 
> bootstrapApplication
> INFO: OpenWebBeans Container is starting...
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-microprofile-1.0-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-api-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-impl-1.8.0.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-brave-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-spi-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-core-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/rest-cxf-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-tomcat-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-metrics-1.5-SNAPSHOT.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/cxf-integration-cdi-3.1.12.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
> addWebBeansXmlLocation
> INFO: added beans archive URL: 
> jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/metrics-cdi-1.3.6.jar!/META-INF/beans.xml
> Jul 15, 2017 10:41:55 PM 
> org.apache.webbeans.

[jira] [Created] (OWB-1201) OWB Not discovering JARs in a Capsule packaged JAR

[John D. Ament (JIRA)]

John D. Ament created OWB-1201:
--

 Summary: OWB Not discovering JARs in a Capsule packaged JAR
 Key: OWB-1201
 URL: https://issues.apache.org/jira/browse/OWB-1201
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


Note: this may be the root of OWB-1200

OWB doesn't seem to discover JARs within a capsule JAR.  I package my app using 
a bunch of dependencies, and wrap it in a capsule JAR to simplify deployment 
(rather than having all of the JARs dumped out onto the file system).

I noticed when using OWB 1.7.3 I get this output when starting:

{code}
Jul 15, 2017 10:41:55 PM org.apache.webbeans.lifecycle.AbstractLifeCycle 
bootstrapApplication
INFO: OpenWebBeans Container is starting...
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-microprofile-1.0-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-api-1.8.0.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/deltaspike-core-impl-1.8.0.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-brave-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-spi-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/hammock-core-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/rest-cxf-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/web-tomcat-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/util-metrics-1.5-SNAPSHOT.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/cxf-integration-cdi-3.1.12.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
jar:file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/metrics-cdi-1.3.6.jar!/META-INF/beans.xml
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/joda-time-2.9.1.jar
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/swagger-annotations-1.5.12.jar
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/swagger-models-1.5.12.jar
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
file:/Users/johnament/.capsule/apps/hammock-microprofile-1.0-SNAPSHOT-capsule/jackson-dataformat-yaml-2.8.4.jar
Jul 15, 2017 10:41:55 PM 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery 
addWebBeansXmlLocation
INFO: added beans archive URL: 
file

[jira] [Created] (OWB-1200) OWB 2 skips producer methods defined in annotated bean archives in SE

[John D. Ament (JIRA)]

John D. Ament created OWB-1200:
--

 Summary: OWB 2 skips producer methods defined in annotated bean 
archives in SE
 Key: OWB-1200
 URL: https://issues.apache.org/jira/browse/OWB-1200
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


Here's a code sample that fails for me
https://github.com/astefanutti/metrics-cdi/blob/29e7bac497513de420543497612180331cc5d1b3/impl/src/main/java/io/astefanutti/metrics/cdi/MetricNameFactory.java#L24

Basically, from what I can tell OWB 2 misses this producer method, I believe 
because it doesn't have a scope but the outer bean class does have a scope.

AFAIK, per the spec, this is implicitly a `@Dependent` producer and should have 
been picked up because the outer bean is defined as a dependent scoped bean.



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

[jira] [Commented] (OWB-1199) CDISeScannerService.autoScanning should be true by default

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088624#comment-16088624
 ] 

John D. Ament commented on OWB-1199:


Any reason you skipped the test change?

> CDISeScannerService.autoScanning should be true by default
> --
>
> Key: OWB-1199
> URL: https://issues.apache.org/jira/browse/OWB-1199
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>    Reporter: John D. Ament
> Fix For: 2.0.1
>
> Attachments: OWB_1199.patch
>
>
> The value of CDISeScannerService.autoScanning should be true by default.  
> There's no setter for this property, and the default value is false in java 
> so... this means this never does scanning.
> Here's a very simple patch to fix
> {code}
> Index: 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java
> ===
> --- 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (revision 1801946)
> +++ 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (working copy)
> @@ -44,7 +44,7 @@
>  
>  public class CDISeScannerService extends AbstractMetaDataDiscovery
>  {
> -private boolean autoScanning;
> +private boolean autoScanning = true;
>  private final Collection<Class> classes = new ArrayList<>();
>  
>  public OwbAnnotationFinder getFinder()
> {code}



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

[jira] [Updated] (OWB-1199) CDISeScannerService.autoScanning should be true by default

[John D. Ament (JIRA)]

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

John D. Ament updated OWB-1199:
---
Attachment: OWB_1199.patch

Attached is a more complete patch with tests.

> CDISeScannerService.autoScanning should be true by default
> --
>
> Key: OWB-1199
> URL: https://issues.apache.org/jira/browse/OWB-1199
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>    Reporter: John D. Ament
> Attachments: OWB_1199.patch
>
>
> The value of CDISeScannerService.autoScanning should be true by default.  
> There's no setter for this property, and the default value is false in java 
> so... this means this never does scanning.
> Here's a very simple patch to fix
> {code}
> Index: 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java
> ===
> --- 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (revision 1801946)
> +++ 
> webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java 
> (working copy)
> @@ -44,7 +44,7 @@
>  
>  public class CDISeScannerService extends AbstractMetaDataDiscovery
>  {
> -private boolean autoScanning;
> +private boolean autoScanning = true;
>  private final Collection<Class> classes = new ArrayList<>();
>  
>  public OwbAnnotationFinder getFinder()
> {code}



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

[jira] [Created] (OWB-1199) CDISeScannerService.autoScanning should be true by default

[John D. Ament (JIRA)]

John D. Ament created OWB-1199:
--

 Summary: CDISeScannerService.autoScanning should be true by default
 Key: OWB-1199
 URL: https://issues.apache.org/jira/browse/OWB-1199
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Reporter: John D. Ament


The value of CDISeScannerService.autoScanning should be true by default.  
There's no setter for this property, and the default value is false in java 
so... this means this never does scanning.

Here's a very simple patch to fix

{code}
Index: 
webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java
===
--- 
webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java   
(revision 1801946)
+++ 
webbeans-se/src/main/java/org/apache/openwebbeans/se/CDISeScannerService.java   
(working copy)
@@ -44,7 +44,7 @@
 
 public class CDISeScannerService extends AbstractMetaDataDiscovery
 {
-private boolean autoScanning;
+private boolean autoScanning = true;
 private final Collection<Class> classes = new ArrayList<>();
 
 public OwbAnnotationFinder getFinder()
{code}



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

Re: AutoScanning off by default in SE?

[John D. Ament]

Created https://issues.apache.org/jira/browse/OWB-1199 and added a patch.

John

On Fri, Jul 14, 2017 at 8:15 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi John,
>
> should be at true by default yes
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-14 13:14 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Hi,
> >
> > I was trying to wire in Hammock w/ OWB 2.  I noticed that
> > in CDISeScannerService autoScanning isn't set.  I can't find a way to set
> > it to true.  The behavior in Weld is that this is on by default, hence
> why
> > in SeContainerInitializer there's only a disableDiscovery method.
> >
> > John
> >
>

AutoScanning off by default in SE?

[John D. Ament]

Hi,

I was trying to wire in Hammock w/ OWB 2.  I noticed that
in CDISeScannerService autoScanning isn't set.  I can't find a way to set
it to true.  The behavior in Weld is that this is on by default, hence why
in SeContainerInitializer there's only a disableDiscovery method.

John

Re: [VOTE] Release Apache OpenWebBeans-2.0.0

[John D. Ament]

Hi, Nevermind ignore the below error.

Here's my +1 to release.  Tested w/ Hammock and DeltaSpike looks good
(still that dependency issue in servlet but not a big deal).

BTW, I have a JUG talk end of the month so will be extremely good to be
able to demo w/ OWB2 at that time.

John

On Mon, Jul 10, 2017 at 7:36 AM John D. Ament <johndam...@apache.org> wrote:

> Hi Mark,
>
> I just pulled trunk and get this compilation error
>
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,14]
> cannot find symbol
>   symbol:   class E
>   location: class org.apache.webbeans.boot.OwbSeContainerInitializer
> [ERROR]
> /Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,57]
> lambda body is neither value nor void compatible
> [ERROR]
> /Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,52]
> method map in interface java.util.stream.Stream cannot be applied to
> given types;
>   required: java.util.function.Function javax.enterprise.inject.spi.Extension>,? extends R>
>   found: (c)->{ try[...]; } }
>   reason: cannot infer type-variable(s) R
> (argument mismatch; bad return type in lambda expression
>   missing return value)
>
> On Mon, Jul 10, 2017 at 7:21 AM Mark Struberg <strub...@yahoo.de> wrote:
>
>> Good afternoon!
>>
>> We are proud to call a VOTE on releasing Apache OpenWebBeans-2.0.0
>>
>> This is an implementation of the CDI-2.0 specification (JSR-365) which
>> just got released.
>>
>> We already tested it with DeltaSpike, BVal and quite a few other
>> projects, and it really looks fine so far!
>>
>> Besides implenting CDI-2.0 the following bugs and enhancements got fixed
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844=12333257
>>
>> Sub-task
>>
>> • [OWB-1185] - implement Annotated#getAnnotations
>> • [OWB-1186] - update logic for bootstrapping-events
>> • [OWB-1187] - implement configurators
>> • [OWB-1188] - implement async events
>> • [OWB-1189] - add new parts to the event-api
>> • [OWB-1190] - implement java-se support
>> • [OWB-1192] - update logic for Instance
>> • [OWB-1193] - implement InterceptionFactory
>> Bug
>>
>> • [OWB-1179] - OWB-Arquillian scanner doesn't ignore classes with
>> ClassNotFound and NoClassDefFound
>> • [OWB-1183] - OWB-Arquillian does not supports implicit bean
>> discovery mode
>> • [OWB-1184] - arquillian connector doesn't support BDAs
>> • [OWB-1196] - Signed classes can't be proxied:
>> java.lang.SecurityException: class "com.Foo$$OwbNormalScopeProxy0"'s signer
>> information does not match signer information of other classes in the same
>> package
>> • [OWB-1197] - OwbSWClassLoader creates wrong URL
>> Improvement
>>
>> • [OWB-1135] - Remove duplication for openwebbeans/Messages
>> • [OWB-1195] - do a codestyle analysis check and apply fidings
>> before releasing OWB-2.0.0
>> Task
>>
>> • [OWB-1087] - fix failing integration tests with java 8
>> • [OWB-1182] - Implement the CDI-2.0 API
>>
>>
>>
>> The staging repo is here
>>
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/
>>
>> The Source release can be found here
>>
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/org/apache/openwebbeans/openwebbeans/2.0.0/
>>
>>
>>
>> Please VOTE:
>> [+1] yeah, let's ship it
>> [+0] meh, don't care
>> [-1] no, because I found a ${showstopper}
>>
>> The VOTE is open for 72h
>>
>>
>> A special thanks to all who put their hard time into making this release
>> possible!
>>
>> txs and LieGrue,
>> the Apache OpenWebBeans team
>>
>>

Re: [VOTE] Release Apache OpenWebBeans-2.0.0

[John D. Ament]

Hi Mark,

I just pulled trunk and get this compilation error

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,14]
cannot find symbol
  symbol:   class E
  location: class org.apache.webbeans.boot.OwbSeContainerInitializer
[ERROR]
/Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,57]
lambda body is neither value nor void compatible
[ERROR]
/Users/johnament/src/openwebbeans/webbeans-impl/src/main/java/org/apache/webbeans/boot/OwbSeContainerInitializer.java:[57,52]
method map in interface java.util.stream.Stream cannot be applied to
given types;
  required: java.util.function.Function,? extends R>
  found: (c)->{ try[...]; } }
  reason: cannot infer type-variable(s) R
(argument mismatch; bad return type in lambda expression
  missing return value)

On Mon, Jul 10, 2017 at 7:21 AM Mark Struberg  wrote:

> Good afternoon!
>
> We are proud to call a VOTE on releasing Apache OpenWebBeans-2.0.0
>
> This is an implementation of the CDI-2.0 specification (JSR-365) which
> just got released.
>
> We already tested it with DeltaSpike, BVal and quite a few other projects,
> and it really looks fine so far!
>
> Besides implenting CDI-2.0 the following bugs and enhancements got fixed
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844=12333257
>
> Sub-task
>
> • [OWB-1185] - implement Annotated#getAnnotations
> • [OWB-1186] - update logic for bootstrapping-events
> • [OWB-1187] - implement configurators
> • [OWB-1188] - implement async events
> • [OWB-1189] - add new parts to the event-api
> • [OWB-1190] - implement java-se support
> • [OWB-1192] - update logic for Instance
> • [OWB-1193] - implement InterceptionFactory
> Bug
>
> • [OWB-1179] - OWB-Arquillian scanner doesn't ignore classes with
> ClassNotFound and NoClassDefFound
> • [OWB-1183] - OWB-Arquillian does not supports implicit bean
> discovery mode
> • [OWB-1184] - arquillian connector doesn't support BDAs
> • [OWB-1196] - Signed classes can't be proxied:
> java.lang.SecurityException: class "com.Foo$$OwbNormalScopeProxy0"'s signer
> information does not match signer information of other classes in the same
> package
> • [OWB-1197] - OwbSWClassLoader creates wrong URL
> Improvement
>
> • [OWB-1135] - Remove duplication for openwebbeans/Messages
> • [OWB-1195] - do a codestyle analysis check and apply fidings
> before releasing OWB-2.0.0
> Task
>
> • [OWB-1087] - fix failing integration tests with java 8
> • [OWB-1182] - Implement the CDI-2.0 API
>
>
>
> The staging repo is here
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/
>
> The Source release can be found here
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/org/apache/openwebbeans/openwebbeans/2.0.0/
>
>
>
> Please VOTE:
> [+1] yeah, let's ship it
> [+0] meh, don't care
> [-1] no, because I found a ${showstopper}
>
> The VOTE is open for 72h
>
>
> A special thanks to all who put their hard time into making this release
> possible!
>
> txs and LieGrue,
> the Apache OpenWebBeans team
>
>

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: OWB-2.0.0 to be released soon

[John D. Ament]

Ok, so I started to add the missing dependencies, that's not going to
work.  In scheduler I added log4j then it complained about some terracotta
class.  I think there's a regression in the arquillian adapter,
specifically how it handles classes that may not be present.

On Mon, Jun 19, 2017 at 8:39 PM John D. Ament <johndam...@apache.org> wrote:

> I had a hunch it was that, so did a dependency tree - no luck.
>
> https://paste.apache.org/X3c5
>
> John
>
>
> On Mon, Jun 19, 2017 at 3:22 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
>> IncompatibleClassChangeError, classpath is probably corrupted with an owb 
>> 1.0 dependency somehow
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-06-19 8:19 GMT+02:00 Mark Struberg <strub...@yahoo.de>:
>>
>>> Oh txs for the catch, will check.
>>>
>>> LieGrue,
>>> Strub
>>>
>>> Am 19.06.2017 um 04:47 schrieb John D. Ament <johndam...@apache.org>:
>>>
>>> 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 <
>>> rmannibu...@gmail.com> 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 <https://twitter.com/rmannibucau> |  Blog
>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>>
>>>> 2017-06-18 15:41 GMT+02:00 Mark Struberg <strub...@yahoo.de>:
>>>>
>>>>> 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 <johndam...@apache.org
>>>>> >:
>>>>> >
>>>>> > 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 <
>>>>> strub...@yahoo.de.invalid>
>>>>> > wrote:
>>>>> >
>>>>> >> 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 implementa

Re: OWB-2.0.0 to be released soon

[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 <rmannibu...@gmail.com>
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 <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-18 15:41 GMT+02:00 Mark Struberg <strub...@yahoo.de>:
>
>> 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 <johndam...@apache.org>:
>> >
>> > 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 <strub...@yahoo.de.invalid
>> >
>> > wrote:
>> >
>> >> 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 <johndam...@apache.org>:
>> >>>
>> >>> 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
>> <strub...@yahoo.de.invalid>
>> >> 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 <l.pe...@senat.fr>:
>> >>>>
>> >>>> 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 <strub...@yahoo.de
>> >
>> >> 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
>> >> repository [1].
>> >>>> This get's deployed via Jenkins each night.
>> >>>>
>> >>>> It would be great if you could try it out and give us some feedback!
>> >>>> We gonna release it somewhen next week.
>> >>>>
>> >>>> txs and LieGrue,
>> >>>> strub
>> >>>>
>> >>>>
>> >>>> [1] https://repository.apache.org/content/groups/snapshots/
>> >>>>
>> >>>> --
>> >>>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>> >> brièveté.
>> >>>
>> >>
>> >>
>>
>>
>

Re: OWB-2.0.0 to be released soon

[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 <strub...@yahoo.de.invalid>
wrote:

> 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 <johndam...@apache.org>:
> >
> > 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 <strub...@yahoo.de.invalid>
> 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 <l.pe...@senat.fr>:
> > >
> > > 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 <strub...@yahoo.de>
> 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
> repository [1].
> > > This get's deployed via Jenkins each night.
> > >
> > > It would be great if you could try it out and give us some feedback!
> > > We gonna release it somewhen next week.
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> > > [1] https://repository.apache.org/content/groups/snapshots/
> > >
> > > --
> > > Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
> brièveté.
> >
>
>

Re: OWB-2.0.0 to be released soon

[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
> repository [1].
> > This get's deployed via Jenkins each night.
> >
> > It would be great if you could try it out and give us some feedback!
> > We gonna release it somewhen next week.
> >
> > txs and LieGrue,
> > strub
> >
> >
> > [1] https://repository.apache.org/content/groups/snapshots/
> >
> > --
> > Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
> brièveté.
>
>

[jira] [Commented] (OWB-1190) implement java-se support

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029241#comment-16029241
 ] 

John D. Ament commented on OWB-1190:


I started playing around with this. It seems like the right course of action is 
to introduce a new {{ScannerService}} that supports the buildable options (and 
more?) that are defined by the CDI spec.  It may make sense to add a bit more 
power to classes like ExtensionLoader to handle the use cases.  It seems that 
the expected behavior is that these Extensions are loaded in addition to what's 
defined in the service loader.

> implement java-se support
> -
>
> Key: OWB-1190
> URL: https://issues.apache.org/jira/browse/OWB-1190
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Gerhard Petracek
> Fix For: 2.0.0
>
>
> new parts:
>  * SeContainer
>  * SeContainerInitializer



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Build failed in Jenkins: OpenWebBeans-trunk #1204

[John D. Ament]

I updated the build to point to 1.8.

John

On Mon, May 29, 2017 at 6:53 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/OpenWebBeans-trunk/1204/display/redirect?page=changes
> >
>
> Changes:
>
> [struberg] OWB-1186 implement ProcessSyntheticObserverMethod and
> ProcessSyntheticBean
>
> [struberg] OWB-1182 improve Instance handling
>
> [struberg] OWB-1182 improve Instance handling
>
> [struberg] OWB-1182 disable another broken test
>
> [struberg] OWB-1184 move our Arquillian connector to implement the
> BdaScannerService
>
> This is needed to also support trimmed BDAs in the TCKs
>
> [struberg] OWB-1182 remove further challenged test
>
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-1 (ubuntu trusty) in workspace <
> https://builds.apache.org/job/OpenWebBeans-trunk/ws/>
> Cleaning up 
> Updating https://svn.apache.org/repos/asf/openwebbeans/trunk at revision
> '2017-05-29T22:51:09.818 +'
> A
>  
> webbeans-arquillian/owb-arquillian-standalone/src/test/java/org/apache/webbeans/arquillian/test/OwbArquillianTrimmedBdaJarDeploymentTest.java
> U
>  
> webbeans-arquillian/owb-arquillian-standalone/src/main/java/org/apache/webbeans/arquillian/standalone/OwbArquillianScannerService.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/event/ContainerEventObserverMethodImpl.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/container/InjectableBeanManager.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java
> U
>  webbeans-impl/src/main/java/org/apache/webbeans/container/OwbCDI.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/component/creation/ObserverMethodsBuilder.java
> U
>  webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/config/OpenWebBeansConfiguration.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/ProcessObserverMethodImpl.java
> D
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/generics/GProcessObservableMethod.java
> AU
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/generics/GProcessSyntheticObserverMethod.java
> AU
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/generics/GProcessObserverMethod.java
> AU
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/generics/GProcessSyntheticBean.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/discovery/ExtensionAware.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/discovery/AfterTypeDiscoveryImpl.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/discovery/AfterBeanDiscoveryImpl.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/portable/events/discovery/BeforeBeanDiscoveryImpl.java
> U
>  
> webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java
> U
>  webbeans-impl/src/main/java/org/apache/webbeans/util/WebBeansUtil.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/unittests/event/exception/EventExceptionTest.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/unittests/event/EventTest.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/event/TypeArgumentObserver.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/event/TypeArgumentInterfaceObserver.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/component/third/ThirdPartyExtension.java
> U
>  
> webbeans-impl/src/test/java/org/apache/webbeans/test/instance/InstanceQualifierInjectionPointTest.java
> U webbeans-tck/standalone-suite.xml
> U
>  webbeans-tck/src/main/resources/META-INF/openwebbeans/openwebbeans.properties
> At revision 1796717
>
> [locks-and-latches] Checking to see if we really have the locks
> [locks-and-latches] Have all the locks, build can start
> Parsing POMs
> Modules changed, recalculating dependency graph
> Established TCP socket on 38180
> maven33-agent.jar already up to date
> maven33-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [trunk] $ /home/jenkins/tools/java/latest1.7/bin/java -Xmx2g -Xms256m -cp
> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/latest/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/latest/conf/logging
> jenkins.maven3.agent.Maven33Main /home/jenkins/tools/maven/latest/
> /home/jenkins/jenkins-slave/slave.jar
> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 38180
> <===[JENKINS REMOTING CAPACITY]===>   channel started
> Executing Maven:  -B 

Re: [VOTE] Release Apache Meecrowave-0.2.0

[John D. Ament]

Its OK, I've moved the question over to legal-discuss.

On Tue, Jan 3, 2017 at 12:32 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Please reread the link you posted:
>
> "Which Files Must Contain An ASF License Text?¶
>
> Every source file must contain the appropriate ASF License text or
> boilerplate notice."
>
>
> You don't verify the source of a binary because it's not a source. This is
> the same as not being able to verify the license of a png or jpeg via a
> license header - because those binary formats don't have any.
> But we can verify the license of the file. Romain wrote those files and
> there is a proper NOTICE and LICENSE file in the jars.
>
> It's not perfect that we have those files in the source zip, but it is
> legally perfectly fine.
>
> LieGrue,
> strub
>
>
> > Am 02.01.2017 um 23:38 schrieb John D. Ament <john.d.am...@gmail.com>:
> >
> > Unfortunately that means users have no way of verifying the license [1]
> >
> >
> >
> > [1]: http://www.apache.org/dev/release.html#which-files-contain-license
> >
> >
> > On Mon, Jan 2, 2017 at 5:30 PM Mark Struberg <strub...@yahoo.de.invalid>
> > wrote:
> >
> >> Not really elegant, but the class is really more like a real resource.
> >> It's also in SVN:
> >>
> >>
> https://svn.apache.org/repos/asf/openwebbeans/meecrowave/tags/meecrowave-0.2.0/meecrowave-core/src/test/resources/org/superbiz/app-res/
> >>
> >> In any case thanks for the review!
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 02.01.2017 um 23:00 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> This is part of the way a few (1 or 2) tests are written. This is
> >> intended
> >>> for now.
> >>>
> >>> Le 2 janv. 2017 22:11, "John D. Ament" <johndam...@apache.org> a
> écrit :
> >>>
> >>> You have two binaries in the source release:
> >>>
> >>> ./meecrowave-core/src/test/resources/org/superbiz/app-
> >>> res/OtherEndpoint.class
> >>>
> >>
> ./meecrowave-core/src/test/resources/org/superbiz/app-res/OtherFilter.class
> >>>
> >>> The allowable ASF binaries are usually graphics, not class files (which
> >> are
> >>> usually compiled java source files).  These both appear to be compiled
> >>> source files.
> >>>
> >>> John
> >>>
> >>> On Mon, Jan 2, 2017 at 12:08 PM Mark Struberg
> <strub...@yahoo.de.invalid
> >>>
> >>> wrote:
> >>>
> >>>> Hi all!
> >>>>
> >>>> It's time to do our very first Meecrowave release!
> >>>> And since we already use it in some production systems we upped the
> >>>> version from 0.0.1 to 0.2.0.
> >>>>
> >>>> Here is the staging repo
> >>>>
> >>>> https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1021/
> >>>>
> >>>> And here comes the source release zip:
> >>>>
> >>>> https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave/0.2.0/
> >>>>
> >>>> My gpg key can be found at
> >>>> https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
> >>>>
> >>>> So what is Apache Meecrowave (tm)?
> >>>>
> >>>> Meecrowave is a lightweight bundle of
> >>>>
> >>>> * Servlet-4.0 (Apache Tomcat 9.0.0.M15)
> >>>> * CDI-1.2 (Apache OpenWebBeans-1.7.1)
> >>>> * JAX-RS (Apache CXF-3.1.9)
> >>>> * JSON-P-1.0 (Apache Johnzon-1.0.0)
> >>>>
> >>>> And all that within only 9MB!
> >>>>
> >>>> Want to test it?
> >>>> Just download
> >>>>
> >>>> https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave-core/0.2.0/
> >>> meecrowave-core-0.2.0-runner.jar
> >>>> (sha1
> >>>> <https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave-core/0.2.0/
> >>> meecrowave-core-0.2.0-runner.jar(sha1>:
> >>>> 042a2b4344c494cff378f072423ed8bb4a2ea93a)
> >>>> and type
> >>>>
> >>>> For running an existing.war file:
> >>>> java -jar meecrowave-core-0.2.0-runner.jar existing.war
> >>>>
> >>>> For running an existing-fat.jar file:
> >>>> java -jar meecrowave-core-0.2.0-runner.jar existing-fat.jar
> >>>>
> >>>> Meecrowave can do a lot more.
> >>>> We will host and imporove the docs at
> >>>> http://openwebbeans.apache.org/meecrowave/
> >>>>
> >>>>
> >>>> Please VOTE:
> >>>> [+1] great, let's ship it
> >>>> [+0] meh, don't care
> >>>> [-1] stop there is a ${blocker}
> >>>>
> >>>> The VOTE is open for 72h.
> >>>>
> >>>>
> >>>> txs and LieGrue,
> >>>> strub
> >>>>
> >>>> PS: thanks to Romain for pushing this!
> >>
> >>
>
>

Re: [VOTE] Release Apache Meecrowave-0.2.0

[John D. Ament]

Unfortunately that means users have no way of verifying the license [1]



[1]: http://www.apache.org/dev/release.html#which-files-contain-license


On Mon, Jan 2, 2017 at 5:30 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Not really elegant, but the class is really more like a real resource.
> It's also in SVN:
>
> https://svn.apache.org/repos/asf/openwebbeans/meecrowave/tags/meecrowave-0.2.0/meecrowave-core/src/test/resources/org/superbiz/app-res/
>
> In any case thanks for the review!
>
> LieGrue,
> strub
>
>
> > Am 02.01.2017 um 23:00 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > This is part of the way a few (1 or 2) tests are written. This is
> intended
> > for now.
> >
> > Le 2 janv. 2017 22:11, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> > You have two binaries in the source release:
> >
> > ./meecrowave-core/src/test/resources/org/superbiz/app-
> > res/OtherEndpoint.class
> >
> ./meecrowave-core/src/test/resources/org/superbiz/app-res/OtherFilter.class
> >
> > The allowable ASF binaries are usually graphics, not class files (which
> are
> > usually compiled java source files).  These both appear to be compiled
> > source files.
> >
> > John
> >
> > On Mon, Jan 2, 2017 at 12:08 PM Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> >> Hi all!
> >>
> >> It's time to do our very first Meecrowave release!
> >> And since we already use it in some production systems we upped the
> >> version from 0.0.1 to 0.2.0.
> >>
> >> Here is the staging repo
> >>
> >> https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1021/
> >>
> >> And here comes the source release zip:
> >>
> >> https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave/0.2.0/
> >>
> >> My gpg key can be found at
> >> https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
> >>
> >> So what is Apache Meecrowave (tm)?
> >>
> >> Meecrowave is a lightweight bundle of
> >>
> >> * Servlet-4.0 (Apache Tomcat 9.0.0.M15)
> >> * CDI-1.2 (Apache OpenWebBeans-1.7.1)
> >> * JAX-RS (Apache CXF-3.1.9)
> >> * JSON-P-1.0 (Apache Johnzon-1.0.0)
> >>
> >> And all that within only 9MB!
> >>
> >> Want to test it?
> >> Just download
> >>
> >> https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave-core/0.2.0/
> > meecrowave-core-0.2.0-runner.jar
> >> (sha1
> >> <https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave-core/0.2.0/
> > meecrowave-core-0.2.0-runner.jar(sha1>:
> >> 042a2b4344c494cff378f072423ed8bb4a2ea93a)
> >> and type
> >>
> >> For running an existing.war file:
> >> java -jar meecrowave-core-0.2.0-runner.jar existing.war
> >>
> >> For running an existing-fat.jar file:
> >> java -jar meecrowave-core-0.2.0-runner.jar existing-fat.jar
> >>
> >> Meecrowave can do a lot more.
> >> We will host and imporove the docs at
> >> http://openwebbeans.apache.org/meecrowave/
> >>
> >>
> >> Please VOTE:
> >> [+1] great, let's ship it
> >> [+0] meh, don't care
> >> [-1] stop there is a ${blocker}
> >>
> >> The VOTE is open for 72h.
> >>
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >> PS: thanks to Romain for pushing this!
>
>

Re: [VOTE] Release Apache Meecrowave-0.2.0

[John D. Ament]

You have two binaries in the source release:

./meecrowave-core/src/test/resources/org/superbiz/app-res/OtherEndpoint.class
./meecrowave-core/src/test/resources/org/superbiz/app-res/OtherFilter.class

The allowable ASF binaries are usually graphics, not class files (which are
usually compiled java source files).  These both appear to be compiled
source files.

John

On Mon, Jan 2, 2017 at 12:08 PM Mark Struberg 
wrote:

> Hi all!
>
> It's time to do our very first Meecrowave release!
> And since we already use it in some production systems we upped the
> version from 0.0.1 to 0.2.0.
>
> Here is the staging repo
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1021/
>
> And here comes the source release zip:
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave/0.2.0/
>
> My gpg key can be found at
> https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
>
> So what is Apache Meecrowave (tm)?
>
> Meecrowave is a lightweight bundle of
>
> * Servlet-4.0 (Apache Tomcat 9.0.0.M15)
> * CDI-1.2 (Apache OpenWebBeans-1.7.1)
> * JAX-RS (Apache CXF-3.1.9)
> * JSON-P-1.0 (Apache Johnzon-1.0.0)
>
> And all that within only 9MB!
>
> Want to test it?
> Just download
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1021/org/apache/meecrowave/meecrowave-core/0.2.0/meecrowave-core-0.2.0-runner.jar
> (sha1
> :
> 042a2b4344c494cff378f072423ed8bb4a2ea93a)
> and type
>
> For running an existing.war file:
> java -jar meecrowave-core-0.2.0-runner.jar existing.war
>
> For running an existing-fat.jar file:
> java -jar meecrowave-core-0.2.0-runner.jar existing-fat.jar
>
> Meecrowave can do a lot more.
> We will host and imporove the docs at
> http://openwebbeans.apache.org/meecrowave/
>
>
> Please VOTE:
> [+1] great, let's ship it
> [+0] meh, don't care
> [-1] stop there is a ${blocker}
>
> The VOTE is open for 72h.
>
>
> txs and LieGrue,
> strub
>
> PS: thanks to Romain for pushing this!

[jira] [Commented] (OWB-1164) Third Party Beans do not include Any qualifier if not included in bean impl

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15785470#comment-15785470
 ] 

John D. Ament commented on OWB-1164:


[~rmannibucau] I see you made some changes on top of my patch.  There is one 
gotcha now.  If I change my bean to use this:

{code:java}
@Override
public Set getQualifiers()
{
Set qualifiers = new HashSet<>();
qualifiers.add(new AnyLiteral());
return qualifiers;
}
{code}

Where {{AnyLiteral}} is defined as:

{code:java}
public static class AnyLiteral implements Any
{
@Override
public Class annotationType() {
return Any.class;
}
}
{code}

I'll point out that the use of {{AnnotationLiteral}} is meant as a convenience. 
 OWB and Weld both support direct annotation subclassing like I used here.  
With your logic in place, then the bean ends up with two any qualifiers, which 
is strictly prohibited in CDI 1.2.  Using this logic gives some of the clean up 
you did but retains the check for classes.

{code:java}
private Set calculateQualifiers(final BeanAttributes 
beanAttributes)
{
final Set originalQualifiers = 
beanAttributes.getQualifiers() == null ?
Collections.emptySet() : 
beanAttributes.getQualifiers();
for(Annotation a : originalQualifiers)
{
if(a instanceof Any)
{
return originalQualifiers;
}
}
final Set newQualifiers = new HashSet<>(originalQualifiers);
newQualifiers.add(AnyLiteral.INSTANCE);
return newQualifiers;
}
{code}

> Third Party Beans do not include Any qualifier if not included in bean impl
> ---
>
> Key: OWB-1164
> URL: https://issues.apache.org/jira/browse/OWB-1164
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: John D. Ament
> Fix For: 1.7.1
>
> Attachments: 
> 0001-OWB-1164-Introduce-ThirdpartyBeanAttributes-to-calcu.patch
>
>
> Section 2.3.1 of CDI 1.2 spec indicates that custom beans should include the 
> any qualifier even if not specified by the bean impl.  OWB does not honor 
> this, instead only the original qualifiers are included in the bean.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OWB-1164) Third Party Beans do not include Any qualifier if not included in bean impl

[John D. Ament (JIRA)]

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

John D. Ament updated OWB-1164:
---
Affects Version/s: 1.7.0

> Third Party Beans do not include Any qualifier if not included in bean impl
> ---
>
> Key: OWB-1164
> URL: https://issues.apache.org/jira/browse/OWB-1164
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.7.0
>    Reporter: John D. Ament
> Fix For: 1.7.0
>
> Attachments: 
> 0001-OWB-1164-Introduce-ThirdpartyBeanAttributes-to-calcu.patch
>
>
> Section 2.3.1 of CDI 1.2 spec indicates that custom beans should include the 
> any qualifier even if not specified by the bean impl.  OWB does not honor 
> this, instead only the original qualifiers are included in the bean.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Programmatic instance look up

[John D. Ament]

Created and added patch to https://issues.apache.org/jira/browse/OWB-1164
If you guys want to take a look.  I can also raise a PR but since you're on
SVN... dunno.

John

On Wed, Dec 28, 2016 at 4:05 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Ok, can do it tmr if nobody beats me at it
>
> Le 28 déc. 2016 21:41, "Mark Struberg" <strub...@yahoo.de.invalid> a
> écrit :
>
> > John is right, we should likely check for @Any in ThirdPartyBean and add
> > it if missing.
> >
> >
> > LieGrue,
> > Strub
> >
> >
> > > Am 28.12.2016 um 14:44 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Almost there too except on "declare qualifier" which was for me through
> > > annotation which implied custom beans had to do it themself. Not sure
> to
> > be
> > > honest.
> > >
> > > @Mark: how do you read it on your side?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-12-28 14:42 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > >
> > >> It does not.  I'm not sure I should add it though.  When I look at the
> > >> relevant section of the spec
> > >> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#programmatic_lookup
> > >> <http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#
> > programmatic_lookup>
> > >> the
> > >> example mentions that the resulting bean only has the selected
> > qualifier.
> > >>
> > >> In addition section 2.3.1
> > >> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_qualifiers
> > says
> > >> "Every bean has the built-in qualifier @Any, even if it does not
> > explicitly
> > >> declare this qualifier," so it sounds like the correct thing to do is
> to
> > >> add @Any to any custom registered beans.
> > >>
> > >> So that means the test is right, just something missing when
> > >> programmatically adding beans.
> > >>
> > >> John
> > >>
> > >> On Wed, Dec 28, 2016 at 8:33 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >>> I'm not sure about this one since pretty much all beans should match
> > Any,
> > >>> is my assumption your database bean doesnt add it correct?
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > >>> <http://rmannibucau.wordpress.com> | Github <
> > >>> https://github.com/rmannibucau> |
> > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > >>> <https://javaeefactory-rmannibucau.rhcloud.com>
> > >>>
> > >>> 2016-12-28 14:29 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > >>>
> > >>>> Looks like you already applied a fix.  There's still one issue.
> Your
> > >>> bean
> > >>>> behind CDI.current() has an any qualifier on it.  AFAIK it should
> not.
> > >>>> This causes programmatic lookup to try to include Any in the
> > qualifiers
> > >>>> which doesn't make sense.  Since you fixed the NPE now I'm able to
> see
> > >>> that
> > >>>> (
> > >>>>
> > >>>> Qualifiers:
> > >>>> [@javax.enterprise.inject.Any(),@ws.ament.hammock.jpa.
> > >>>> Database(value="__default")]
> > >>>> )
> > >>>>
> > >>>> I'm inclined to say that InstanceBean should be extended to have a
> > >> second
> > >>>> constructor which takes qualifiers (since @any is expected in
> @Inject
> > >>> @Any
> > >>>> Instance) and pass that up the chain.  Can be as simple as
> > >> calling
> > >>>> the other constructor in BeanAttribut

[jira] [Created] (OWB-1164) Third Party Beans do not include Any qualifier if not included in bean impl

[John D. Ament (JIRA)]

John D. Ament created OWB-1164:
--

 Summary: Third Party Beans do not include Any qualifier if not 
included in bean impl
 Key: OWB-1164
 URL: https://issues.apache.org/jira/browse/OWB-1164
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament
 Fix For: 1.7.0


Section 2.3.1 of CDI 1.2 spec indicates that custom beans should include the 
any qualifier even if not specified by the bean impl.  OWB does not honor this, 
instead only the original qualifiers are included in the bean.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Programmatic instance look up

[John D. Ament]

It does not.  I'm not sure I should add it though.  When I look at the
relevant section of the spec
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#programmatic_lookup
<http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#programmatic_lookup> the
example mentions that the resulting bean only has the selected qualifier.

In addition section 2.3.1
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_qualifiers says
"Every bean has the built-in qualifier @Any, even if it does not explicitly
declare this qualifier," so it sounds like the correct thing to do is to
add @Any to any custom registered beans.

So that means the test is right, just something missing when
programmatically adding beans.

John

On Wed, Dec 28, 2016 at 8:33 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> I'm not sure about this one since pretty much all beans should match Any,
> is my assumption your database bean doesnt add it correct?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-12-28 14:29 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> > Looks like you already applied a fix.  There's still one issue.  Your
> bean
> > behind CDI.current() has an any qualifier on it.  AFAIK it should not.
> > This causes programmatic lookup to try to include Any in the qualifiers
> > which doesn't make sense.  Since you fixed the NPE now I'm able to see
> that
> > (
> >
> > Qualifiers:
> > [@javax.enterprise.inject.Any(),@ws.ament.hammock.jpa.
> > Database(value="__default")]
> > )
> >
> > I'm inclined to say that InstanceBean should be extended to have a second
> > constructor which takes qualifiers (since @any is expected in @Inject
> @Any
> > Instance) and pass that up the chain.  Can be as simple as calling
> > the other constructor in BeanAttributesImpl.
> >
> > I haven't tried it yet, but I suspect you may need to strip Any from the
> > qualifiers as well.  I think the
> > test InstanceQualifierInjectionPointTest.checkQualfiers may be incorrect
> > as
> > well.
> >
> > I can give you a patch to fix this if you're in agreement that it's right
> > course of action.
> >
> > John
> >
> > On Wed, Dec 28, 2016 at 5:13 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > think I spotted the issue(s):
> > >
> > > 1. a NPE when missing an injection point (trivial to solve)
> > > 2. we dont strip Default qualifier when user
> > > select(AnotherQualifier.LITERAL) which leads to something pretty much
> > never
> > > resolvable
> > >
> > > will check if i can fix it in my spare time today
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-12-28 10:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > looks like a bug, we reused InstanceBean (https://github.com/apache/
> > > > openwebbeans/blob/trunk/webbeans-impl/src/main/java/
> > > > org/apache/webbeans/container/OwbCDI.java#L45) but this only works
> > with
> > > > injection points. Using our injection resolver would work (from the
> > > > webbeanscontext).
> > > >
> > > > We have a release coming very soon, do you want to propose a patch?
> > Happy
> > > > to help if you need.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github
> > > > <https://github.com/rmannibucau> | LinkedIn
> > > > <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-12-28 1:08 GMT+01:00 John D. Ament &l

Re: Programmatic instance look up

[John D. Ament]

Looks like you already applied a fix.  There's still one issue.  Your bean
behind CDI.current() has an any qualifier on it.  AFAIK it should not.
This causes programmatic lookup to try to include Any in the qualifiers
which doesn't make sense.  Since you fixed the NPE now I'm able to see that
(

Qualifiers:
[@javax.enterprise.inject.Any(),@ws.ament.hammock.jpa.Database(value="__default")]
)

I'm inclined to say that InstanceBean should be extended to have a second
constructor which takes qualifiers (since @any is expected in @Inject @Any
Instance) and pass that up the chain.  Can be as simple as calling
the other constructor in BeanAttributesImpl.

I haven't tried it yet, but I suspect you may need to strip Any from the
qualifiers as well.  I think the
test InstanceQualifierInjectionPointTest.checkQualfiers may be incorrect as
well.

I can give you a patch to fix this if you're in agreement that it's right
course of action.

John

On Wed, Dec 28, 2016 at 5:13 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> think I spotted the issue(s):
>
> 1. a NPE when missing an injection point (trivial to solve)
> 2. we dont strip Default qualifier when user
> select(AnotherQualifier.LITERAL) which leads to something pretty much never
> resolvable
>
> will check if i can fix it in my spare time today
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-12-28 10:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > looks like a bug, we reused InstanceBean (https://github.com/apache/
> > openwebbeans/blob/trunk/webbeans-impl/src/main/java/
> > org/apache/webbeans/container/OwbCDI.java#L45) but this only works with
> > injection points. Using our injection resolver would work (from the
> > webbeanscontext).
> >
> > We have a release coming very soon, do you want to propose a patch? Happy
> > to help if you need.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-12-28 1:08 GMT+01:00 John D. Ament <johndam...@apache.org>:
> >
> >> Its a single classloader.  Programmatic lookup is just
> >>
> >> CDI.current().select(SomeClass.class).select(someAnnotationL
> >> iteral).get();
> >>
> >> This fails, I would imagine, at least last time I did this on OWB,
> because
> >> there's no injection point defined
> >>
> >> @Inject
> >> @SomeAnnotation
> >> private SomeClass sc;
> >>
> >> and the bean has scope dependent.
> >>
> >> John
> >>
> >> On Tue, Dec 27, 2016 at 6:29 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Hi John
> >> >
> >> > What does the lookup look like? Using the related bean manager un
> >> several
> >> > apps with success.
> >> >
> >> > Side note: is your classloader well setup?
> >> >
> >> >
> >> > Le 27 déc. 2016 23:29, "John D. Ament" <johndam...@apache.org> a
> écrit
> >> :
> >> >
> >> > > Hi,
> >> > >
> >> > > So I'm starting to run into my old friend, where instance doesn't
> work
> >> > the
> >> > > same in OWB and Weld.  Basically anytime I use CDI.current() to
> >> resolve a
> >> > > bean, it fails.  The same lookup works when using
> >> > BeanManager.getReference,
> >> > > or even the DeltaSpike utilities.
> >> > >
> >> > > My understanding is that I should be able to look up any bean via
> >> > > CDI.current() not just beans that have injection targets.  So I was
> >> > > wondering, would it make sense to relax the requirement on injection
> >> > > points?
> >> > >
> >> > > John
> >> > >
> >> >
> >>
> >
> >
>

Re: Programmatic instance look up

[John D. Ament]

Its a single classloader.  Programmatic lookup is just

CDI.current().select(SomeClass.class).select(someAnnotationLiteral).get();

This fails, I would imagine, at least last time I did this on OWB, because
there's no injection point defined

@Inject
@SomeAnnotation
private SomeClass sc;

and the bean has scope dependent.

John

On Tue, Dec 27, 2016 at 6:29 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi John
>
> What does the lookup look like? Using the related bean manager un several
> apps with success.
>
> Side note: is your classloader well setup?
>
>
> Le 27 déc. 2016 23:29, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > Hi,
> >
> > So I'm starting to run into my old friend, where instance doesn't work
> the
> > same in OWB and Weld.  Basically anytime I use CDI.current() to resolve a
> > bean, it fails.  The same lookup works when using
> BeanManager.getReference,
> > or even the DeltaSpike utilities.
> >
> > My understanding is that I should be able to look up any bean via
> > CDI.current() not just beans that have injection targets.  So I was
> > wondering, would it make sense to relax the requirement on injection
> > points?
> >
> > John
> >
>

Programmatic instance look up

[John D. Ament]

Hi,

So I'm starting to run into my old friend, where instance doesn't work the
same in OWB and Weld.  Basically anytime I use CDI.current() to resolve a
bean, it fails.  The same lookup works when using BeanManager.getReference,
or even the DeltaSpike utilities.

My understanding is that I should be able to look up any bean via
CDI.current() not just beans that have injection targets.  So I was
wondering, would it make sense to relax the requirement on injection points?

John

Re: Handling bootstrap for mixed SE/Servlet scenario

[John D. Ament]

Ok, so in the end I did have to sublcass WebBeansConfigurationListener.
The issue I ran into was that in contextInitialized you're attempting to
start the application.  Since I do my servlet initialization in a @Observes
@Initialized(ApplicationScoped.class) callback, OWB was firing the event
that was already in progress.  This causes a stackoverflow.  My overridden
version doesn't do the application start up logic.

I don't know if it makes sense to roll this listener into OWB instead of
keeping it outside.  It could be controlled via external configuration I
suppose.  Everything else seems to work well.

Let me know, I can provide a patch.

John

On Tue, Dec 27, 2016 at 12:27 AM John D. Ament <johndam...@apache.org>
wrote:

> Nevermind, I forgot about openwebbeans.properties.  Mix and match for the
> win.
>
> John
>
>
> On Mon, Dec 26, 2016 at 11:55 PM John D. Ament <johndam...@apache.org>
> wrote:
>
> Hi,
>
> So let's say I'm using Tomcat embedded and OWB.  I bootstrap OWB using its
> normal function, and I have impl, web and resource on my classpath.  When I
> ask for the ContainerLifecycle service, I get back a WebContainerLifecycle
> since I have web on the classpath.  So I'm wondering, does it make sense to
> create a fake servlet context in this scenario?  I believe if I do that,
> OWB will treat these as two different contexts and as a result the
> instances won't be shared.
>
> I'm almost thinking this would require a new plugin in OWB that did a lot
> of the same work, however it allows the sharing of the context.  Thoughts?
>
> John
>
>

Re: Handling bootstrap for mixed SE/Servlet scenario

[John D. Ament]

Nevermind, I forgot about openwebbeans.properties.  Mix and match for the
win.

John

On Mon, Dec 26, 2016 at 11:55 PM John D. Ament <johndam...@apache.org>
wrote:

> Hi,
>
> So let's say I'm using Tomcat embedded and OWB.  I bootstrap OWB using its
> normal function, and I have impl, web and resource on my classpath.  When I
> ask for the ContainerLifecycle service, I get back a WebContainerLifecycle
> since I have web on the classpath.  So I'm wondering, does it make sense to
> create a fake servlet context in this scenario?  I believe if I do that,
> OWB will treat these as two different contexts and as a result the
> instances won't be shared.
>
> I'm almost thinking this would require a new plugin in OWB that did a lot
> of the same work, however it allows the sharing of the context.  Thoughts?
>
> John
>

Handling bootstrap for mixed SE/Servlet scenario

[John D. Ament]

Hi,

So let's say I'm using Tomcat embedded and OWB.  I bootstrap OWB using its
normal function, and I have impl, web and resource on my classpath.  When I
ask for the ContainerLifecycle service, I get back a WebContainerLifecycle
since I have web on the classpath.  So I'm wondering, does it make sense to
create a fake servlet context in this scenario?  I believe if I do that,
OWB will treat these as two different contexts and as a result the
instances won't be shared.

I'm almost thinking this would require a new plugin in OWB that did a lot
of the same work, however it allows the sharing of the context.  Thoughts?

John

Re: CDI 2.0 Spec JAR

[John D. Ament]

Yep, thats all necessary.  Once thats in, cdi spec jar should be buildable.

John

On Mon, Jul 11, 2016 at 3:54 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> cool guys!
>
> +1 daniel, the patch looks good
>
> 2016-07-11 21:51 GMT+02:00 Daniel Cunha <daniels...@gmail.com>:
>
> > Cool!
> >
> > I have a patch to update maven-bundle-plugin and maven-checkstyle-plugin.
> > I had work on some changes on branch cdi-2.0 and I get some problems with
> > java8.
> >
> > It's necessary update this plugins to have build working fine, so I'll be
> > possible to use java8 features on the code. :)
> >
> > Let me see what do you think about it:
> > https://issues.apache.org/jira/browse/OWB-1134
> >
> > On Mon, Jul 11, 2016 at 11:50 AM, Mark Struberg
> <strub...@yahoo.de.invalid
> > >
> > wrote:
> >
> > > txs will apply.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > >
> > > > On Monday, 11 July 2016, 2:43, John D. Ament <johndam...@apache.org>
> > > wrote:
> > > > > I've raised a JIRA with the API changes that I noticed.  There
> might
> > > be a
> > > > few more pending.  I tested it against Weld, apparently they're
> behind
> > a
> > > > little bit as well.
> > > >
> > > > https://issues.apache.org/jira/browse/GERONIMO-6553
> > > >
> > > > - John
> > > >
> > > >
> > > > On Wed, Jul 6, 2016 at 2:46 PM Mark Struberg
> <strub...@yahoo.de.invalid
> > >
> > > > wrote:
> > > >
> > > >>  >  Only constraint we
> > > >>  > have is to not copy official comments/spec AFAIK.
> > > >>
> > > >>  Except we wrote that stuff ourselves for the spec. In that case the
> > > >>  original author is of course free to also contribute it to the ASF
> > > under
> > > >>  ALv2.
> > > >>
> > > >>  LieGrue,
> > > >>  strub
> > > >>
> > > >>
> > > >>
> > > >>  > Am 03.07.2016 um 23:01 schrieb Romain Manni-Bucau
> > > > <rmannibu...@gmail.com
> > > >>  >:
> > > >>  >
> > > >>  > Le 3 juil. 2016 22:56, "John D. Ament"
> > > > <johndam...@apache.org> a écrit :
> > > >>  >>
> > > >>  >> geronimo@ who?
> > > >>  >
> > > >>  > Dev list
> > > >>  >
> > > >>  >>
> > > >>  >> I emailed the OWB list as the OWB team is maintaining the JAR,
> > > > there's
> > > >>  > just
> > > >>  >> considerable overlap w/ the geronimo PMC that it becomes
> > > > confusing.
> > > >>  >>
> > > >>  >
> > > >>  > Well you can also see geronimo community is doing so since people
> > > >>  overlap a
> > > >>  > lot there but strictly speaking this jar is not always driven by
> > owb.
> > > >>  >
> > > >>  >> What about my comments about the javadocs?
> > > >>  >>
> > > >>  >
> > > >>  > It is usually best effort but im +1 to make it better. Only
> > > constraint
> > > > we
> > > >>  > have is to not copy official comments/spec AFAIK.
> > > >>  >
> > > >>  >> John
> > > >>  >>
> > > >>  >> On Sun, Jul 3, 2016 at 3:24 PM Romain Manni-Bucau <
> > > >>  rmannibu...@gmail.com>
> > > >>  >> wrote:
> > > >>  >>
> > > >>  >>> Hi John,
> > > >>  >>>
> > > >>  >>> -> geronimo@ ;)
> > > >>  >>>
> > > >>  >>> Otherwise +1 for jenkins and to replace current 2.0 by an up
> > > > to date
> > > >>  >>> version
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> Romain Manni-Bucau
> > > >>  >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >>  >>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress
> > > > Blog
> > > >>  >>> <http://rmannibucau.wordpress.com> | Github <
> > > >>  >>> https://github.com/rmannibucau> |
> > > >>  >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> > > > Tomitriber
> > > >>  >>> <http://www.tomitribe.com> | JavaEE Factory
> > > >>  >>> <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >>  >>>
> > > >>  >>> 2016-07-03 15:10 GMT+02:00 John D. Ament
> > > > <johndam...@apache.org>:
> > > >>  >>>
> > > >>  >>>> Hey guys
> > > >>  >>>>
> > > >>  >>>> I'm looking at the current state of the Geronimo CDI 2
> > > > spec jar.  I'm
> > > >>  >>>> wondering, what version of CDI 2 is it based on currently?
> > > >>  >>>>
> > > >>  >>>> In addition, I'm planning to apply patches to it based
> > > > on the changes
> > > >>  > in
> > > >>  >>>> CDI 2.  I notice that unlike most geronimo specs, its
> > > > pretty heavy on
> > > >>  >>>> javadocs.  I plan to restate them, similar to what i'm
> > > > seeing in here.
> > > >>  >>>>
> > > >>  >>>> I'm wondering if we can enable a build in jenkins to
> > > > build the JAR?
> > > >>  >>>>
> > > >>  >>>> John
> > > >>  >>>>
> > > >>  >>>
> > > >>
> > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Daniel Cunha
> > https://twitter.com/dvlc_
> > http://www.tomitribe.com
> > http://www.tomitribe.io
> >
>

Re: CDI 2.0 Spec JAR

[John D. Ament]

I've raised a JIRA with the API changes that I noticed.  There might be a
few more pending.  I tested it against Weld, apparently they're behind a
little bit as well.

https://issues.apache.org/jira/browse/GERONIMO-6553

- John

On Wed, Jul 6, 2016 at 2:46 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> >  Only constraint we
> > have is to not copy official comments/spec AFAIK.
>
> Except we wrote that stuff ourselves for the spec. In that case the
> original author is of course free to also contribute it to the ASF under
> ALv2.
>
> LieGrue,
> strub
>
>
>
> > Am 03.07.2016 um 23:01 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Le 3 juil. 2016 22:56, "John D. Ament" <johndam...@apache.org> a écrit :
> >>
> >> geronimo@ who?
> >
> > Dev list
> >
> >>
> >> I emailed the OWB list as the OWB team is maintaining the JAR, there's
> > just
> >> considerable overlap w/ the geronimo PMC that it becomes confusing.
> >>
> >
> > Well you can also see geronimo community is doing so since people
> overlap a
> > lot there but strictly speaking this jar is not always driven by owb.
> >
> >> What about my comments about the javadocs?
> >>
> >
> > It is usually best effort but im +1 to make it better. Only constraint we
> > have is to not copy official comments/spec AFAIK.
> >
> >> John
> >>
> >> On Sun, Jul 3, 2016 at 3:24 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Hi John,
> >>>
> >>> -> geronimo@ ;)
> >>>
> >>> Otherwise +1 for jenkins and to replace current 2.0 by an up to date
> >>> version
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>> <http://www.tomitribe.com> | JavaEE Factory
> >>> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>>
> >>> 2016-07-03 15:10 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >>>
> >>>> Hey guys
> >>>>
> >>>> I'm looking at the current state of the Geronimo CDI 2 spec jar.  I'm
> >>>> wondering, what version of CDI 2 is it based on currently?
> >>>>
> >>>> In addition, I'm planning to apply patches to it based on the changes
> > in
> >>>> CDI 2.  I notice that unlike most geronimo specs, its pretty heavy on
> >>>> javadocs.  I plan to restate them, similar to what i'm seeing in here.
> >>>>
> >>>> I'm wondering if we can enable a build in jenkins to build the JAR?
> >>>>
> >>>> John
> >>>>
> >>>
>
>

Re: CDI 2.0 Spec JAR

[John D. Ament]

geronimo@ who?

I emailed the OWB list as the OWB team is maintaining the JAR, there's just
considerable overlap w/ the geronimo PMC that it becomes confusing.

What about my comments about the javadocs?

John

On Sun, Jul 3, 2016 at 3:24 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi John,
>
> -> geronimo@ ;)
>
> Otherwise +1 for jenkins and to replace current 2.0 by an up to date
> version
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-03 15:10 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Hey guys
> >
> > I'm looking at the current state of the Geronimo CDI 2 spec jar.  I'm
> > wondering, what version of CDI 2 is it based on currently?
> >
> > In addition, I'm planning to apply patches to it based on the changes in
> > CDI 2.  I notice that unlike most geronimo specs, its pretty heavy on
> > javadocs.  I plan to restate them, similar to what i'm seeing in here.
> >
> > I'm wondering if we can enable a build in jenkins to build the JAR?
> >
> > John
> >
>

CDI 2.0 Spec JAR

[John D. Ament]

Hey guys

I'm looking at the current state of the Geronimo CDI 2 spec jar.  I'm
wondering, what version of CDI 2 is it based on currently?

In addition, I'm planning to apply patches to it based on the changes in
CDI 2.  I notice that unlike most geronimo specs, its pretty heavy on
javadocs.  I plan to restate them, similar to what i'm seeing in here.

I'm wondering if we can enable a build in jenkins to build the JAR?

John

[jira] [Created] (OWB-719) @Named qualifier is not adhering to CDI spec default naming conventions

[John D. Ament (JIRA)]

John D. Ament created OWB-719:
-

 Summary: @Named qualifier is not adhering to CDI spec default 
naming conventions
 Key: OWB-719
 URL: https://issues.apache.org/jira/browse/OWB-719
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.3
Reporter: John D. Ament


Using the following test case and producer methods, OWB cannot resolve this 
bean until the third producer method.  All three work correctly in Weld.  As 
noted from original poster:

See CDI Spec 1.0, section 3.3.8:

The default name for a producer method is the method name, unless the
method follows the JavaBeans property getter naming convention, in
which case the default name is the JavaBeans property name.

@RunWith(Arquillian.class)
public class FooTest {
@Deployment
public static Archive? createTestArchive() {
return 
ShrinkWrap.create(JavaArchive.class).addClass(FooMaker.class)
.addAsManifestResource(EmptyAsset.INSTANCE, 
beans.xml);
}

@Inject @Named(foo)
private String foo;

@Test
public void testFoo() {
Assert.assertEquals(bobo, foo);
}
}

I tried the following producers, only the last worked (OWB not using method 
name or JavaBeans naming conventions)

@Produces @Named
public String getFoo() {
return bobo;
}

@Produces @Named
public String foo() {
return bobo;
}

@Produces @Named(foo)
public String foo() {
return bobo;
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira