[cdi-dev] Minutes from EG meeting 20/08/2012

[Mark Struberg]

That sounds like a workaround for a workaround for a workaround for a ...

Reminds me to an old saying "dirty remains, while quick is long forgotten"


I still don't get the original problem. We need to go back to the original distinction of our 'XML' or other config use cases

1.) addAnnotatedType() for a class which is NOT in a BDA

2.) addAnnotatedType() for a class which IS in a BDA and should get their annotations set to a fixed specific constellation 1:1 as it is defined in the XML. All existing annotations should get replaced.

3.) ProcessAnnotatedType for a class which IS in a BDA and should get their annotations modified (You also need to further distinct between add-only and replace-by-type e.g. addQualifiers() vs setQualifiers())

4.)  addAnnotatedType() for a class which IS in a BDA, but the XML should result in an _additional_ Bean and _not_ modify the existing AnnotatedType.

And once again: we do all this stuff just because we like to get a specific Bean<T> in the end. If we discuss our goals, then the target is not to get a specific AnnotatedType but to get the final Bean<T>.

LieGrue,
strub




----- Original Message -----
> From: Stuart Douglas <sdouglas at redhat.com>
> To: Pete Muir <pmuir at redhat.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, August 22, 2012 12:31 AM
> Subject: Re: [cdi-dev] Minutes from EG meeting 20/08/2012
> 
> 
> That would also be fine. 
> 
> Stuart
> 
> On 22/08/2012, at 8:06 AM, Pete Muir <pmuir at redhat.com> wrote:
> 
>>  Or just say that if you want to add >1 annotated type based on the same 
> class you must specify a unique id for it?
>> 
>>  On 21 Aug 2012, at 23:00, Stuart Douglas wrote:
>> 
>>>  I have actually been thinking about this. What if we say that any 
> additional added AnnotatedTypes are not passivation capable, but then add an 
> additional version of addAnnotatedType() where the extension explicitly 
> specifies the bean id to make it passivation capable? 
>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>