deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: [cdi-dev] CDI EG requires feedback
Date Wed, 15 Aug 2012 15:30:32 GMT

On 15 Aug 2012, at 16:23, Stuart Douglas wrote:

> 
> On 16/08/2012, at 12:41 AM, Pete Muir <pmuir@redhat.com> wrote:
> 
>> 
>> On 15 Aug 2012, at 15:30, Stuart Douglas wrote:
>> 
>>> 
>>> On 15/08/2012, at 11:20 PM, Pete Muir <pmuir@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-dev@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.
> 
> 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.

Understood.

Another thing we can think about here is standardizing the XML, which would remove this extension
from the mix at least.

> there is not a 1:1 relationship between beans and annotated types, because annotated
types can have producer methods. 

We're talking about 1:1 between class instance and annotated types. You could still have multiple
beans per annotated type.

> 
> 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 don't believe it's actually specified this way today, it's very very ambiguous how this
should work.

> 
> 
>> 
>>> 
>>> 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.

If this is the case, we should probably standardise this approach to creating the id. Maybe
even expose an API for it.

> 
> 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);
>>>> 
>>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev


Mime
View raw message