[cdi-dev] AnnotatedTypeConfigurator limitation

[Matej Novotny]

> This said, I understand it's rather late to open this topic and with such
> cold and negative reception I move it to 2.1.

Uh, sorry, seems like I am all too cold and negative this week. Didn't mean that, my apology.
All I meant to say is that we discussed this quite excessively before and came to resolve the way we did.
That being said, applying your 1) solution would perfectly fit into our current layout :-)

Matej

----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> To: "Matej Novotny" <manovotn at redhat.com>, "Martin Kouba" <mkouba at redhat.com>
> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, November 16, 2016 1:51:27 PM
> Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> 
> From the beginning I advocated to have AnnotatedType treated as special
> case since it can be used from outside a portable extension (that's the
> reason why ATC and not other configurators, Matej).
> 
> These are not corner cases since I encountered them on 3rd party framework
> integration.
> 
> This said, I understand it's rather late to open this topic and with such
> cold and negative reception I move it to 2.1.
> 
> Antoine
> 
> On Wed, Nov 16, 2016 at 12:59 PM Matej Novotny <manovotn at redhat.com> wrote:
> 
> > Here are my 0.02$
> >
> > As soon as you extract ATC outside and make it available at any time, a
> > question pops up - Why ATC only? Why not all configurators usable at all
> > times?
> > The above is ofc nonsense and had been discussed before. So, we cannot add
> > all, and therefore doing so for some will make usage inconsistent and
> > confusing.
> >
> > If you really feel like covering the cases you described[1] and making ATC
> > available there, I would go for 1). We don't yet know what will users do
> > with current API; let us not overextend it.
> >
> > > Well, I thought the EG already agreed that the purpose of the
> > > configurator API is not to cover all possible use cases, but the most
> > > common ones.
> >
> > Also, +10 on ^
> >
> > Regards
> > Matej
> >
> >
> > ----- Original Message -----
> > > From: "Martin Kouba" <mkouba at redhat.com>
> > > To: "Antoine Sabot-Durand" <antoine at sabot-durand.net>, "cdi-dev" <
> > cdi-dev at lists.jboss.org>
> > > Sent: Wednesday, November 16, 2016 12:34:03 PM
> > > Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> > >
> > > Well, I thought the EG already agreed that the purpose of the
> > > configurator API is not to cover all possible use cases, but the most
> > > common ones. And the list of use cases below seems more like a list of
> > > corner cases.
> > >
> > > Anyway, if the EG decides to support this, I think we could either go
> > > with 1) or 3) *.
> > >
> > > *
> > > BeanManager.getAnnotatedTypeBuilder() that returns a new builder
> > > wrapping a configurator instance.
> > >
> > > Martin
> > >
> > > Dne 16.11.2016 v 11:30 Antoine Sabot-Durand napsal(a):
> > > > Hi Guys,
> > > >
> > > > Following CDI-642 and 643 I started to explore place where
> > annotatedType
> > > > can be used and where we don't provide access to
> > > > AnnotatedTypeConfigurator [1], I really think we should solve this use
> > > > case to avoid advanced users frustration discovering a new feature they
> > > > can use everywhere (that was my case when realised that I could use it
> > > > in BBD for Qualifier or interceptorBinding addition).
> > > >
> > > > Possible solutions:
> > > > 1) Add a hook to each of these place to obtain an
> > AnnotatedTypeConfigurator
> > > > 2) Add BM.createAnnotatypeConfigurator(Class) and
> > > > BM.createAnnotatedType(ATC)
> > > > 3) Add a Builder class that would provide a configure method
> > > > 4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
> > > > using AnnotatedTypeConfigurator.
> > > >
> > > > Antoine
> > > >
> > > >  [1] Non exhaustive list :
> > > > - BeforeTypeDiscovery for addQualifier and addInterceptorBinding
> > > > - UnManaged class
> > > > - BeanManager createInjectionTartet and getInjectionTargetFactory or in
> > > > InjectionTarget
> > > > - BeanManager getProducerFactory where a configured AnnotatedField or
> > > > AnnotatedMethod could be useful
> > > >
> > > >
> > > > _______________________________________________
> > > > cdi-dev mailing list
> > > > cdi-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > > >
> > > > Note that for all code provided on this list, the provider licenses the
> > > > code under the Apache License, Version 2
> > > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > > provided on this list, the provider waives all patent and other
> > > > intellectual property rights inherent in such information.
> > > >
> > >
> > > --
> > > Martin Kouba
> > > Software Engineer
> > > Red Hat, Czech Republic
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > code
> > > under the Apache License, Version 2
> > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > intellectual
> > > property rights inherent in such information.
> > >
> >
>