You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openwebbeans.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2015/06/01 03:42:03 UTC

BeanAttributesImpl and types

Hi guys,

org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<? extends
java.lang.annotation.Annotation>, java.lang.String, boolean,
java.util.Set<java.lang.Class<? extends java.lang.annotation.Annotation>>,
boolean) copies types from bean attributes. It prevents any further changes
and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
portable (if set is filled before we copy it it works otherwise it is
broken)

do you think we should just take the input value without any modification?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

Re: BeanAttributesImpl and types

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Ok

Originally come with copy one (which is fine)

So do we keep it this way finally? Sounds like yes

Le 1 juin 2015 01:58, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> what is the 2nd issue?
>
> The one I mean is that the scanned classes are processed one after the
other (as specified). But the sample code relies on ProcessInjectionPoint
of ALL classes gets scanned before the first ProcessBeanAttributes get
fired.
>
> LieGrue,
> strub
>
>
> > Am 01.06.2015 um 09:58 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>:
> >
> > @Mark: for which of 2 issue?
> >
> > Agree spec is not 100% clean
> > Le 1 juin 2015 00:38, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> >> Can you plz create a JIRA issue?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 01.06.2015 um 03:51 schrieb Romain Manni-Bucau <
rmannibucau@gmail.com
> >>> :
> >>>
> >>> PS: alternative is to fix the lifecycle between ProcessBeanAttributes
and
> >>> ProcessInjectionPoint
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>> <http://www.tomitribe.com>
> >>>
> >>> 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >>>
> >>>> Hi guys,
> >>>>
> >>>>
> >>
org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
> >>>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
> >> extends
> >>>> java.lang.annotation.Annotation>, java.lang.String, boolean,
> >>>> java.util.Set<java.lang.Class<? extends
> >> java.lang.annotation.Annotation>>,
> >>>> boolean) copies types from bean attributes. It prevents any further
> >> changes
> >>>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes
not
> >>>> portable (if set is filled before we copy it it works otherwise it is
> >>>> broken)
> >>>>
> >>>> do you think we should just take the input value without any
> >> modification?
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>> <http://rmannibucau.wordpress.com> | Github
> >>>> <https://github.com/rmannibucau> | LinkedIn
> >>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>>> <http://www.tomitribe.com>
> >>>>
> >>
> >>
>

Re: BeanAttributesImpl and types

Posted by Mark Struberg <st...@yahoo.de>.

what is the 2nd issue?

The one I mean is that the scanned classes are processed one after the other (as specified). But the sample code relies on ProcessInjectionPoint of ALL classes gets scanned before the first ProcessBeanAttributes get fired. 

LieGrue,
strub


> Am 01.06.2015 um 09:58 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> @Mark: for which of 2 issue?
> 
> Agree spec is not 100% clean
> Le 1 juin 2015 00:38, "Mark Struberg" <st...@yahoo.de> a écrit :
> 
>> Can you plz create a JIRA issue?
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 01.06.2015 um 03:51 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>>> :
>>> 
>>> PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
>>> ProcessInjectionPoint
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>> 
>>> 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>>> 
>>>> Hi guys,
>>>> 
>>>> 
>> org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
>>>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
>> extends
>>>> java.lang.annotation.Annotation>, java.lang.String, boolean,
>>>> java.util.Set<java.lang.Class<? extends
>> java.lang.annotation.Annotation>>,
>>>> boolean) copies types from bean attributes. It prevents any further
>> changes
>>>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
>>>> portable (if set is filled before we copy it it works otherwise it is
>>>> broken)
>>>> 
>>>> do you think we should just take the input value without any
>> modification?
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>> <http://www.tomitribe.com>
>>>> 
>> 
>>

Re: BeanAttributesImpl and types

Posted by Romain Manni-Bucau <rm...@gmail.com>.

@Mark: for which of 2 issue?

Agree spec is not 100% clean
 Le 1 juin 2015 00:38, "Mark Struberg" <st...@yahoo.de> a écrit :

> Can you plz create a JIRA issue?
>
> LieGrue,
> strub
>
>
> > Am 01.06.2015 um 03:51 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
> > ProcessInjectionPoint
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >
> >> Hi guys,
> >>
> >>
> org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
> >> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
> extends
> >> java.lang.annotation.Annotation>, java.lang.String, boolean,
> >> java.util.Set<java.lang.Class<? extends
> java.lang.annotation.Annotation>>,
> >> boolean) copies types from bean attributes. It prevents any further
> changes
> >> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
> >> portable (if set is filled before we copy it it works otherwise it is
> >> broken)
> >>
> >> do you think we should just take the input value without any
> modification?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com>
> >>
>
>

Re: BeanAttributesImpl and types

Posted by Mark Struberg <st...@yahoo.de>.

Can you plz create a JIRA issue?

LieGrue,
strub


> Am 01.06.2015 um 03:51 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
> ProcessInjectionPoint
> 
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
> 
> 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> 
>> Hi guys,
>> 
>> org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<? extends
>> java.lang.annotation.Annotation>, java.lang.String, boolean,
>> java.util.Set<java.lang.Class<? extends java.lang.annotation.Annotation>>,
>> boolean) copies types from bean attributes. It prevents any further changes
>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
>> portable (if set is filled before we copy it it works otherwise it is
>> broken)
>> 
>> do you think we should just take the input value without any modification?
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>

Re: BeanAttributesImpl and types

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Le 1 juin 2015 00:58, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> No, it’s even explicitly in the spec that it is NOT the case ;)
>
> Read 12.4.3. Bean discovery
> „For every type in the set of discovered types (as defined in Section
12.4.1, “Type discovery”), the container must:
> • if the class is a managed bean, session bean, or other Java EE
component class supporting injection, fire an event of type
ProcessInjectionPoint for each injection point in the class, as defined in
Section 11.5.7, “ProcessInjectionPoint event”, and THEN
> • if the class is a managed bean, session bean, or other Java EE
component class supporting injection, fire an event of type
ProcessInjectionTarget, as defined in Section 11.5.8,
“ProcessInjectionTarget event”, and then
> • determine which alternatives, interceptors and decorators are enabled,
according to the rules defined in Section 5.1.2, “Enabled and disabled
beans”, Section 9.4, “Interceptor enablement and ordering” and Section 8.2,
“Decorator enablement and ordering”, and THEN
> • if the class is an enabled bean, interceptor or decorator, fire an
event of type ProcessBeanAttributes, as defined in Section 11.5.9,
“ProcessBeanAttributes event”, and THEN
> …
>
> „So the CDI spec CLEARLY specifies that the whole loop is ‚for every type
in the set of discovered types, THEN THEN THEN“
>

That is your interpretation. The bucket one still matches it.

> OWB impls it exactly as it is specified.
>
> So this usecase is rather illegal.
>
> LieGrue,
> strub
>
> > Am 01.06.2015 um 09:18 schrieb Arne Limburg <
arne.limburg@openknowledge.de>:
> >
> > Hmm, I think we discussed this in the past.
> > The problem is, that the spec does not clearly state whether all
> > ProcessInjectionPoint-Events have to be fired before the first
> > ProcessBeanAttributes-Event. Weld does so, we donąt (we fire them bean
by
> > bean).
> > I donąt think, our way is wrong from the spec point of view. If it is,
we
> > should fix it. Otherwise I tend to say, that the extension is not
portable.
> >
> > Cheers,
> > Arne
> >
> >
> > Am 01.06.15 03:51 schrieb "Romain Manni-Bucau" unter
> > <rm...@gmail.com>:
> >
> >> PS: alternative is to fix the lifecycle between ProcessBeanAttributes
and
> >> ProcessInjectionPoint
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com>
> >>
> >> 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >>
> >>> Hi guys,
> >>>
> >>>
> >>>
org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.
> >>> util.Set<java.lang.reflect.Type>,
> >>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
> >>> extends
> >>> java.lang.annotation.Annotation>, java.lang.String, boolean,
> >>> java.util.Set<java.lang.Class<? extends
> >>> java.lang.annotation.Annotation>>,
> >>> boolean) copies types from bean attributes. It prevents any further
> >>> changes
> >>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
> >>> portable (if set is filled before we copy it it works otherwise it is
> >>> broken)
> >>>
> >>> do you think we should just take the input value without any
> >>> modification?
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <http://rmannibucau.wordpress.com> | Github
> >>> <https://github.com/rmannibucau> | LinkedIn
> >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>> <http://www.tomitribe.com>
> >>>
> >
>

Re: BeanAttributesImpl and types

Posted by Mark Struberg <st...@yahoo.de>.

No, it’s even explicitly in the spec that it is NOT the case ;)

Read 12.4.3. Bean discovery
„For every type in the set of discovered types (as defined in Section 12.4.1, “Type discovery”), the container must:
• if the class is a managed bean, session bean, or other Java EE component class supporting injection, fire an event of type ProcessInjectionPoint for each injection point in the class, as defined in Section 11.5.7, “ProcessInjectionPoint event”, and THEN
• if the class is a managed bean, session bean, or other Java EE component class supporting injection, fire an event of type ProcessInjectionTarget, as defined in Section 11.5.8, “ProcessInjectionTarget event”, and then
• determine which alternatives, interceptors and decorators are enabled, according to the rules defined in Section 5.1.2, “Enabled and disabled beans”, Section 9.4, “Interceptor enablement and ordering” and Section 8.2, “Decorator enablement and ordering”, and THEN
• if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in Section 11.5.9, “ProcessBeanAttributes event”, and THEN
…

„So the CDI spec CLEARLY specifies that the whole loop is ‚for every type in the set of discovered types, THEN THEN THEN“

OWB impls it exactly as it is specified.

So this usecase is rather illegal.

LieGrue,
strub

> Am 01.06.2015 um 09:18 schrieb Arne Limburg <ar...@openknowledge.de>:
> 
> Hmm, I think we discussed this in the past.
> The problem is, that the spec does not clearly state whether all
> ProcessInjectionPoint-Events have to be fired before the first
> ProcessBeanAttributes-Event. Weld does so, we donąt (we fire them bean by
> bean).
> I donąt think, our way is wrong from the spec point of view. If it is, we
> should fix it. Otherwise I tend to say, that the extension is not portable.
> 
> Cheers,
> Arne
> 
> 
> Am 01.06.15 03:51 schrieb "Romain Manni-Bucau" unter
> <rm...@gmail.com>:
> 
>> PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
>> ProcessInjectionPoint
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>> 
>> 2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>> 
>>> Hi guys,
>>> 
>>> 
>>> org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.
>>> util.Set<java.lang.reflect.Type>,
>>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
>>> extends
>>> java.lang.annotation.Annotation>, java.lang.String, boolean,
>>> java.util.Set<java.lang.Class<? extends
>>> java.lang.annotation.Annotation>>,
>>> boolean) copies types from bean attributes. It prevents any further
>>> changes
>>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
>>> portable (if set is filled before we copy it it works otherwise it is
>>> broken)
>>> 
>>> do you think we should just take the input value without any
>>> modification?
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>> 
>

Re: BeanAttributesImpl and types

Posted by Arne Limburg <ar...@openknowledge.de>.

Hmm, I think we discussed this in the past.
The problem is, that the spec does not clearly state whether all
ProcessInjectionPoint-Events have to be fired before the first
ProcessBeanAttributes-Event. Weld does so, we don¹t (we fire them bean by
bean).
I don¹t think, our way is wrong from the spec point of view. If it is, we
should fix it. Otherwise I tend to say, that the extension is not portable.

Cheers,
Arne


Am 01.06.15 03:51 schrieb "Romain Manni-Bucau" unter
<rm...@gmail.com>:

>PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
>ProcessInjectionPoint
>
>
>Romain Manni-Bucau
>@rmannibucau <https://twitter.com/rmannibucau> |  Blog
><http://rmannibucau.wordpress.com> | Github
><https://github.com/rmannibucau> |
>LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
><http://www.tomitribe.com>
>
>2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> Hi guys,
>>
>> 
>>org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.
>>util.Set<java.lang.reflect.Type>,
>> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<?
>>extends
>> java.lang.annotation.Annotation>, java.lang.String, boolean,
>> java.util.Set<java.lang.Class<? extends
>>java.lang.annotation.Annotation>>,
>> boolean) copies types from bean attributes. It prevents any further
>>changes
>> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
>> portable (if set is filled before we copy it it works otherwise it is
>> broken)
>>
>> do you think we should just take the input value without any
>>modification?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>

Re: BeanAttributesImpl and types

Posted by Romain Manni-Bucau <rm...@gmail.com>.

PS: alternative is to fix the lifecycle between ProcessBeanAttributes and
ProcessInjectionPoint


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-06-01 3:42 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:

> Hi guys,
>
> org.apache.webbeans.component.BeanAttributesImpl#BeanAttributesImpl(java.util.Set<java.lang.reflect.Type>,
> java.util.Set<java.lang.annotation.Annotation>, java.lang.Class<? extends
> java.lang.annotation.Annotation>, java.lang.String, boolean,
> java.util.Set<java.lang.Class<? extends java.lang.annotation.Annotation>>,
> boolean) copies types from bean attributes. It prevents any further changes
> and https://gist.github.com/antoinesd/3097661ca99fa61900fb becomes not
> portable (if set is filled before we copy it it works otherwise it is
> broken)
>
> do you think we should just take the input value without any modification?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>