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 <[email protected]> > To: "Lincoln Baxter, III" <[email protected]> > Cc: "seam-dev >> seam-dev@lists. jboss. org Development List" > <[email protected]> > 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 <[email protected]> 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 [email protected] > :-) >> >> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." > > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
