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 20:32:55 GMT
as for the Qualifier discussion. We again have 2 different locations for the qualifiers and
both mean different things

a.) place a qualifier on a 'partial bean': 


consider public interface Car

public abstract class @Driven @Minivan VwBus implements Car ...

and 

public abstract class @Driven @Coupe Porsche implements Car

where Minivan and Coupe being two Qualifiers and @Driven is our @PartialBeanBinding.



b.) is different in that it has 2 different PartialBeanBindings which you like to distinct
via qualifiers. A @Driven @Minivan @PartialBeanBinding and a @Driven @Coupe @PartialBeanBinding.

Now we face the problem that we have 2 things such a qualifier can refer to: the service or
the binding! There is no way to distinguish them technically, so we need to pick one strategy.
It would be easy to just add another binding annotation and extend the existing InvocationHandler.
So we imo don't need qualifiers to distinguish between them. 

LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: John D. Ament <john.d.ament@gmail.com>
> Sent: Thursday, December 27, 2012 8:54 PM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> 
> i agree that we have an un-(/under-)specified area here.
> 
> i've pushed the changes since it's currently the only approach which 
> works
> with both implementations (owb and weld).
> (for now the handling of dependent scoped invocation-handlers isn't
> included.)
> 
> @repackaging:
> it was just an example, however, we can discuss the details once we agreed
> on an implementation.
> 
> @john:
> you asked for supporting qualifiers in combination with
> @InvocationHandlerBinding.
> i'm not sure what you tried to get in. for me it sounded more like [1] (and
> i don't agree with that).
> 
> regards,
> gerhard
> 
> [1] http://s.apache.org/5nM
> 
> 
> 
> 2012/12/27 Mark Struberg <struberg@yahoo.de>
> 
>> 
>>  > it works already for the invocation-handler, but >only< with 
> owb.
>> 
>>  Yes, this is because OWB applies the interceptor and decorators _outside_
>>  of Producer<T>/InjectionTarget<T>.
>>  Weld does this _inside_ thus it only works for Bean<?> which have a
>>  Producer<T>/InjectionTarget<T>.
>> 
>>  Both ways are allowed by the spec, so we cannot rely on it.
>> 
>> 
>>  Thus the only _portable_ way to implement interceptors on the
>>  InvocationHandlers (which is imo a must) is to pick them up as CDI beans 
> ->
>>  option C.)
>> 
>> 
>>  > @no core-dependencies:
>>  > agreed - nobody said that we will keep it that way. e.g. we can 
> repackage
>>  > the proxy lib (with the shade-plugin for maven).
>> 
>>  Nope, that gonna be 2MB++. For my personal taste this is just too fat to
>>  be shaded in!
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>>  ----- Original Message -----
>>  > From: Gerhard Petracek <gerhard.petracek@gmail.com>
>>  > To: deltaspike-dev@incubator.apache.org
>>  > Cc:
>>  > Sent: Thursday, December 27, 2012 2:24 PM
>>  > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss 
> ServiceHandler
>>  >
>>  > @abstract classes:
>>  > i agree with john (in view of more complex queries). that's 
> actually the
>>  > only reason why we need DELTASPIKE-113 (for DELTASPIKE-60).
>>  >
>>  > @interceptors:
>>  > it works already for the invocation-handler, but >only< with 
> owb.
>>  > since DELTASPIKE-60 is just for doing the actual queries, it's a
>>  > restriction which affects esp. simple constellations.
>>  > once you call such daos from a transactional bean (/service), you only
>>  have
>>  > issues with fine grained interceptors for daos (e.g.
>>  security-interceptors).
>>  > -> it depends on your application, if you see the restriction at 
> all.
>>  >
>>  > @no core-dependencies:
>>  > agreed - nobody said that we will keep it that way. e.g. we can 
> repackage
>>  > the proxy lib (with the shade-plugin for maven).
>>  >
>>  > regards,
>>  > gerhard
>>  >
>>  >
>>  >
>>  > 2012/12/27 Mark Struberg <struberg@yahoo.de>
>>  >
>>  >>  whoops, forgot to share the links ^^
>>  >>
>>  >>  
> https://svn.apache.org/repos/asf/commons/sandbox/privilizer/trunk/
>>  >>  http://commons.apache.org/sandbox/privilizer/
>>  >>
>>  >>  Please note that our docs are not yet updated to reflect the 
> generic
>>  >>  weaver.
>>  >>
>>  >>  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 1:30 PM
>>  >>  > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>  > ServiceHandler
>>  >>  >
>>  >>  > 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