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<Blah>) 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>
