[seam-dev] CDI EG requires feedback

[Lincoln Baxter, III]

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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20120815/c37561a8/attachment.html