Indeed. If we need any byte code engineering library then it must not be in core-impl but in a separate module. core-impl shall not have _any_ 3rd party runtime dependencies.
LieGrue, strub >________________________________ > From: Romain Manni-Bucau <[email protected]> >To: Mark Struberg <[email protected]>; [email protected] >Sent: Thursday, December 27, 2012 12:41 PM >Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > >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 >>>>> >> >> > >>>>> >> >> >>>>> >> > >>>>> >> > >>>>> >> >>>>> > >>>>> >>>> >>> >> > >
