deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 27 Dec 2012 11:20:25 GMT
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 <struberg@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>
> 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 <john.d.ament@gmail.com>
>>  To: deltaspike-dev@incubator.apache.org; Mark Struberg 
> <struberg@yahoo.de>
>>  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 <struberg@yahoo.de> 
> 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 <gerhard.petracek@gmail.com>
>>>   > To: deltaspike-dev@incubator.apache.org
>>>   > 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 <john.d.ament@gmail.com>
>>>   >
>>>   >>  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 
>>  <john.d.ament@gmail.com
>>>   >>  >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 <
>>>   >>  > gerhard.petracek@gmail.com> 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 
> <john.d.ament@gmail.com>
>>>   >>  >>
>>>   >>  >> > but the
>>>   >>  >> > specific one annotated a certain way.  The 
> cleanest 
>>  way
>>>   > (conceptual
>>>   >>  >> >
>>>   >>  >>
>>>   >>  >
>>>   >>  >
>>>   >>
>>>   >
>>> 
>> 
> 

Mime
View raw message