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 > >>>>> >> >> > > >>>>> >> >> > >>>>> >> > > >>>>> >> > > >>>>> >> > >>>>> > > >>>>> > >>>> > >>> > >> > > > > >
