[cdi-dev] Minutes from EG meeting 20/08/2012
struberg at yahoo.de
Thu Aug 23 06:50:12 EDT 2012
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>.
----- 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.
> 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
More information about the cdi-dev