As pointed out by Gerhard on IRC we have 2 different areas where we need interception
1.) on the InvocationHandler and 2.) on the abstract class. In hindsight of DELTASPIKE-60 I'm thinking about @Transactional and @Securec, etc. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Thursday, December 27, 2012 11:24 AM > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > 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 >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> >>> > >>> >> >
