On 15 Aug 2012, at 15:30, Stuart Douglas wrote: > > On 15/08/2012, at 11:20 PM, Pete Muir <pm...@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 Deltaspike contains lots of extensions authors, requesting >> feedback. Please either send direct to me, or post to >> cdi-...@lists.jboss.org :-) >> >> ------------------------------------------------------------------------------------------------------------------------------------------------ >> >> 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. >> > > > I think there are some issues here. In order to get consistent behaviour the > XML extension relied upon PAT being fired for every class it defined, so > other extension could then modify the annotated type in a consistent manner.
IOW this would prevent XML defined class from then being modified by another extension. > > Later on Weld changed its behaviour so that PAT was not fired when annotated > types were added through the SPI, in order to work around this I made the XML > extension fire PAT for these type itself in order to provide backwards > compatibility, which is a horrible hack that is now causing problems for > Delta Spike. > > If we make this change to the specification I don't think that it will be > possible to implement a viable XML extension. The XML would work but couldn't have it's behaviour changed by other extensions. > > I am aware that this present challenges for serialisation and clustering, > however I worked around this in Weld when I was writing the XML extension by > creating a class that creates a deterministic bean id based on the > annotations on the class > (https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/AnnotatedTypes.java#L185), > I wrote this code before I was working for Red Hat an I am quite happy to > license it under Apache or any other license. Weld is Apache licensed anyway. I think it's fair to define this approach of creating a type id as "not easy". > > Stuart > > >> ------------------------------------------------------------------------------------------------------------------------------------------------ >> >> 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); >> >> >
