[jira] Closed: (OWB-464) InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values.
[ https://issues.apache.org/jira/browse/OWB-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-464. -- Fix Version/s: 1.0.0-GA (was: 1.0.0-alpha-2) Resolution: Fixed Cool patch, thanks Paul! committed in r1002951 > InjectionPointImpl using wrong class loader during serialize/deserialize, > dropping qualifiers, and omiting qualifier values. > > > Key: OWB-464 > URL: https://issues.apache.org/jira/browse/OWB-464 > Project: OpenWebBeans > Issue Type: Bug > Components: Injection and Lookup >Affects Versions: 1.0.0-alpha-2 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu > Fix For: 1.0.0-GA > > Attachments: InjectionPoint_fix.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > InjectionPointImpl was using the default class loader instead of the thread > class loader during serialize/deserialize which was resulting in class not > found exceptions. It was also dropping every other qualifier due to the way > readObject was double-reading the qualifiers while looking for the '~' > delimeter. And finally, the writeObject code was writing the type of the > qualifiers rather than writing the whole object, thus omiting qualifier > values (i.e. @Named(org.apache.webbeans.foo) resulted in @Named(value=)). > Attached patch resolves these issues when applied on top of OWB-462. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-464) InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values.
[ https://issues.apache.org/jira/browse/OWB-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul J. Reder updated OWB-464: -- Attachment: InjectionPoint_fix.patch Patch to InjectionPointImpl that resolves correct class loader use, avoids loss of qualifiers and qualifier vlaues. > InjectionPointImpl using wrong class loader during serialize/deserialize, > dropping qualifiers, and omiting qualifier values. > > > Key: OWB-464 > URL: https://issues.apache.org/jira/browse/OWB-464 > Project: OpenWebBeans > Issue Type: Bug > Components: Injection and Lookup >Affects Versions: 1.0.0-alpha-2 > Environment: All >Reporter: Paul J. Reder >Assignee: Gurkan Erdogdu > Fix For: 1.0.0-alpha-2 > > Attachments: InjectionPoint_fix.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > InjectionPointImpl was using the default class loader instead of the thread > class loader during serialize/deserialize which was resulting in class not > found exceptions. It was also dropping every other qualifier due to the way > readObject was double-reading the qualifiers while looking for the '~' > delimeter. And finally, the writeObject code was writing the type of the > qualifiers rather than writing the whole object, thus omiting qualifier > values (i.e. @Named(org.apache.webbeans.foo) resulted in @Named(value=)). > Attached patch resolves these issues when applied on top of OWB-462. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-464) InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values.
InjectionPointImpl using wrong class loader during serialize/deserialize, dropping qualifiers, and omiting qualifier values. Key: OWB-464 URL: https://issues.apache.org/jira/browse/OWB-464 Project: OpenWebBeans Issue Type: Bug Components: Injection and Lookup Affects Versions: 1.0.0-alpha-2 Environment: All Reporter: Paul J. Reder Assignee: Gurkan Erdogdu Fix For: 1.0.0-alpha-2 InjectionPointImpl was using the default class loader instead of the thread class loader during serialize/deserialize which was resulting in class not found exceptions. It was also dropping every other qualifier due to the way readObject was double-reading the qualifiers while looking for the '~' delimeter. And finally, the writeObject code was writing the type of the qualifiers rather than writing the whole object, thus omiting qualifier values (i.e. @Named(org.apache.webbeans.foo) resulted in @Named(value=)). Attached patch resolves these issues when applied on top of OWB-462. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ambiguous dependencies when using multiple qualifiers
I think you hit the nail on the head with your last paragraph.
Basically it only matters that the bean (or producer in this case)
matches all of the qualifiers on the injection point. From the
perspective of the specification it doesn't matter if the bean has
extra qualifiers beyond those on the injection point. Section 5.3 is
another key section here.
Sincerely,
Joe
On Wed, Sep 29, 2010 at 12:30 PM, Jakob Korherr wrote:
> Hi,
>
> I tested some scenarios when using multiple qualifiers for test-cases
> in MyFaces CODI and stumbled upon the following scenario, which is not
> totally clear to me.
>
> Image you have the following producer methods:
>
> �...@produces
> �...@qualifier2
> �...@applicationscoped
> public ProducerBean createWithQualifier2()
> {
> return new ProducerBean();
> }
>
> �...@produces
> �...@qualifier1
> �...@qualifier2
> �...@applicationscoped
> public ProducerBean createWithQualifier1And2()
> {
> return new ProducerBean();
> }
>
>
> and you want to inject the instances produced by these producers. Now
> you can use @Inject @Qualifier1 or @Inject @Qualifier1 @Qualifier2,
> but when using @Inject @Qualifier2 you will get an exception, because
> the injection point is ambiguous (both producers provide @Qualifier2).
>
> However I was wondering if this is really unresolvable ambiguous,
> because if you think about it, it would make sence to take the
> producer createWithQualifier2() in this scenario (because the other
> one provides additional qualifiers).
>
> I also took a look in the CDI spec about this, but could only find the
> following from section 2.3.4: "A bean may only be injected to an
> injection point if it has all the qualifiers of the injection point."
> Of course this applies to both producers and thus, yes, it's kinda
> ambiguous.
>
> WDYT?
>
> Regards,
> Jakob
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: ambiguous dependencies when using multiple qualifiers
> I also took a look in the CDI spec about this, but could only find the > following from section 2.3.4: "A bean may only be injected to an > injection point if it has all the qualifiers of the injection point." > Of course this applies to both producers and thus, yes, it's kinda > ambiguous. "When an ambiguous dependency exists, the container attempts to resolve the ambiguity. The container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable." The spec says both producers satisfy the injection point, and does not allow it to discard the one with additional qualifiers. -- Eric Covener cove...@gmail.com
ambiguous dependencies when using multiple qualifiers
Hi,
I tested some scenarios when using multiple qualifiers for test-cases
in MyFaces CODI and stumbled upon the following scenario, which is not
totally clear to me.
Image you have the following producer methods:
@Produces
@Qualifier2
@ApplicationScoped
public ProducerBean createWithQualifier2()
{
return new ProducerBean();
}
@Produces
@Qualifier1
@Qualifier2
@ApplicationScoped
public ProducerBean createWithQualifier1And2()
{
return new ProducerBean();
}
and you want to inject the instances produced by these producers. Now
you can use @Inject @Qualifier1 or @Inject @Qualifier1 @Qualifier2,
but when using @Inject @Qualifier2 you will get an exception, because
the injection point is ambiguous (both producers provide @Qualifier2).
However I was wondering if this is really unresolvable ambiguous,
because if you think about it, it would make sence to take the
producer createWithQualifier2() in this scenario (because the other
one provides additional qualifiers).
I also took a look in the CDI spec about this, but could only find the
following from section 2.3.4: "A bean may only be injected to an
injection point if it has all the qualifiers of the injection point."
Of course this applies to both producers and thus, yes, it's kinda
ambiguous.
WDYT?
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [jira] Updated: (OWB-462) Refactor AnnotationUtil.hasAnnotationMember()
You're welcome - I'm glad to contribute! Regards, Jakob 2010/9/29 Rohit Kelapure : > This is an excellent patch. Thanks Jakob! > > We ran into a similar issue discovered by Paul Reder where in > > org.apache.webbeans.inject.impl.InjectionPointImpl.readObject(ObjectInputStream) > > the owner bean filtering > this.ownerBean = BeanManagerImpl.getManager().getBeans(beanClass, > anns.toArray(new Annotation[0])).iterator().next(); > > did NOT work.because checkEquality does NOT correctly compare the > owner bean deserialized annotations with the resolvedComponent > qualifiers. > > how this patch affects InjectionPointImpl deserialization ... > method hierarchy --> > org.apache.webbeans.util.AnnotationUtil.checkEquality(String, String, > List) > org.apache.webbeans.util.AnnotationUtil.hasAnnotationMember(Class extends Annotation>, Annotation, Annotation) > > org.apache.webbeans.container.InjectionResolver.findByQualifier(Set>, > Annotation...) > > org.apache.webbeans.container.InjectionResolver.implResolveByType(Type, > Annotation...) > org.apache.webbeans.container.BeanManagerImpl.getBeans(Type, > Annotation...) > > org.apache.webbeans.inject.impl.InjectionPointImpl.readObject(ObjectInputStream) > > > --Thanks, > Rohit Kelapure > > On Tue, Sep 28, 2010 at 5:24 PM, Jakob Korherr (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/OWB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Jakob Korherr updated OWB-462: >> -- >> >> Attachment: OWB-462.patch >> >> The patch contains the refactored code and some test cases. >> >>> Refactor AnnotationUtil.hasAnnotationMember() >>> - >>> >>> Key: OWB-462 >>> URL: https://issues.apache.org/jira/browse/OWB-462 >>> Project: OpenWebBeans >>> Issue Type: Task >>> Components: Core >>> Affects Versions: 1.0.0-alpha-2 >>> Reporter: Jakob Korherr >>> Assignee: Gurkan Erdogdu >>> Attachments: OWB-462.patch >>> >>> >>> We needed a method to compare qualifiers for MyFaces CODI and stumbled upon >>> AnnotationUtil.hasAnnotationMember(). >>> However this method is really messy, because it uses the String >>> representation of an annotation to compare it and thus fails in various >>> cases (e.g. when using annotation instances which implement toString() >>> differently or by using array values in the qualifier). Furthermore it does >>> not detect @Nonbinding fields correctly, if there is more than one >>> annotation on the annotation-method. >>> Also it's kinda weird that the method takes the Annotation-Class as an >>> extra parameter, but it could just get it from one of the Annotation >>> instances. I checked all usages and found out that this argument can be >>> dropped. In addition I think it's better to rename the method to >>> isQualifierEqual() - the usage is just a lot clearer. >>> I implemented a custom solution for MyFaces CODI and I think it should also >>> be applied here. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [jira] Updated: (OWB-462) Refactor AnnotationUtil.hasAnnotationMember()
This is an excellent patch. Thanks Jakob! We ran into a similar issue discovered by Paul Reder where in org.apache.webbeans.inject.impl.InjectionPointImpl.readObject(ObjectInputStream) the owner bean filtering this.ownerBean = BeanManagerImpl.getManager().getBeans(beanClass, anns.toArray(new Annotation[0])).iterator().next(); did NOT work.because checkEquality does NOT correctly compare the owner bean deserialized annotations with the resolvedComponent qualifiers. how this patch affects InjectionPointImpl deserialization ... method hierarchy --> org.apache.webbeans.util.AnnotationUtil.checkEquality(String, String, List) org.apache.webbeans.util.AnnotationUtil.hasAnnotationMember(Class, Annotation, Annotation) org.apache.webbeans.container.InjectionResolver.findByQualifier(Set>, Annotation...) org.apache.webbeans.container.InjectionResolver.implResolveByType(Type, Annotation...) org.apache.webbeans.container.BeanManagerImpl.getBeans(Type, Annotation...) org.apache.webbeans.inject.impl.InjectionPointImpl.readObject(ObjectInputStream) --Thanks, Rohit Kelapure On Tue, Sep 28, 2010 at 5:24 PM, Jakob Korherr (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/OWB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Jakob Korherr updated OWB-462: > -- > > Attachment: OWB-462.patch > > The patch contains the refactored code and some test cases. > >> Refactor AnnotationUtil.hasAnnotationMember() >> - >> >> Key: OWB-462 >> URL: https://issues.apache.org/jira/browse/OWB-462 >> Project: OpenWebBeans >> Issue Type: Task >> Components: Core >> Affects Versions: 1.0.0-alpha-2 >> Reporter: Jakob Korherr >> Assignee: Gurkan Erdogdu >> Attachments: OWB-462.patch >> >> >> We needed a method to compare qualifiers for MyFaces CODI and stumbled upon >> AnnotationUtil.hasAnnotationMember(). >> However this method is really messy, because it uses the String >> representation of an annotation to compare it and thus fails in various >> cases (e.g. when using annotation instances which implement toString() >> differently or by using array values in the qualifier). Furthermore it does >> not detect @Nonbinding fields correctly, if there is more than one >> annotation on the annotation-method. >> Also it's kinda weird that the method takes the Annotation-Class as an extra >> parameter, but it could just get it from one of the Annotation instances. I >> checked all usages and found out that this argument can be dropped. In >> addition I think it's better to rename the method to isQualifierEqual() - >> the usage is just a lot clearer. >> I implemented a custom solution for MyFaces CODI and I think it should also >> be applied here. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
