I think we have to first point out all available options. Option A.) is to treat the InvocationHandler as CDI bean and create all the proxies as @Dependent beans and inject them directly. So you would _not_ get a normalscoped CDI proxy (Contextual Reference) but our own proxy which is different for each injection point. And this own proxy resolves the InvocationHandler as CDI beans.
Option B.) The InvocationHandler is _no_ CDI bean at all. It's even vetoed as bean! We take the scope and the qualifiers, etc from the 'serviced' interface/abstract class and create a Bean<?> for each of it which gets those scopes and qualifiers. The registered Beans will create Contextual Instances which are _our_ servicehandler proxies. Those will be stored in the Contexts. During injection the CDI container will apply all NormalScoped mechanism like the CDI proxy over our internal servicehandler proxy. Both ways will provide similar results, but they each have a different impact on side effects, states and handling. I think B.) is what Gerhard implemented, right? What option was used in Seam? LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, December 26, 2012 9:59 PM > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > hi john, > > as mentioned before: > >> @ InvocationHandler as a separated bean (at runtime): >> currently i can't see a benefit for DELTASPIKE-60. > > regards, > gerhard > > > > 2012/12/26 John D. Ament <[email protected]> > >> Gerhard, >> >> Just so I'm clear, when I was referring to the current implementation, > it >> was the one shipped with Seam3/Solder: >> >> > https://github.com/seam/solder/tree/develop/impl/src/main/java/org/jboss/solder/serviceHandler >> >> It does look like we're doing something very similar by veto'ing > the >> handler classes. >> >> else if (InvocationHandler.class.isAssignableFrom(beanClass)) >> { >> validateInvocationHandler(beanClass, bindingAnnotationClass); >> >> this.partialBeanHandlers.put(bindingAnnotationClass, >> (Class<? extends InvocationHandler>) beanClass); >> pat.veto(); >> } >> >> I believe as a result, we have to do what you're doing in >> PartialBeanLifecycle.create (line 75) to manually create the instance. >> If we just let the scopes handle the scopes whether this is a new >> instance or an existing instance should resolve itself more naturally. >> >> >> >> On Wed, Dec 26, 2012 at 2:06 PM, John D. Ament <[email protected] >> >wrote: >> >> > Gerhard, >> > >> > I apologize, I hadn't realized you implemented this feature, > considering >> > it has been assigned to me. >> > >> > John >> > >> > >> > On Wed, Dec 26, 2012 at 1:56 PM, Gerhard Petracek < >> > [email protected]> wrote: >> > >> >> hi john, >> >> >> >> that can't be - the described example (/excerpt) is a copy of > a working >> >> example (tested with owb and weld). >> >> >> >> the only use-case (we have so far) which can't be implemented > with std. >> >> cdi >> >> mechanisms (due to abstract classes) is DELTASPIKE-60. >> >> >> >> @ InvocationHandler as a separated bean (at runtime): >> >> currently i can't see a benefit for DELTASPIKE-60. >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> 2012/12/26 John D. Ament <[email protected]> >> >> >> >> > but the >> >> > specific one annotated a certain way. The cleanest way > (conceptual >> >> > >> >> >> > >> > >> >
