[cdi-dev] Getting injection point from Bean#create

arjan tijms arjan.tijms at gmail.com
Thu Jan 28 14:57:15 EST 2016


On Thu, Jan 28, 2016 at 4:43 PM, Martin Kouba <mkouba at redhat.com> wrote:

> By the way, Tomas tested the original way using
> BeanManager.getInjectableReference() and it works fine. For the purpose of
> this use case a custom IP with InjectionPoint as a requested type, @Default
> as a qualifier and "this" as a declaring bean should be enough (no need for
> InjectionPointGenerator).
>

Okay, so you mean this code:

InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
     resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
     creationalContext
);

To what does that has to be changed exactly?



>
> We're going to add a test in the Weld test suite.


Great! That test will be for this method?

Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
manager.resolve(manager.getBeans(InjectionPoint.class));
InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
InjectionPoint.class, manager.createCreationalContext(bean));



> I don't think we should add this into TCK as it's rather corner case not
> clearly defined in the spec.
>

Would that be something that's beneficial to add to the 2.0 spec?

Kind regards,
Arjan Tijms





>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-1823
>
> Dne 27.1.2016 v 15:20 Tomas Remes napsal(a):
>
>
>> Hi Arjan,
>>
>> Ok I am going to check this. Wrt TCK I am not sure it's suitable to some
>> spec assertion so I wouldn't add it to TCK but we can definitely include
>> this to Weld internal testsuite.
>>
>> Thank's
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms at gmail.com>
>> To: "Jozef Hartinger" <jharting at redhat.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Wednesday, January 27, 2016 2:42:00 PM
>> Subject: Re: [cdi-dev] Getting injection point from Bean#create
>>
>> Hi
>>
>> On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger < jharting at redhat.com >
>> wrote:
>>
>>
>> The simplest thing you can do is:
>>
>> Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
>> manager.resolve(manager.getBeans(InjectionPoint.class));
>> InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
>> InjectionPoint.class, manager.createCreationalContext(bean));
>>
>> I just tried this again, and unfortunately it now fails on Weld.
>>
>> I quickly tried a series of Weld versions and this is the result:
>>
>> Weld
>> 2.2.6 works
>> 2.2.8 works
>> 2.2.9 fails
>> 2.2.13 fails
>> 2.2.14 fails
>> 2.2.16 fails
>> 2.3.0 fails
>> 2.3.2 fails
>>
>> So apparently it broke between 2.2.8 and 2.2.9.
>>
>> Would it be possible to add a TCK test for this? This would be really
>> helpful as we'd like to use this for the JSF 2.3 RI.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11/19/2014 05:06 PM, arjan tijms wrote:
>>
>>
>>
>> Hi,
>>
>> In a producer method it's trivial to get access to an InjectionPoint
>> instance representing the point where the value produced by the
>> producer will be injected.
>>
>> When registering a Bean manually from an extension using
>> AfterBeanDiscovery#addBean, this is not immediately obvious.
>>
>> After some fumbling with the CDI APIs I came up with the following
>> code that seems to work on both Weld and OWB (didn't test CanDI yet).
>>
>> It uses a small "dummy" class, which is used to grab an InjectionPoint
>> off:
>>
>> In a Bean:
>>
>> public Object create(CreationalContext<Object> creationalContext) {
>>
>> InjectionPoint injectionPoint = (InjectionPoint)
>> beanManager.getInjectableReference(
>> resolve(beanManager,
>> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>> creationalContext
>> );
>>
>> With InjectionPointGenerator being the following class:
>>
>> public class InjectionPointGenerator {
>> @Inject
>> private InjectionPoint injectionPoint;
>> }
>>
>> And resolve being the following method:
>>
>> public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
>> beanClass) {
>> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>
>> for (Bean<?> bean : beans) {
>> if (bean.getBeanClass() == beanClass) {
>> return (Bean<T>)
>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>> }
>> }
>>
>> return (Bean<T>) beanManager.resolve(beans);
>> }
>>
>> As mentioned, while this seems to work, I wonder if it's the best
>> approach.
>>
>> Kind regards,
>> Arjan
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160128/4e09f1e9/attachment-0001.html 


More information about the cdi-dev mailing list