hi mark, i just compared it and solder uses b) as well (just not that explicit).
regards, gerhard 2012/12/26 Mark Struberg <[email protected]> > 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 > >> >> > > >> >> > >> > > >> > > >> > > >
