On 16/08/2012, at 12:41 AM, Pete Muir <[email protected]> wrote: > > On 15 Aug 2012, at 15:30, Stuart Douglas wrote: > >> >> On 15/08/2012, at 11:20 PM, 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 Deltaspike contains lots of extensions authors, >>> requesting feedback. Please either send direct to me, or post to >>> [email protected] :-) >>> >>> ------------------------------------------------------------------------------------------------------------------------------------------------ >>> >>> 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.
Yes, which is very non-intutive considering the way the existing XML syntax. I know is is not a standard, but it has seen wide adoption, and people expect that applying an annotation via XML is the same as applying it to the class itself. > >> >> 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. Kind of, but it also becomes a lot more complex to implement, you definitely could not just take the old Seam XML extension and expect it to work. there is not a 1:1 relationship between beans and annotated types, because annotated types can have producer methods. I think that this is actually a feature, and a feature that Seam XML relied on. If this becomes spec I think that a lot of legacy apps will stop working. Sometimes breaking backwards compatibility is necessary, but in this case I don't really see any advantage too it. > >> >> 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". I would consider it a 'solved problem'. AFAIK the same code should work for any CDI impl that needs to generate a deterministic type id. Stuart > >> >> 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); >>> >>> >> >
