deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 27 Dec 2012 12:19:50 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message