Le 1 juin 2015 00:58, "Mark Struberg" <[email protected]> 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 < [email protected]>: > > > > 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 > > <[email protected]>: > > > >> 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 <[email protected]>: > >> > >>> 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> > >>> > > >
