compile time would be an option! It happens that Matt and I are currently working on commons-weaver [1]. It started as 'privilizer' (to generate doPrilived blocks fo @Privileged annotated methods) but we moved it to a more generic pattern recently. It basically provides an ant task and a maven-plugin which trigger the WeaveProcessor. This WeaveProcessor picks up all provided weaving plugins. In the privilizer plugin we just change the bytecode of the existing classes. We could easily create such a weaving plugin which would change the abstract class into a full class and fill in the InvocationHandler calls. The resulting class files do not have any runtime dependencies that way. Javassist or whatever you choose to do the bytecode stuff is only used at compile time.
LieGrue, strub >________________________________ > From: John D. Ament <[email protected]> >To: [email protected]; Mark Struberg <[email protected]> >Sent: Thursday, December 27, 2012 1:19 PM >Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > >Agreed (separate module since it has a dependency on javassist) > > >I think abstract classes are a must. I can think of some DAO use cases where >the handler's approach may not match how they want the search to operate, plus >if they want to do a criteria query I can't think of a generic way to do that >(yet). > > >Can't we use a ProducerMethod to obscure the fact that we cannot simply >install a bean up front? Is there a timing issue w/ when we can add the >producer methods vs beans? What about a compile-time option where we generate >the class up front via a compiler plugin or maven plugin? > > >John > > > >On Thu, Dec 27, 2012 at 7:10 AM, Mark Struberg <[email protected]> wrote: > > >> >>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 >>>>>>> >> >> > >>>>>>> >> >> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > >
