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:30:41 GMT
compile time would be an option!

It happens that Matt and I are currently working on commons-weaver [1].
It started as 'privilizer' (to generate doPrilived blocks fo @Privileged annotated methods)
but we moved it to a more generic pattern recently. 
It basically provides an ant task and a maven-plugin which trigger the WeaveProcessor. This
WeaveProcessor picks up all provided weaving plugins. In the privilizer plugin we just change
the bytecode of the existing classes.
We could easily create such a weaving plugin which would change the abstract class into a
full class and fill in the InvocationHandler calls.
The resulting class files do not have any runtime dependencies that way. Javassist or whatever
you choose to do the bytecode stuff is only used at compile time.


LieGrue,
strub



>________________________________
> From: John D. Ament <john.d.ament@gmail.com>
>To: deltaspike-dev@incubator.apache.org; Mark Struberg <struberg@yahoo.de> 
>Sent: Thursday, December 27, 2012 1:19 PM
>Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> 
>
>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 <struberg@yahoo.de> 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 <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