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