@ "...since it's currently the only approach which works with both implementations (owb and weld)...":
fyi: in case of weld interceptors for invocation-handlers just work with v1.1.9+. regards, gerhard 2012/12/27 Mark Struberg <[email protected]> > as for the Qualifier discussion. We again have 2 different locations for > the qualifiers and both mean different things > > a.) place a qualifier on a 'partial bean': > > > consider public interface Car > > public abstract class @Driven @Minivan VwBus implements Car ... > > and > > public abstract class @Driven @Coupe Porsche implements Car > > where Minivan and Coupe being two Qualifiers and @Driven is our > @PartialBeanBinding. > > > > b.) is different in that it has 2 different PartialBeanBindings which you > like to distinct via qualifiers. A @Driven @Minivan @PartialBeanBinding and > a @Driven @Coupe @PartialBeanBinding. > > Now we face the problem that we have 2 things such a qualifier can refer > to: the service or the binding! There is no way to distinguish them > technically, so we need to pick one strategy. It would be easy to just add > another binding annotation and extend the existing InvocationHandler. So we > imo don't need qualifiers to distinguish between them. > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Gerhard Petracek <[email protected]> > > To: [email protected] > > Cc: John D. Ament <[email protected]> > > Sent: Thursday, December 27, 2012 8:54 PM > > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > > > i agree that we have an un-(/under-)specified area here. > > > > i've pushed the changes since it's currently the only approach which > > works > > with both implementations (owb and weld). > > (for now the handling of dependent scoped invocation-handlers isn't > > included.) > > > > @repackaging: > > it was just an example, however, we can discuss the details once we > agreed > > on an implementation. > > > > @john: > > you asked for supporting qualifiers in combination with > > @InvocationHandlerBinding. > > i'm not sure what you tried to get in. for me it sounded more like [1] > (and > > i don't agree with that). > > > > regards, > > gerhard > > > > [1] http://s.apache.org/5nM > > > > > > > > 2012/12/27 Mark Struberg <[email protected]> > > > >> > >> > it works already for the invocation-handler, but >only< with > > owb. > >> > >> Yes, this is because OWB applies the interceptor and decorators > _outside_ > >> of Producer<T>/InjectionTarget<T>. > >> Weld does this _inside_ thus it only works for Bean<?> which have a > >> Producer<T>/InjectionTarget<T>. > >> > >> Both ways are allowed by the spec, so we cannot rely on it. > >> > >> > >> Thus the only _portable_ way to implement interceptors on the > >> InvocationHandlers (which is imo a must) is to pick them up as CDI > beans > > -> > >> option C.) > >> > >> > >> > @no core-dependencies: > >> > agreed - nobody said that we will keep it that way. e.g. we can > > repackage > >> > the proxy lib (with the shade-plugin for maven). > >> > >> Nope, that gonna be 2MB++. For my personal taste this is just too fat > to > >> be shaded in! > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> ----- Original Message ----- > >> > From: Gerhard Petracek <[email protected]> > >> > To: [email protected] > >> > Cc: > >> > Sent: Thursday, December 27, 2012 2:24 PM > >> > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss > > ServiceHandler > >> > > >> > @abstract classes: > >> > i agree with john (in view of more complex queries). that's > > actually the > >> > only reason why we need DELTASPIKE-113 (for DELTASPIKE-60). > >> > > >> > @interceptors: > >> > it works already for the invocation-handler, but >only< with > > owb. > >> > since DELTASPIKE-60 is just for doing the actual queries, it's a > >> > restriction which affects esp. simple constellations. > >> > once you call such daos from a transactional bean (/service), you > only > >> have > >> > issues with fine grained interceptors for daos (e.g. > >> security-interceptors). > >> > -> it depends on your application, if you see the restriction at > > all. > >> > > >> > @no core-dependencies: > >> > agreed - nobody said that we will keep it that way. e.g. we can > > repackage > >> > the proxy lib (with the shade-plugin for maven). > >> > > >> > regards, > >> > gerhard > >> > > >> > > >> > > >> > 2012/12/27 Mark Struberg <[email protected]> > >> > > >> >> 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 > >> >> >>>>>>>> >> >> > > >> >> >>>>>>>> >> >> > >> >> >>>>>>>> >> > > >> >> >>>>>>>> >> > > >> >> >>>>>>>> >> > >> >> >>>>>>>> > > >> >> >>>>>>>> > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>>> > >> >> >>>> > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > >> > > >> > > >
