You are right! And we need to take this C. route. But for other reasons than having a different state lifecycle in the servicehandler than in the service.
The reason is that the CDI spec doesn't define a portable way how to intercept contextual instances generated via a Bean<T>. This is only defined for Decorators and 'Managed Beans' (Bean<T> resulting from a scanned class). In practice there would also be an option to generate a Proxy class and add an AnnotatedType for it. I think this also works in all containers. The problem here being that this doesn't work in CDI-1.0 as there are yet no 'synthetic annotated types' plus we have the problem that we would need to know this info in BeforeBeanDiscovery (for #addAnnotatedType). So we would need to manually scan with some other tools than ProcessAnnoatedType. That would btw something to consider in our CDI spec. a Method ProcessAnnotatedType#addSyntheticAnnotatedType(..); Anyway. It doesn't work in CDI-1.0 thus we only have the way to pick up the InvocationHandlers via CDI itself. Which means they also have their own scope! Otherwise we would not be able to add an @Transactional to the servicehandler InvocationHandler. LieGrue, strub ----- Original Message ----- > From: John D. Ament <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Thursday, December 27, 2012 12:57 AM > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > i think there's a C here as well that can be considered (which is what > I've > been driving to): > > Allow the scope of the InvocationHandler to drive the scope of the > InvocationProxy (the interface/abstract class we just proxied), with an > override to a narrower scope (if so chosen by the app developer). This > approach closely mirrors the CDI approach of injecting a session scoped > object in to a request scoped object, or another session scoped object (so > it's relate-able). We don't veto the InvocationHandler and instead > allow > it to retain its original scope (in fact, we don't have to do anything with > the invocation handler until runtime and validation). We just have to make > sure we install the InvocationProxy with the appropriate scopes. > > > On Wed, Dec 26, 2012 at 5:15 PM, Mark Struberg <[email protected]> wrote: > >> 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 >> >> >> > >> >> >> >> >> > >> >> > >> >> >> > >> >
