We proxy abstract classes? Is that mandatory? I would like to be able to skip javassist as forced dependency. Le 27 déc. 2012 12:20, "Mark Struberg" <[email protected]> a écrit :
> 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 > >>> >> >> > > >>> >> >> > >>> >> > > >>> >> > > >>> >> > >>> > > >>> > >> > > >
