whoops, forgot to share the links ^^ https://svn.apache.org/repos/asf/commons/sandbox/privilizer/trunk/ http://commons.apache.org/sandbox/privilizer/
Please note that our docs are not yet updated to reflect the generic weaver. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Thursday, December 27, 2012 1:30 PM > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > 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 >>>>>>>> >> >> > >>>>>>>> >> >> >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> >
