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 Fri, 28 Dec 2012 09:58:15 GMT
What about the weaving I pointed out? 

Any ideas, pros and cons?


LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Friday, December 28, 2012 10:08 AM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> 
> @ "...since it's currently the only approach which works with both
> implementations (owb and weld)...":
> 
> fyi: in case of weld interceptors for invocation-handlers just work with
> v1.1.9+.
> 
> regards,
> gerhard
> 
> 
> 
> 2012/12/27 Mark Struberg <struberg@yahoo.de>
> 
>>  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