[seam-dev] CDI EG requires feedback

[Mark Struberg]

To make it even more clear what Pete just stated: People added multiple different AnnotatedTypes to the same class because they wanted to get multiple different 'Managed Bean' for the same class. If we clarify that only 1 AnnotatedType instance exists per class, then you would do the same by just providing multiple Bean<T> instances directly.

LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> Cc: "seam-dev >> seam-dev at lists. jboss. org Development List" <seam-dev at lists.jboss.org>
> Sent: Wednesday, August 15, 2012 7:07 PM
> Subject: Re: [seam-dev] CDI EG requires feedback
> 
>T his would still work, you are replacing an existing annotated type, not adding 
> a new one for the same type.
> 
> We're talking about having an AnnotatedType<Foo>, and adding another 
> one of AnnotatedType<Foo>.
> 
> On 15 Aug 2012, at 17:42, Lincoln Baxter, III wrote:
> 
>>  I believe that Forge creates new Annotated Types to replace the existing 
> one in the event-bus extension. This is done so that Qualifiers may be added to 
> parameters of event observers.
>> 
>>  You can see the code here. I'm not sure if this is related to your 
> discussion, but it seems close so I thought I would mention it: 
>> 
>> 
> https://github.com/forge/core/blob/master/event-bus-api/src/main/java/org/jboss/forge/bus/cdi/ObserverCaptureExtension.java
>> 
>>  This extension took a good deal of work to produce, and is used throughout 
> Forge. As long as we can capture events like we are doing here, it could be 
> re-implemented, but it would potentially be a lot of work.
>> 
>>  ~Lincoln
>> 
>>  On Wed, Aug 15, 2012 at 9:17 AM, Pete Muir <pmuir at redhat.com> wrote:
>>  All, the CDI EG requires feedback on an item in the spec which is not 
> clear, and has been implemented differently between implementations, and is not 
> TCK tested. As Seam-dev contains lots of extensions authors, requesting 
> feedback. Please either send direct to me, or post to cdi-dev at lists.jboss.org 
> :-)
>> 
>>  Stuart, your feedback on this would be good, as it relates to XML config.
>> 
>> 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>>  Multiple Annotated Types
>>  ====================
>> 
>>  https://issues.jboss.org/browse/CDI-58
>> 
>>  This concerns whether there can be greater than one annotated type per 
> class instance in the JVM. Gavin intended there should be, principally to 
> support an XML configuration dialect, which could introduce multiple versions of 
> a class, each with a different qualifier. However, this is not TCK tested, and 
> implementations vary in how they support this.
>> 
>>  We discussed that this makes an implementation considerably more complex 
> (as there is no easy way to uniquely identify an annotated type e.g. for 
> serialization), and also is pretty confusing for a user (as you now get multiple 
> ProcessAnnotatedType events for each class, making it hard to know which one you 
> want to change).
>> 
>>  We looked at alternative solutions, and concluded that if all use cases can 
> be satisfied by adding a new bean, rather than a new annotated type, we would 
> like to explicitly specify that there is only one annotated type per class 
> instance. In CDI 1.1 it is already much easier to add and manipulate beans from 
> annotated types, so we believe that the correct thing here is take this route.
>> 
>> 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>>  Does anyone create multiple AnnotatedTypes per class instance? If so, can 
> you please describe:
>> 
>>  a) why you need to do this
>>  b) whether you could reimplement by directly creating beans (given that CDI 
> 1.1 allows you to [1])
>>  c) how much effort it would be to reimplement/how much of your codebase 
> this would affect
>> 
>>  Thanks!
>> 
>>  Pete
>> 
>>  [1]
>> 
>>  BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
>>  InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
>>  Bean b = beanManager.createBean(ba, clazz, it);
>> 
>>  or
>> 
>>  BeanAttributes ba = 
> beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
>>  Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
>>  Bean b = beanManager.createBean(ba, clazz, p);
>> 
>>  The Bean can then be registered using
>> 
>>  afterBeanDiscovery.addBean(b);
>>  _______________________________________________
>>  seam-dev mailing list
>>  seam-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/seam-dev
>> 
>> 
>> 
>>  -- 
>>  Lincoln Baxter, III
>>  http://ocpsoft.org
>>  "Simpler is better."
> 
> 
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>