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 12:10:06 GMT


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 <rmannibucau@gmail.com>
>To: Mark Struberg <struberg@yahoo.de>; deltaspike-dev@incubator.apache.org 
>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" <struberg@yahoo.de> 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 <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