You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2012/03/04 17:03:55 UTC
[DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Hi All
I wanted to bring up the subject of ServiceHandler. I added 113 as a child
of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
know if you think it's not appropriate as a child). ServiceHandler is a
feature in Solder that allows you to define an interceptor that manages
generic calls against an injected interface. The API is as follows:
- @ServiceHandlerType(Class<?> clazz) - placed on an annotation that would
be placed on the interface. Indicates what interceptor would be invoked
for calls against this interface.
It's then up to the application developer/framework author to define
annotations that go on methods, as well as the interceptor itself that will
be invoked. The feature for ServiceHandler would be to provide the API of
the type and then the infrastructure required to make the interceptor be
called. Existing documentation of the feature:
http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
Regards,
john
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
What about the weaving I pointed out?
Any ideas, pros and cons?
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@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 <st...@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 <ge...@gmail.com>
>> > To: deltaspike-dev@incubator.apache.org
>> > Cc: John D. Ament <jo...@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 <st...@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 <ge...@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 <st...@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 <st...@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
> <jo...@gmail.com>
>> >> >> >> To: deltaspike-dev@incubator.apache.org; Mark
> Struberg
>> >> >> > <st...@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
>> >> > <st...@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
>> > <rm...@gmail.com>
>> >> >> >>>> To: Mark Struberg
> <st...@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"
>> >> >> > <st...@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
>> > <st...@yahoo.de>
>> >> >> >>>>>> To:
>> >> > "deltaspike-dev@incubator.apache.org"
>> >> >> > <de...@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
>> >> > <jo...@gmail.com>
>> >> >> >>>>>>> To:
>> > deltaspike-dev@incubator.apache.org;
>> >> > Mark Struberg
>> >> >> >>>>>> <st...@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
>> >> >> > <st...@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
>> >> >> > <ge...@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
>> >> >> > <jo...@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
>> >> >> >>>>>>
> <jo...@gmail.com>
>> >> >> >>>>>>>> >> >>
>> >> >> >>>>>>>> >> >>
>> but
>> > the
>> >> >> >>>>>>>> >> >>
>>
>> > specific one
>> >> > annotated a
>> >> >> > certain way. The
>> >> >> >>>>>> cleanest
>> >> >> >>>>>>> way
>> >> >> >>>>>>>> > (conceptual
>> >> >> >>>>>>>> >> >>
>>
>> >> >> >>>>>>>> >> >>
>> >> >> >>>>>>>> >> >
>> >> >> >>>>>>>> >> >
>> >> >> >>>>>>>> >>
>> >> >> >>>>>>>> >
>> >> >> >>>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
@ "...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 <st...@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 <ge...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc: John D. Ament <jo...@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 <st...@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 <ge...@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 <st...@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 <st...@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 <jo...@gmail.com>
> >> >> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> >> >> > <st...@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
> >> > <st...@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
> > <rm...@gmail.com>
> >> >> >>>> To: Mark Struberg <st...@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"
> >> >> > <st...@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
> > <st...@yahoo.de>
> >> >> >>>>>> To:
> >> > "deltaspike-dev@incubator.apache.org"
> >> >> > <de...@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
> >> > <jo...@gmail.com>
> >> >> >>>>>>> To:
> > deltaspike-dev@incubator.apache.org;
> >> > Mark Struberg
> >> >> >>>>>> <st...@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
> >> >> > <st...@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
> >> >> > <ge...@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
> >> >> > <jo...@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
> >> >> >>>>>> <jo...@gmail.com>
> >> >> >>>>>>>> >> >>
> >> >> >>>>>>>> >> >> > but
> > the
> >> >> >>>>>>>> >> >> >
> > specific one
> >> > annotated a
> >> >> > certain way. The
> >> >> >>>>>> cleanest
> >> >> >>>>>>> way
> >> >> >>>>>>>> > (conceptual
> >> >> >>>>>>>> >> >> >
> >> >> >>>>>>>> >> >>
> >> >> >>>>>>>> >> >
> >> >> >>>>>>>> >> >
> >> >> >>>>>>>> >>
> >> >> >>>>>>>> >
> >> >> >>>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@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 <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: John D. Ament <jo...@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 <st...@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 <ge...@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 <st...@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 <st...@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 <jo...@gmail.com>
>> >> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>> >> > <st...@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
>> > <st...@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
> <rm...@gmail.com>
>> >> >>>> To: Mark Struberg <st...@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"
>> >> > <st...@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
> <st...@yahoo.de>
>> >> >>>>>> To:
>> > "deltaspike-dev@incubator.apache.org"
>> >> > <de...@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
>> > <jo...@gmail.com>
>> >> >>>>>>> To:
> deltaspike-dev@incubator.apache.org;
>> > Mark Struberg
>> >> >>>>>> <st...@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
>> >> > <st...@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
>> >> > <ge...@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
>> >> > <jo...@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
>> >> >>>>>> <jo...@gmail.com>
>> >> >>>>>>>> >> >>
>> >> >>>>>>>> >> >> > but
> the
>> >> >>>>>>>> >> >> >
> specific one
>> > annotated a
>> >> > certain way. The
>> >> >>>>>> cleanest
>> >> >>>>>>> way
>> >> >>>>>>>> > (conceptual
>> >> >>>>>>>> >> >> >
>> >> >>>>>>>> >> >>
>> >> >>>>>>>> >> >
>> >> >>>>>>>> >> >
>> >> >>>>>>>> >>
>> >> >>>>>>>> >
>> >> >>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <st...@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 <ge...@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 <st...@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 <st...@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 <jo...@gmail.com>
> >> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> >> > <st...@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
> > <st...@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 <rm...@gmail.com>
> >> >>>> To: Mark Struberg <st...@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"
> >> > <st...@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 <st...@yahoo.de>
> >> >>>>>> To:
> > "deltaspike-dev@incubator.apache.org"
> >> > <de...@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
> > <jo...@gmail.com>
> >> >>>>>>> To: deltaspike-dev@incubator.apache.org;
> > Mark Struberg
> >> >>>>>> <st...@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
> >> > <st...@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
> >> > <ge...@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
> >> > <jo...@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
> >> >>>>>> <jo...@gmail.com>
> >> >>>>>>>> >> >>
> >> >>>>>>>> >> >> > but the
> >> >>>>>>>> >> >> > specific one
> > annotated a
> >> > certain way. The
> >> >>>>>> cleanest
> >> >>>>>>> way
> >> >>>>>>>> > (conceptual
> >> >>>>>>>> >> >> >
> >> >>>>>>>> >> >>
> >> >>>>>>>> >> >
> >> >>>>>>>> >> >
> >> >>>>>>>> >>
> >> >>>>>>>> >
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@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 <ge...@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 <st...@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 <st...@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 <jo...@gmail.com>
>> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>> > <st...@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
> <st...@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 <rm...@gmail.com>
>> >>>> To: Mark Struberg <st...@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"
>> > <st...@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 <st...@yahoo.de>
>> >>>>>> To:
> "deltaspike-dev@incubator.apache.org"
>> > <de...@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
> <jo...@gmail.com>
>> >>>>>>> To: deltaspike-dev@incubator.apache.org;
> Mark Struberg
>> >>>>>> <st...@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
>> > <st...@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
>> > <ge...@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
>> > <jo...@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
>> >>>>>> <jo...@gmail.com>
>> >>>>>>>> >> >>
>> >>>>>>>> >> >> > but the
>> >>>>>>>> >> >> > specific one
> annotated a
>> > certain way. The
>> >>>>>> cleanest
>> >>>>>>> way
>> >>>>>>>> > (conceptual
>> >>>>>>>> >> >> >
>> >>>>>>>> >> >>
>> >>>>>>>> >> >
>> >>>>>>>> >> >
>> >>>>>>>> >>
>> >>>>>>>> >
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
@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 <st...@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 <st...@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 <jo...@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > <st...@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 <st...@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 <rm...@gmail.com>
> >>>> To: Mark Struberg <st...@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"
> > <st...@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 <st...@yahoo.de>
> >>>>>> To: "deltaspike-dev@incubator.apache.org"
> > <de...@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 <jo...@gmail.com>
> >>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> >>>>>> <st...@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
> > <st...@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
> > <ge...@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
> > <jo...@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
> >>>>>> <jo...@gmail.com>
> >>>>>>>> >> >>
> >>>>>>>> >> >> > but the
> >>>>>>>> >> >> > specific one annotated a
> > certain way. The
> >>>>>> cleanest
> >>>>>>> way
> >>>>>>>> > (conceptual
> >>>>>>>> >> >> >
> >>>>>>>> >> >>
> >>>>>>>> >> >
> >>>>>>>> >> >
> >>>>>>>> >>
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@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 <st...@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@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 <jo...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> <st...@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 <st...@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 <rm...@gmail.com>
>>>> To: Mark Struberg <st...@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"
> <st...@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 <st...@yahoo.de>
>>>>>> To: "deltaspike-dev@incubator.apache.org"
> <de...@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 <jo...@gmail.com>
>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>>>>>> <st...@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
> <st...@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
> <ge...@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
> <jo...@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
>>>>>> <jo...@gmail.com>
>>>>>>>> >> >>
>>>>>>>> >> >> > but the
>>>>>>>> >> >> > specific one annotated a
> certain way. The
>>>>>> cleanest
>>>>>>> way
>>>>>>>> > (conceptual
>>>>>>>> >> >> >
>>>>>>>> >> >>
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >>
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@gmail.com>
>To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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 <st...@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 <rm...@gmail.com>
>>>To: Mark Struberg <st...@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" <st...@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 <st...@yahoo.de>
>>>>> To: "deltaspike-dev@incubator.apache.org" <de...@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 <jo...@gmail.com>
>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>>>>> <st...@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 <st...@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 <ge...@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 <jo...@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
>>>>> <jo...@gmail.com>
>>>>>>> >> >>
>>>>>>> >> >> > but the
>>>>>>> >> >> > specific one annotated a certain way. The
>>>>> cleanest
>>>>>> way
>>>>>>> > (conceptual
>>>>>>> >> >> >
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
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 <st...@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 <rm...@gmail.com>
> >To: Mark Struberg <st...@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" <st...@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 <st...@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 <jo...@gmail.com>
> >>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> >>> <st...@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 <st...@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 <ge...@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 <jo...@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
> >>> <jo...@gmail.com>
> >>>>> >> >>
> >>>>> >> >> > but the
> >>>>> >> >> > specific one annotated a certain way. The
> >>> cleanest
> >>>> way
> >>>>> > (conceptual
> >>>>> >> >> >
> >>>>> >> >>
> >>>>> >> >
> >>>>> >> >
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@gmail.com>
>To: Mark Struberg <st...@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" <st...@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 <st...@yahoo.de>
>>> To: "deltaspike-dev@incubator.apache.org" <de...@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 <jo...@gmail.com>
>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>>> <st...@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 <st...@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 <ge...@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 <jo...@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
>>> <jo...@gmail.com>
>>>>> >> >>
>>>>> >> >> > but the
>>>>> >> >> > specific one annotated a certain way. The
>>> cleanest
>>>> way
>>>>> > (conceptual
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@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 <st...@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 <jo...@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > <st...@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 <st...@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 <ge...@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 <jo...@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
> > <jo...@gmail.com>
> >>> >> >>
> >>> >> >> > but the
> >>> >> >> > specific one annotated a certain way. The
> > cleanest
> >> way
> >>> > (conceptual
> >>> >> >> >
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <st...@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@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 <jo...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> <st...@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 <st...@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 <ge...@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 <jo...@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
> <jo...@gmail.com>
>>> >> >>
>>> >> >> > but the
>>> >> >> > specific one annotated a certain way. The
> cleanest
>> way
>>> > (conceptual
>>> >> >> >
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >
>>>
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@gmail.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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 <st...@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 <ge...@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 <jo...@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 <jo...@gmail.com>
>> >> >>
>> >> >> > but the
>> >> >> > specific one annotated a certain way. The cleanest
> way
>> > (conceptual
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
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 <st...@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 <ge...@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 <jo...@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 <jo...@gmail.com>
> >> >>
> >> >> > but the
> >> >> > specific one annotated a certain way. The cleanest way
> > (conceptual
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi mark,
i just compared it and solder uses b) as well (just not that explicit).
regards,
gerhard
2012/12/26 Mark Struberg <st...@yahoo.de>
> 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 <ge...@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 <jo...@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 <jo...@gmail.com>
> >> >>
> >> >> > but the
> >> >> > specific one annotated a certain way. The cleanest way
> > (conceptual
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <ge...@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 <jo...@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 <jo...@gmail.com>
>> >>
>> >> > but the
>> >> > specific one annotated a certain way. The cleanest way
> (conceptual
>> >> >
>> >>
>> >
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <jo...@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 <jo...@gmail.com>
> >>
> >> > but the
> >> > specific one annotated a certain way. The cleanest way (conceptual
> >> >
> >>
> >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@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 <jo...@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 <jo...@gmail.com>
>>
>> > but the
>> > specific one annotated a certain way. The cleanest way (conceptual
>> >
>>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
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 <jo...@gmail.com>
>
> > but the
> > specific one annotated a certain way. The cleanest way (conceptual
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <jo...@gmail.com>
> but the
> specific one annotated a certain way. The cleanest way (conceptual
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Gerhard,
No, the example I understand (without qualifiers), the problem is that the
current implementation doesn't work the way described in your example (for
example, if you want to inject into members they have to be public). With
the way we're implementing this (by having the handler implement
InvocationHandler) we cannot simply resolve an invocation handler, but the
specific one annotated a certain way. The cleanest way (conceptually,
since a lot of feedback I get is that the Seam way is too difficult to
understand) to then merge those is to make the invocation handlers CDI
beans directly and this would automatically inject members. Then logically
the annotation that has the handler should be a qualifier to find the
specific invocation handler (obviously we need to resolve an issue where
multiple handlers are created with the same annotations, but that's a
different issue).
John
On Wed, Dec 26, 2012 at 12:25 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:
> hi john,
>
> please have a look at [1] - then you might know what pete is talking about.
>
> regards,
> gerhard
>
> [1] http://s.apache.org/T8h
>
>
>
> 2012/12/26 John D. Ament <jo...@gmail.com>
>
> > Pete,
> >
> > What do you expect the "normal" way to be? I figured qualifiers made
> more
> > sense since a lot of the CDI functionality is based on qualifiers
> (though I
> > think a lot of applications mostly use a single type of an interface or
> > leverage alternatives).
> >
> >
> > On Mon, Dec 24, 2012 at 8:47 AM, Pete Muir <pm...@redhat.com> wrote:
> >
> > > I think it should work, adding a qualifier, but I don't think it's the
> > > "normal" way to do it.
> > >
> > > On 23 Dec 2012, at 16:12, John D. Ament wrote:
> > >
> > > > Well, this object is used for a specific case. In my opinion, you
> > should
> > > be
> > > > able to resolve it using
> > > >
> > > > @Inject @QueryHandler
> > > > private InvocationHandler queryHandler;
> > > >
> > > > Though why you may want to inject it in a client app is unknown to
> me;
> > it
> > > > does make it easier from an implementation standpoint.
> > > >
> > > > Does the service handler need to have any specific scope? Can it
> > inherit
> > > > the scope of what it's handling? I guess not, since it could be a
> > handler
> > > > to n things. NormalScope would be appropriate then.
> > > >
> > > >
> > > > On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de>
> > > wrote:
> > > >
> > > >> I guess because it might overlap with other qualifiers added in some
> > > cases.
> > > >>
> > > >> What do we gain for making it a qualifier?
> > > >>
> > > >> Another important difference to CDI interceptors is that they are
> > always
> > > >> @Dependent to the intercepted instance.
> > > >> Whereas the ServiceHandler should be of NormalScope, isn't?
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: John D. Ament <jo...@gmail.com>
> > > >>> To: deltaspike-dev@incubator.apache.org
> > > >>> Cc:
> > > >>> Sent: Saturday, December 22, 2012 7:56 PM
> > > >>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > > ServiceHandler
> > > >>>
> > > >>> Pete,
> > > >>>
> > > >>> Regarding interceptors - I think what I have is pretty close to the
> > > >>> interceptor definition, except this should only end up working on a
> > > >>> class/interface (I think?)
> > > >>>
> > > >>> Also, why wouldn't we want the annotation to also be a qualifier?
> > > >>>
> > > >>> John
> > > >>>
> > > >>>
> > > >>> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com>
> wrote:
> > > >>>
> > > >>>>
> > > >>>> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> > > >>>>
> > > >>>>> Hi all,
> > > >>>>>
> > > >>>>> So just to summarize the current proposal:
> > > >>>>>
> > > >>>>> - Create a new annotation @ServiceHandlerBinding (in core/api)
> > which
> > > >>> will
> > > >>>>> be placed on on the interface that defines points of the
> > > >>>>> - Create a new annotation @ServiceHandler (in core/api) (I think
> > > >> based
> > > >>> on
> > > >>>>> below this isn't needed since we have the interface now).
> > > >>>>> - Create an extension that can generate object proxies that link
> > > >> calls
> > > >>> to
> > > >>>>> methods on the - org.apache.deltaspike.core.api....
> > > >>>>>
> > > >>>>> Define the binding type annotation:
> > > >>>>>
> > > >>>>> @ServiceHandlerBinding
> > > >>>>> @Qualifier
> > > >>>>> public @interface QueryHandler {
> > > >>>>> }
> > > >>>>
> > > >>>> I don't think we want @Qualifier here.
> > > >>>>
> > > >>>>>
> > > >>>>> which will define the relationship between the interface/abstract
> > > >>> class
> > > >>>>> that will use the service handler and the class that will serve
> as
> > > >> the
> > > >>>>> invocation handler.
> > > >>>>>
> > > >>>>> For example, we can use @QueryHandler on an interface:
> > > >>>>>
> > > >>>>> @QueryHandler
> > > >>>>> public interface PersonDAO {
> > > >>>>> //...
> > > >>>>> }
> > > >>>>>
> > > >>>>> When the container finds this interface it will identify the
> > > >>> appropriate
> > > >>>>> InvocationHandler, based on the following matches:
> > > >>>>>
> > > >>>>> - Implements InvocationHandler
> > > >>>>
> > > >>>> Yes.
> > > >>>>
> > > >>>>> - Is annotated @QueryHandler
> > > >>>>
> > > >>>> Ish, this should follow standard CDI resolution rules, you can
> copy
> > > the
> > > >>>> way interceptor bindings work here.
> > > >>>>
> > > >>>>> - Is annotated @ServiceHandler
> > > >>>>
> > > >>>> Yes
> > > >>>>
> > > >>>>>
> > > >>>>> DeltaSpike will provide a proxied object where all abstract
> method
> > > >>> calls
> > > >>>>> are delegated to the InvocationHandler. The InvocationHandler
> will
> > > >>> need
> > > >>>> to
> > > >>>>> have logic to handle all methods as defined within the class, as
> > long
> > > >>> as
> > > >>>>> that method is invoked through the InvocationHandler.
> > > >>>>>
> > > >>>>> @QueryHandler @ServiceHandler
> > > >>>>> public QueryHandlerInvoker implements InvocationHandler {
> > > >>>>>
> > > >>>>> public Object invoke(Object proxy, Method method, Object[] args)
> {
> > > >>>>> if(method.getName().startsWith("find..."){
> > > >>>>> //...
> > > >>>>> }
> > > >>>>> return null;
> > > >>>>>
> > > >>>>> }
> > > >>>>> }
> > > >>>>>
> > > >>>>> In addition, the ServiceHandlerBinding can be placed on an
> abstract
> > > >>>> class.
> > > >>>>> In this case, only abstract methods will be passed to the
> > > >>>>> InvocationHandler.
> > > >>>>>
> > > >>>>> @QueryHandler
> > > >>>>> public abstract interface PersonDAO {
> > > >>>>> public String doSomethingConcrete() {
> > > >>>>> return "concrete";
> > > >>>>> }
> > > >>>>>
> > > >>>>> public abstract Person find(int id);
> > > >>>>> }
> > > >>>>>
> > > >>>>> Only the find method will be wrapped, the method
> > doSomethingConcrete
> > > >>> will
> > > >>>>> be invoked directly. When interacting with an abstract class,
> the
> > > >>>>> InvocationHandler can call methods on the proxied object.
> > > >>>>>
> > > >>>>> Finally, the app developer will be able to simply inject their
> > > >>>>> interface/abstract class in to their beans to perform work:
> > > >>>>>
> > > >>>>> @Inject @QueryHandler PersonDAO dao;
> > > >>>>>
> > > >>>>> Questions:
> > > >>>>>
> > > >>>>> Should we provide a store (simple key/value map) to keep a
> history
> > of
> > > >>>> found
> > > >>>>> object types and how they map?
> > > >>>>
> > > >>>> You mean like BeanManager.resolveInterceptors() ? I guess this is
> > > >> useful.
> > > >>>>
> > > >>>>> Should we depend on certain libraries for proxying (e.g.
> > javassist, I
> > > >>>> think
> > > >>>>> both Weld & OWB use this still?)
> > > >>>>
> > > >>>> If you want to just cover interfaces, it's easy, you can use
> > proxying
> > > >>> from
> > > >>>> the JDK. Otherwise yes you need to pick a lib.
> > > >>>>
> > > >>>> Weld doesn't use javassist for proxying, but does for other stuff.
> > > >>>>
> > > >>>>> Since we now use the interface InvocationHandler should we rename
> > the
> > > >>>>> binding to be InvocationHandlerBinding?
> > > >>>>
> > > >>>> Yes, this makes sense
> > > >>>>
> > > >>>>> I also think it's not necessary to
> > > >>>>> have @ServiceHandler since the marker interface now exists.
> > > >>>>
> > > >>>> +1
> > > >>>>
> > > >>>>>
> > > >>>>> Comments welcome..
> > > >>>>>
> > > >>>>> John
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> > > >>> <lightguard.jp@gmail.com
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> +1 for @ServiceHandler
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> > > >>> <john.d.ament@gmail.com
> > > >>>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> If we're still calling the feature
> > > >>> "ServiceHandler" then why not
> > > >>>>>>> @ServiceHandler?
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> > > >>>>>>> <rm...@gmail.com>wrote:
> > > >>>>>>>
> > > >>>>>>>> if we don't need it perfect, if we need it we'll
> > > >>> just use another name
> > > >>>>>>>> @DSHandler, @Handler...whatever it is ;)
> > > >>>>>>>>
> > > >>>>>>>> Romain Manni-Bucau
> > > >>>>>>>> Twitter: @rmannibucau
> > > >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> > > >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>>> Github: https://github.com/rmannibucau
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> > > >>>>>>>>> :-) Yes for sure. I suspect we dont' need
> > > >>> @InvocationHandler at all.
> > > >>>>>>>>>
> > > >>>>>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> The problem I have is that now InvocationHandler
> > > >>> is both an
> > > >>>>>> interface
> > > >>>>>>>> and
> > > >>>>>>>>>> an @interface which will make it impossible for
> > > >>> imports. I don't
> > > >>>>>>> think
> > > >>>>>>>>>> they should have the same name.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> > > >>> <pm...@redhat.com>
> > > >>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> All,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> So mostly ok from my perspective. One
> > > >>> thing to note:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> @InvocationHandlerBinding
> > > >>>>>>>>>>>> public @interface Repository {}
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> @Repository
> > > >>>>>>>>>>>> public interface MyRepository {
> > > >>>>>>>>>>>> ...
> > > >>>>>>>>>>>> }
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> @Repository @InvocationHandler
> > > >>>>>>>>>>>> public class MyInvocationHandler
> > > >>> implements InvocationHandler {
> > > >>>>>>>>>>>> ...
> > > >>>>>>>>>>>> }
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Why do we have a @InvocationHandler here?
> > > >>> Is it supposed to be
> > > >>>>>>>>>>>> @InvocationHandlerBinding instead? If so,
> > > >>> is it really needed
> > > >>>>>> here?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> No, it should be @InvocationHandler, it's
> > > >>> analagous to
> > > >>>>>> @Interceptor.
> > > >>>>>>>> It's
> > > >>>>>>>>>>> not 100% necessary as we already implement the
> > > >>> interface, which is
> > > >>>>>>>> enough
> > > >>>>>>>>>>> of the marker.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thinking about the implementation for
> > > >>> this, I think this actually
> > > >>>>>>>> becomes
> > > >>>>>>>>>>>> easier to use and easier to understand
> > > >>> over the Solder solution.
> > > >>>>>>> The
> > > >>>>>>>>>>>> implementation of the InvocationHandler
> > > >>> becomes a true CDI bean.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Should DS support Interceptors and
> > > >>> Decorators on
> > > >>>>>>>>>>>> InvocationHandler beans?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Do you mean the implementation class or
> > > >>> the interface?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> John
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> > > >>> Manni-Bucau
> > > >>>>>>>>>>>> <rm...@gmail.com>wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> i'd rather say no because the idea
> > > >>> is to ease "util" extension
> > > >>>>>>>>>>>>> writing. that's clearly not
> > > >>> intended to be full business beans
> > > >>>>>> IMO
> > > >>>>>>>> (at
> > > >>>>>>>>>>>>> least for a first step)
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> That's why i'd leave it as
> > > >>> this for now
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> wdyt?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Romain Manni-Bucau
> > > >>>>>>>>>>>>> Twitter: @rmannibucau
> > > >>>>>>>>>>>>> Blog:
> > > >>> http://rmannibucau.wordpress.com/
> > > >>>>>>>>>>>>> LinkedIn:
> > > >>> http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>>>>>>>> Github: https://github.com/rmannibucau
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2012/12/20 Arne Limburg
> > > >>> <ar...@openknowledge.de>:
> > > >>>>>>>>>>>>>> Mark refers to my call stack.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Out of the box this call stack
> > > >>> would exist just in OWB, because
> > > >>>>>>> Weld
> > > >>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>> not apply any Interceptors or
> > > >>> Decorators...
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> The question is: Should DS support
> > > >>> Interceptors and Decorators
> > > >>>>>> on
> > > >>>>>>>>>>>>>> InvocationHandler beans? My answer
> > > >>> would be: yes, if our
> > > >>>>>>>> implementation
> > > >>>>>>>>>>>>>> shall be a preview of CDI-110.
> > > >>>>>>>>>>>>>> And that would make things
> > > >>> complicated in the implementation...
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Am 20.12.12 12:11 schrieb
> > > >>> "Romain Manni-Bucau" unter
> > > >>>>>>>>>>>>>> <rm...@gmail.com>:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> is it an issue for
> > > >>> servicehandler? i don't think so
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> it is often used to get util
> > > >>> classes dynamically created, it is
> > > >>>>>>>> rarely
> > > >>>>>>>>>>>>>>> (i never saw it) decorated
> > > >>> directly
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Romain Manni-Bucau
> > > >>>>>>>>>>>>>>> Twitter: @rmannibucau
> > > >>>>>>>>>>>>>>> Blog:
> > > >>> http://rmannibucau.wordpress.com/
> > > >>>>>>>>>>>>>>> LinkedIn:
> > > >>> http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>>>>>>>>>> Github:
> > > >>> https://github.com/rmannibucau
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2012/12/20 Mark Struberg
> > > >>> <st...@yahoo.de>:
> > > >>>>>>>>>>>>>>>> we stumbled about this
> > > >>> lately. It seems CDI only forces
> > > >>>>>> support
> > > >>>>>>>> for
> > > >>>>>>>>>>>>>>>> interceptors and
> > > >>> decorators for CDI-annotated classes, but not
> > > >>>>>>> for
> > > >>>>>>>>>>>>>>>> Bean<T> which get
> > > >>> added via extensions nor even producer
> > > >>>>>> methods
> > > >>>>>>>> and
> > > >>>>>>>>>>>>>>>> fields :/
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Of course OWB does it, but
> > > >>> it would be not portable...
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> LieGrue,
> > > >>>>>>>>>>>>>>>> strub
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> ----- Original Message
> > > >>> -----
> > > >>>>>>>>>>>>>>>>> From: Arne Limburg
> > > >>> <ar...@openknowledge.de>
> > > >>>>>>>>>>>>>>>>> To:
> > > >>> "deltaspike-dev@incubator.apache.org"
> > > >>>>>>>>>>>>>>>>>
> > > >>> <de...@incubator.apache.org>
> > > >>>>>>>>>>>>>>>>> Cc:
> > > >>>>>>>>>>>>>>>>> Sent: Thursday,
> > > >>> December 20, 2012 10:18 AM
> > > >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > > >>> [DELTASPIKE-113] Review and Discuss
> > > >>>>>>>>>>>>>>>>> ServiceHandler
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> T wo things about
> > > >>> this: First: I don't like from the solder
> > > >>>>>>>>>>> approach,
> > > >>>>>>>>>>>>>>>>> because the interface
> > > >>> is annotated instead of the
> > > >>>>>>> implementation.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Second, if we
> > > >>> implement this we should conceptually make
> > > >>>>>> clear
> > > >>>>>>>> how
> > > >>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>> differentiates from
> > > >>> Interceptors and Decorators. And
> > > >>>>>>> personally I
> > > >>>>>>>>>>>>> think
> > > >>>>>>>>>>>>>>>>> this would work better
> > > >>> with the InvocationHandler approach
> > > >>>>>> than
> > > >>>>>>>> with
> > > >>>>>>>>>>>>> an
> > > >>>>>>>>>>>>>>>>> approach that is very
> > > >>> similar to interceptors.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> So +1 for an approach
> > > >>> like this:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>> @HandlesInvocationsOn(MyInterface.class)
> > > >>>>>>>>>>>>>>>>> public class
> > > >>> MyInvocationHandler implements
> > > >>>>>> InvocationHandler {
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Technically we would
> > > >>> register a custom Bean for every found
> > > >>>>>>>>>>>>>>>>> InvocationHandler with
> > > >>> that annotation and take over the
> > > >>>>>>>>>>>>>>>>> interceptor-bindings
> > > >>> from the interfaceŠ
> > > >>>>>>>>>>>>>>>>> So the invocation
> > > >>> stack would be clear, too:
> > > >>>>>>>>>>>>>>>>> First Interceptors,
> > > >>>>>>>>>>>>>>>>> Second Decorators,
> > > >>>>>>>>>>>>>>>>> Third
> > > >>> InvocationHandler
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Wdyt?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Arne
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Am 20.12.12 01:53
> > > >>> schrieb "Romain Manni-Bucau" unter
> > > >>>>>>>>>>>>>>>>>
> > > >>> <rm...@gmail.com>:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> that's a need,
> > > >>> DS targets CDI 1.0 for now so just make this
> > > >>>>>>>> solder
> > > >>>>>>>>>>>>>>>>>> part portable ans
> > > >>> it should be fine
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Romain Manni-Bucau
> > > >>>>>>>>>>>>>>>>>> Twitter:
> > > >>> @rmannibucau
> > > >>>>>>>>>>>>>>>>>> Blog:
> > > >>> http://rmannibucau.wordpress.com/
> > > >>>>>>>>>>>>>>>>>> LinkedIn:
> > > >>> http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>>>>>>>>>>>>> Github:
> > > >>> https://github.com/rmannibucau
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 2012/12/20 Jason
> > > >>> Porter <li...@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>> At this point,
> > > >>> I'd say just do it as is in solder.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Wed, Dec
> > > >>> 19, 2012 at 5:25 PM, John D. Ament
> > > >>>>>>>>>>>>>>>>>>>
> > > >>> <jo...@gmail.com>wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Hi All,
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Regarding
> > > >>> the two open questions:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 1) the
> > > >>> approach (including the name/s) we agree on will be
> > > >>>>>>>> used
> > > >>>>>>>>>>>>>>>>> also
> > > >>>>>>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> cdi 1.1
> > > >>> (the only difference is the package)
> > > >>>>>>>>>>>>>>>>>>>> 2) the eg
> > > >>> has a different opinion about it ->
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> It looks
> > > >>> like the JSR's answer
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> (https://issues.jboss.org/browse/CDI-110 )
> > > >>>>>>>>>>>>>>>>>>>> is still
> > > >>> unresolved - I'm not sure if we can get any
> > > >>>>>> further
> > > >>>>>>>>>>>>>>>>> answer at
> > > >>>>>>>>>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>>>>>> time. The
> > > >>> last posts on the subject seem to discuss using
> > > >>>>>>>>>>>>>>>>> something
> > > >>>>>>>>>>>>>>>>>>>> along
> > > >>>>>>>>>>>>>>>>>>>> the lines
> > > >>> of an invocation handler, which I think would
> > > >>>>>> work
> > > >>>>>>>>>>> well.
> > > >>>>>>>>>>>>>>>>>>>> Since
> > > >>>>>>>>>>>>>>>>>>>> we have
> > > >>> some features coming up that are interested in
> > > >>>>>>> having
> > > >>>>>>>>>>>>>>>>> service
> > > >>>>>>>>>>>>>>>>>>>> handlers
> > > >>> available, do we
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 1.
> > > >>> Implement as is, or similar to, what is currently in
> > > >>>>>>>> Solder?
> > > >>>>>>>>>>>>>>>>>>>> 2. Push EG
> > > >>> on a resolution
> > > >>>>>>>>>>>>>>>>>>>> 3. Do it
> > > >>> using invocation handlers.
> > > >>>>>>>>>>>>>>>>>>>> 4. Do it
> > > >>> some other way?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> John
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On Wed,
> > > >>> Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard.petracek@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> hi
> > > >>> john,
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> as
> > > >>> mentioned before we need the answers to the existing
> > > >>>>>>>>>>>>>>>>> questions.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/4/4 John D. Ament <jo...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> All,
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> I
> > > >>> kind of let this one and the other drop off my radar,
> > > >>>>>> I
> > > >>>>>>>>>>>>>>>>>>>> apologize.
> > > >>>>>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> looks like where we last left off, Gerhard was still
> > > >>>>>>>>>>>>>>>>> requesting
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> additional
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> comments from everyone. Any other feedback?
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> John
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On
> > > >>> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard.petracek@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>> hi
> > > >>> george,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>> thx
> > > >>> for the information. i thought there might be at
> > > >>>>>>>>>>>>>>>>> least some
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> additional
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> answers/clarifications, since pete asked for them in
> > > >>>>>>>>>>>>>>>>> several
> > > >>>>>>>>>>>>>>>>>>>> comments.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> -> imo we should continue with them.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/12 George Gastaldi
> > > >>>>>>>>>>>>>>>>>
> > > >>> <ge...@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Hello Gerhard,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Yeah, it´s the last state. I know it´s quite
> > > >>>>>>>>>>>>>>>>> old, but I
> > > >>>>>>>>>>>>>>>>>>>> haven´t
> > > >>> had
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> time
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> to work on it after that.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> George
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/12 Gerhard Petracek
> > > >>>>>>>>>>>>>>>>>
> > > >>> <ge...@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> hi george,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> thx for the link.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> i'm not sure if it is the latest state
> > > >>>>>>>>>>>>>>>>> of your discussion
> > > >>>>>>>>>>>>>>>>>>>> and/or
> > > >>>>>>>>>>>>>>>>>>>>> draft
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> (at least it's quite old already).
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/7 George Gastaldi
> > > >>>>>>>>>>>>>>>>>
> > > >>> <ge...@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Hi !
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> +1 to #1. I also agree that the term
> > > >>>>>>>>>>>>>>>>> "Service
> > > >>> Handler" might
> > > >>>>>>>>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>>>> so
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> appropriate, so it should be discussed
> > > >>>>>>>>>>>>>>>>> as well.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Here is the latest pull request with
> > > >>>>>>>>>>>>>>>>> some comments from
> > > >>> Pete
> > > >>>>>>>>>>>>>>>>>>>> yet
> > > >>>>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>>>> be
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> reviewed:
> > > >>>>>>>>>>>>>>>>>
> > > >>> https://github.com/jboss/cdi/pull/28
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/7 Pete Muir
> > > >>>>>>>>>>>>>>>>>
> > > >>> <pm...@redhat.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Agreed :-)
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> George is working on it for CDI
> > > >>>>>>>>>>>>>>>>> 1.1. George, can you
> > > >>> share
> > > >>>>>>>>>>>>>>>>>>>> your
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> proposal
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> so far?
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On 7 Mar 2012, at 17:05, Gerhard
> > > >>>>>>>>>>>>>>>>> Petracek wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> hi pete,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> independent of my opinion
> > > >>>>>>>>>>>>>>>>> about the feature
> > > >>> (which is
> > > >>>>>>>>>>>>>>>>>>>> still
> > > >>>>>>>>>>>>>>>>>>>>> +0):
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> if it should be part of cdi
> > > >>>>>>>>>>>>>>>>> 1.1, we have the
> > > >>> following
> > > >>>>>>>>>>>>>>>>>>>> options
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> imo:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 1) the approach (including
> > > >>>>>>>>>>>>>>>>> the name/s) we agree
> > > >>> on will
> > > >>>>>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>> used
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> also
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> for
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> cdi 1.1 (the only difference
> > > >>>>>>>>>>>>>>>>> is the package)
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2) the eg has a different
> > > >>>>>>>>>>>>>>>>> opinion about it ->
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2a) the rest of the eg joins
> > > >>>>>>>>>>>>>>>>> this discussion
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2b) we wait for the final
> > > >>>>>>>>>>>>>>>>> version and just allow
> > > >>> the same
> > > >>>>>>>>>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> cdi
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 1.0
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 3) if the eg doesn't
> > > >>>>>>>>>>>>>>>>> agree on the idea, it
> > > >>> should be
> > > >>>>>>>>>>>>>>>>>>>> re-visited
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> for
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> deltaspike (if we really need
> > > >>>>>>>>>>>>>>>>> it)
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 4) we agree on it independent
> > > >>>>>>>>>>>>>>>>> of the result in cdi
> > > >>> 1.1
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 1-3 is ok for me but -1 for
> > > >>>>>>>>>>>>>>>>> #4
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/7 Pete Muir
> > > >>>>>>>>>>>>>>>>>
> > > >>> <pm...@redhat.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> I'm not sure what you
> > > >>>>>>>>>>>>>>>>> mean by a "super
> > > >>> interceptor",
> > > >>>>>>>>>>>>>>>>>>>> but if
> > > >>>>>>>>>>>>>>>>>>>>> you
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> mean it
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> as
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> in "super man"
> > > >>>>>>>>>>>>>>>>> (something better than
> > > >>> an interceptor),
> > > >>>>>>>>>>>>>>>>>>>> then
> > > >>>>>>>>>>>>>>>>>>>> I
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> would
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> disagree, it's
> > > >>>>>>>>>>>>>>>>> actually a specialised
> > > >>> form of
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> interceptor.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> The best use case I know
> > > >>>>>>>>>>>>>>>>> of is the one John
> > > >>> mentions -
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> creating
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> type
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> safe
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> references to queries:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> @QueryService
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> interface UserQuery {
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> @Query("select u
> > > >>>>>>>>>>>>>>>>> from User u")
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> public List<User>
> > > >>>>>>>>>>>>>>>>> getAllUsers();
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> @Query("select u
> > > >>>>>>>>>>>>>>>>> from User u order by
> > > >>> u.name")
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> public List<User>
> > > >>>>>>>>>>>>>>>>>
> > > >>> getAllUsersSortedByName();
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> }
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Now, it may be the case
> > > >>>>>>>>>>>>>>>>> that there aren't
> > > >>> any other use
> > > >>>>>>>>>>>>>>>>>>>> cases
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> for
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> service
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> handlers, in which case
> > > >>>>>>>>>>>>>>>>> we should perhaps just
> > > >>> offer
> > > >>>>>>>>>>>>>>>>>>>> this
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> particular
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> service handler -
> > > >>>>>>>>>>>>>>>>> references to type
> > > >>> safe queries - as I
> > > >>>>>>>>>>>>>>>>>>>> think
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> this
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> is
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> an
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> extremely powerful idea.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Note, that at the moment
> > > >>>>>>>>>>>>>>>>> service handlers are
> > > >>> scheduled
> > > >>>>>>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>>> CDI
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> 1.1.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On 7 Mar 2012, at 02:35,
> > > >>>>>>>>>>>>>>>>> Jason Porter wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Somewhat. I
> > > >>>>>>>>>>>>>>>>> wouldn't really
> > > >>> think of them as overrides,
> > > >>>>>>>>>>>>>>>>>>>> they,
> > > >>>>>>>>>>>>>>>>>>>>>> to
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> me,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> seem more like items to
> > > >>>>>>>>>>>>>>>>> do in addition to
> > > >>> whatever the
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> original
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> impl
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> does.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> ServiceHandlers to me
> > > >>>>>>>>>>>>>>>>> seem more like super
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> interceptors.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Sent from my iPhone
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On Mar 6, 2012, at
> > > >>>>>>>>>>>>>>>>> 19:23, "John D.
> > > >>> Ament" <
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> john.d.ament@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> @jason
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> I think the
> > > >>>>>>>>>>>>>>>>> concepts are very
> > > >>> dissimilar.
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> servicehandlers
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> create
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> implementation.
> > > >>>>>>>>>>>>>>>>> delegates are more
> > > >>> like overrides and
> > > >>>>>>>>>>>>>>>>>>>> need
> > > >>>>>>>>>>>>>>>>>>>>> to
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> know
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> about
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the method
> > > >>>>>>>>>>>>>>>>> signature.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On Tue, Mar 6,
> > > >>>>>>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> > > >>> Porter <
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> lightguard.jp@gmail.com
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> I think the
> > > >>>>>>>>>>>>>>>>> idea of
> > > >>> ServiceHandlers are good, but,
> > > >>>>>>>>>>>>>>>>>>>> could
> > > >>>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> not
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> do
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> this
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> with
> > > >>>>>>>>>>>>>>>>> delegates?
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Sent from my
> > > >>>>>>>>>>>>>>>>> iPhone
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On Mar 6,
> > > >>>>>>>>>>>>>>>>> 2012, at 19:05,
> > > >>> "John D. Ament" <
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> john.d.ament@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> @mark
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> I
> > > >>>>>>>>>>>>>>>>> don't think
> > > >>> it's a hard requirement for it to be
> > > >>>>>>>>>>>>>>>>>>>> on an
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> interface.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> One of
> > > >>>>>>>>>>>>>>>>> the best use-cases we
> > > >>> built at my job is
> > > >>>>>>>>>>>>>>>>>>>> using it
> > > >>>>>>>>>>>>>>>>>>>>> for
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> calling
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> PL/SQL.
> > > >>>>>>>>>>>>>>>>> The JDBC bindings do
> > > >>> work, but not pretty.
> > > >>>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>> were
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> able to
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> create
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> a fairly
> > > >>>>>>>>>>>>>>>>> clean wrapper API,
> > > >>> generic enough for
> > > >>>>>>>>>>>>>>>>>>>> binding
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> in/out
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> parameters.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> JOhn
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On Tue,
> > > >>>>>>>>>>>>>>>>> Mar 6, 2012 at 12:58
> > > >>> PM, Mark Struberg <
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> struberg@yahoo.de>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> actually I don't
> > > >>> really see a real benefit. I just
> > > >>>>>>>>>>>>>>>>>>>> don't
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> yet
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> grok
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> use
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> case
> > > >>>>>>>>>>>>>>>>> for real world
> > > >>> projects.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Why
> > > >>>>>>>>>>>>>>>>> would one intercept an
> > > >>> Interface and delegate
> > > >>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>> calls
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>> to
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> a
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> method
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> handler?
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> This
> > > >>>>>>>>>>>>>>>>> could be neat for
> > > >>> mocking, but there are
> > > >>>>>>>>>>>>>>>>>>>> better
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> frameworks for
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> that.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> thus
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> -0.2
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> LieGrue,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> strub
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> -----
> > > >>>>>>>>>>>>>>>>> Original Message -----
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> From: Gerhard Petracek
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> <ge...@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> To:
> > > >>> deltaspike-dev@incubator.apache.org
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Cc:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Sent: Tuesday, March
> > > >>> 6, 2012 5:15 PM
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > > >>> [DELTASPIKE-113] Review and
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> Discuss
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> ServiceHandler
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> if you have a lot of
> > > >>> shared code, you can extract
> > > >>>>>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> 1-n
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> method/s or
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> an
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> abstract class which
> > > >>> is still easier than a new
> > > >>>>>>>>>>>>>>>>>>>> concept.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> at least i haven't
> > > >>> seen an use-case which really
> > > >>>>>>>>>>>>>>>>>>>> needed
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> it.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> that
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> was
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> reason for a +0 (which
> > > >>> still means that i'm ok
> > > >>>>>>>>>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>>>>>>> adding
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> it).
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> > > >>> <pm...@redhat.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> So, you mean just write a bean with all the
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> boilerplate
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> code
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> in
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> it?
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> hi pete,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> instead of the interface you can just
> > > >>>>>>>>>>>>>>>>> implement
> > > >>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>> bean
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> which
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> does
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> same.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/6 Pete Muir
> > > >>>>>>>>>>>>>>>>>
> > > >>> <pm...@redhat.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> What CDI mechanism would you use
> > > >>>>>>>>>>>>>>>>> instead?
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> On 5 Mar 2012, at 08:47, Gerhard
> > > >>>>>>>>>>>>>>>>> Petracek
> > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> +0
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> no -1 because there are
> > > >>>>>>>>>>>>>>>>> use-cases for it.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> no +1 because i would use std.
> > > >>>>>>>>>>>>>>>>> cdi mechanisms
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> instead.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/4 Gerhard Petracek <
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard.petracek@gmail.com
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> hi john,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the sub-task is perfectly
> > > >>>>>>>>>>>>>>>>> fine.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> gerhard
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> 2012/3/4 John D. Ament
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> <jo...@gmail.com>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Hi All
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> I wanted to bring up
> > > >>>>>>>>>>>>>>>>> the subject of
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>> ServiceHandler.
> > > >>>>>>>>>>>>>>>>>>>>>> I
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> added 113 as a
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> child
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> of DELTASPIKE-2, looked
> > > >>>>>>>>>>>>>>>>> appropriate but not
> > > >>>>>>>>>>>>>>>>>>>> 100%
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> sure
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> (so please let
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> me
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> know if you think
> > > >>>>>>>>>>>>>>>>> it's not
> > > >>> appropriate as a
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> child).
> > > >>> ServiceHandler
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> is
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> a
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> feature in Solder that
> > > >>>>>>>>>>>>>>>>> allows you to define
> > > >>>>>>>>>>>>>>>>>>>> an
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> interceptor that
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> manages
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> generic calls against
> > > >>>>>>>>>>>>>>>>> an injected interface.
> > > >>>>>>>>>>>>>>>>>>>> The
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> API
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> is as follows:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> -
> > > >>>>>>>>>>>>>>>>>
> > > >>> @ServiceHandlerType(Class<?> clazz) -
> > > >>>>>>>>>>>>>>>>>>>> placed
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> on an annotation that
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> would
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> be placed on the
> > > >>>>>>>>>>>>>>>>> interface. Indicates
> > > >>> what
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> interceptor would be
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> invoked
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> for calls against this
> > > >>>>>>>>>>>>>>>>> interface.
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> It's then up to the
> > > >>>>>>>>>>>>>>>>> application
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> developer/framework
> > > >>> author to define
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> annotations that go on
> > > >>>>>>>>>>>>>>>>> methods, as well as
> > > >>>>>>>>>>>>>>>>>>>> the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> interceptor itself
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> that
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> will
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> be invoked. The
> > > >>>>>>>>>>>>>>>>> feature for
> > > >>> ServiceHandler
> > > >>>>>>>>>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>>>>>>>> be
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> to provide the
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> API of
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> the type and then the
> > > >>>>>>>>>>>>>>>>> infrastructure
> > > >>>>>>>>>>>>>>>>>>>> required
> > > >>> to
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>> make
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> the interceptor
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> be
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> called. Existing
> > > >>>>>>>>>>>>>>>>> documentation of the
> > > >>>>>>>>>>>>>>>>>>>> feature:
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>
> > > >>>
> > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> > > >>>>>>>>>>>>>>>>>>>> ser
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>> vicehandler.html
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> Regards,
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>> john
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>> Jason Porter
> > > >>>>>>>>>>>>>>>>>>>
> > > >>> http://lightguard-jp.blogspot.com
> > > >>>>>>>>>>>>>>>>>>>
> > > >>> http://twitter.com/lightguardjp
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Software
> > > >>> Engineer
> > > >>>>>>>>>>>>>>>>>>> Open Source
> > > >>> Advocate
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> PGP key id:
> > > >>> 926CCFF5
> > > >>>>>>>>>>>>>>>>>>> PGP key
> > > >>> available at: keyserver.net, pgp.mit.edu
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Jason Porter
> > > >>>>>> http://lightguard-jp.blogspot.com
> > > >>>>>> http://twitter.com/lightguardjp
> > > >>>>>>
> > > >>>>>> Software Engineer
> > > >>>>>> Open Source Advocate
> > > >>>>>>
> > > >>>>>> PGP key id: 926CCFF5
> > > >>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> > > >>>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
please have a look at [1] - then you might know what pete is talking about.
regards,
gerhard
[1] http://s.apache.org/T8h
2012/12/26 John D. Ament <jo...@gmail.com>
> Pete,
>
> What do you expect the "normal" way to be? I figured qualifiers made more
> sense since a lot of the CDI functionality is based on qualifiers (though I
> think a lot of applications mostly use a single type of an interface or
> leverage alternatives).
>
>
> On Mon, Dec 24, 2012 at 8:47 AM, Pete Muir <pm...@redhat.com> wrote:
>
> > I think it should work, adding a qualifier, but I don't think it's the
> > "normal" way to do it.
> >
> > On 23 Dec 2012, at 16:12, John D. Ament wrote:
> >
> > > Well, this object is used for a specific case. In my opinion, you
> should
> > be
> > > able to resolve it using
> > >
> > > @Inject @QueryHandler
> > > private InvocationHandler queryHandler;
> > >
> > > Though why you may want to inject it in a client app is unknown to me;
> it
> > > does make it easier from an implementation standpoint.
> > >
> > > Does the service handler need to have any specific scope? Can it
> inherit
> > > the scope of what it's handling? I guess not, since it could be a
> handler
> > > to n things. NormalScope would be appropriate then.
> > >
> > >
> > > On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de>
> > wrote:
> > >
> > >> I guess because it might overlap with other qualifiers added in some
> > cases.
> > >>
> > >> What do we gain for making it a qualifier?
> > >>
> > >> Another important difference to CDI interceptors is that they are
> always
> > >> @Dependent to the intercepted instance.
> > >> Whereas the ServiceHandler should be of NormalScope, isn't?
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: John D. Ament <jo...@gmail.com>
> > >>> To: deltaspike-dev@incubator.apache.org
> > >>> Cc:
> > >>> Sent: Saturday, December 22, 2012 7:56 PM
> > >>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > ServiceHandler
> > >>>
> > >>> Pete,
> > >>>
> > >>> Regarding interceptors - I think what I have is pretty close to the
> > >>> interceptor definition, except this should only end up working on a
> > >>> class/interface (I think?)
> > >>>
> > >>> Also, why wouldn't we want the annotation to also be a qualifier?
> > >>>
> > >>> John
> > >>>
> > >>>
> > >>> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
> > >>>
> > >>>>
> > >>>> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> > >>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>> So just to summarize the current proposal:
> > >>>>>
> > >>>>> - Create a new annotation @ServiceHandlerBinding (in core/api)
> which
> > >>> will
> > >>>>> be placed on on the interface that defines points of the
> > >>>>> - Create a new annotation @ServiceHandler (in core/api) (I think
> > >> based
> > >>> on
> > >>>>> below this isn't needed since we have the interface now).
> > >>>>> - Create an extension that can generate object proxies that link
> > >> calls
> > >>> to
> > >>>>> methods on the - org.apache.deltaspike.core.api....
> > >>>>>
> > >>>>> Define the binding type annotation:
> > >>>>>
> > >>>>> @ServiceHandlerBinding
> > >>>>> @Qualifier
> > >>>>> public @interface QueryHandler {
> > >>>>> }
> > >>>>
> > >>>> I don't think we want @Qualifier here.
> > >>>>
> > >>>>>
> > >>>>> which will define the relationship between the interface/abstract
> > >>> class
> > >>>>> that will use the service handler and the class that will serve as
> > >> the
> > >>>>> invocation handler.
> > >>>>>
> > >>>>> For example, we can use @QueryHandler on an interface:
> > >>>>>
> > >>>>> @QueryHandler
> > >>>>> public interface PersonDAO {
> > >>>>> //...
> > >>>>> }
> > >>>>>
> > >>>>> When the container finds this interface it will identify the
> > >>> appropriate
> > >>>>> InvocationHandler, based on the following matches:
> > >>>>>
> > >>>>> - Implements InvocationHandler
> > >>>>
> > >>>> Yes.
> > >>>>
> > >>>>> - Is annotated @QueryHandler
> > >>>>
> > >>>> Ish, this should follow standard CDI resolution rules, you can copy
> > the
> > >>>> way interceptor bindings work here.
> > >>>>
> > >>>>> - Is annotated @ServiceHandler
> > >>>>
> > >>>> Yes
> > >>>>
> > >>>>>
> > >>>>> DeltaSpike will provide a proxied object where all abstract method
> > >>> calls
> > >>>>> are delegated to the InvocationHandler. The InvocationHandler will
> > >>> need
> > >>>> to
> > >>>>> have logic to handle all methods as defined within the class, as
> long
> > >>> as
> > >>>>> that method is invoked through the InvocationHandler.
> > >>>>>
> > >>>>> @QueryHandler @ServiceHandler
> > >>>>> public QueryHandlerInvoker implements InvocationHandler {
> > >>>>>
> > >>>>> public Object invoke(Object proxy, Method method, Object[] args) {
> > >>>>> if(method.getName().startsWith("find..."){
> > >>>>> //...
> > >>>>> }
> > >>>>> return null;
> > >>>>>
> > >>>>> }
> > >>>>> }
> > >>>>>
> > >>>>> In addition, the ServiceHandlerBinding can be placed on an abstract
> > >>>> class.
> > >>>>> In this case, only abstract methods will be passed to the
> > >>>>> InvocationHandler.
> > >>>>>
> > >>>>> @QueryHandler
> > >>>>> public abstract interface PersonDAO {
> > >>>>> public String doSomethingConcrete() {
> > >>>>> return "concrete";
> > >>>>> }
> > >>>>>
> > >>>>> public abstract Person find(int id);
> > >>>>> }
> > >>>>>
> > >>>>> Only the find method will be wrapped, the method
> doSomethingConcrete
> > >>> will
> > >>>>> be invoked directly. When interacting with an abstract class, the
> > >>>>> InvocationHandler can call methods on the proxied object.
> > >>>>>
> > >>>>> Finally, the app developer will be able to simply inject their
> > >>>>> interface/abstract class in to their beans to perform work:
> > >>>>>
> > >>>>> @Inject @QueryHandler PersonDAO dao;
> > >>>>>
> > >>>>> Questions:
> > >>>>>
> > >>>>> Should we provide a store (simple key/value map) to keep a history
> of
> > >>>> found
> > >>>>> object types and how they map?
> > >>>>
> > >>>> You mean like BeanManager.resolveInterceptors() ? I guess this is
> > >> useful.
> > >>>>
> > >>>>> Should we depend on certain libraries for proxying (e.g.
> javassist, I
> > >>>> think
> > >>>>> both Weld & OWB use this still?)
> > >>>>
> > >>>> If you want to just cover interfaces, it's easy, you can use
> proxying
> > >>> from
> > >>>> the JDK. Otherwise yes you need to pick a lib.
> > >>>>
> > >>>> Weld doesn't use javassist for proxying, but does for other stuff.
> > >>>>
> > >>>>> Since we now use the interface InvocationHandler should we rename
> the
> > >>>>> binding to be InvocationHandlerBinding?
> > >>>>
> > >>>> Yes, this makes sense
> > >>>>
> > >>>>> I also think it's not necessary to
> > >>>>> have @ServiceHandler since the marker interface now exists.
> > >>>>
> > >>>> +1
> > >>>>
> > >>>>>
> > >>>>> Comments welcome..
> > >>>>>
> > >>>>> John
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> > >>> <lightguard.jp@gmail.com
> > >>>>> wrote:
> > >>>>>
> > >>>>>> +1 for @ServiceHandler
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> > >>> <john.d.ament@gmail.com
> > >>>>>>> wrote:
> > >>>>>>
> > >>>>>>> If we're still calling the feature
> > >>> "ServiceHandler" then why not
> > >>>>>>> @ServiceHandler?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> > >>>>>>> <rm...@gmail.com>wrote:
> > >>>>>>>
> > >>>>>>>> if we don't need it perfect, if we need it we'll
> > >>> just use another name
> > >>>>>>>> @DSHandler, @Handler...whatever it is ;)
> > >>>>>>>>
> > >>>>>>>> Romain Manni-Bucau
> > >>>>>>>> Twitter: @rmannibucau
> > >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> > >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>>>>>> Github: https://github.com/rmannibucau
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> > >>>>>>>>> :-) Yes for sure. I suspect we dont' need
> > >>> @InvocationHandler at all.
> > >>>>>>>>>
> > >>>>>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > >>>>>>>>>
> > >>>>>>>>>> The problem I have is that now InvocationHandler
> > >>> is both an
> > >>>>>> interface
> > >>>>>>>> and
> > >>>>>>>>>> an @interface which will make it impossible for
> > >>> imports. I don't
> > >>>>>>> think
> > >>>>>>>>>> they should have the same name.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> > >>> <pm...@redhat.com>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> All,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> So mostly ok from my perspective. One
> > >>> thing to note:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> @InvocationHandlerBinding
> > >>>>>>>>>>>> public @interface Repository {}
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> @Repository
> > >>>>>>>>>>>> public interface MyRepository {
> > >>>>>>>>>>>> ...
> > >>>>>>>>>>>> }
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> @Repository @InvocationHandler
> > >>>>>>>>>>>> public class MyInvocationHandler
> > >>> implements InvocationHandler {
> > >>>>>>>>>>>> ...
> > >>>>>>>>>>>> }
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Why do we have a @InvocationHandler here?
> > >>> Is it supposed to be
> > >>>>>>>>>>>> @InvocationHandlerBinding instead? If so,
> > >>> is it really needed
> > >>>>>> here?
> > >>>>>>>>>>>
> > >>>>>>>>>>> No, it should be @InvocationHandler, it's
> > >>> analagous to
> > >>>>>> @Interceptor.
> > >>>>>>>> It's
> > >>>>>>>>>>> not 100% necessary as we already implement the
> > >>> interface, which is
> > >>>>>>>> enough
> > >>>>>>>>>>> of the marker.
> > >>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thinking about the implementation for
> > >>> this, I think this actually
> > >>>>>>>> becomes
> > >>>>>>>>>>>> easier to use and easier to understand
> > >>> over the Solder solution.
> > >>>>>>> The
> > >>>>>>>>>>>> implementation of the InvocationHandler
> > >>> becomes a true CDI bean.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Should DS support Interceptors and
> > >>> Decorators on
> > >>>>>>>>>>>> InvocationHandler beans?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Do you mean the implementation class or
> > >>> the interface?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> John
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> > >>> Manni-Bucau
> > >>>>>>>>>>>> <rm...@gmail.com>wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> i'd rather say no because the idea
> > >>> is to ease "util" extension
> > >>>>>>>>>>>>> writing. that's clearly not
> > >>> intended to be full business beans
> > >>>>>> IMO
> > >>>>>>>> (at
> > >>>>>>>>>>>>> least for a first step)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> That's why i'd leave it as
> > >>> this for now
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> wdyt?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Romain Manni-Bucau
> > >>>>>>>>>>>>> Twitter: @rmannibucau
> > >>>>>>>>>>>>> Blog:
> > >>> http://rmannibucau.wordpress.com/
> > >>>>>>>>>>>>> LinkedIn:
> > >>> http://fr.linkedin.com/in/rmannibucau
> > >>>>>>>>>>>>> Github: https://github.com/rmannibucau
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2012/12/20 Arne Limburg
> > >>> <ar...@openknowledge.de>:
> > >>>>>>>>>>>>>> Mark refers to my call stack.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Out of the box this call stack
> > >>> would exist just in OWB, because
> > >>>>>>> Weld
> > >>>>>>>>>>>>> would
> > >>>>>>>>>>>>>> not apply any Interceptors or
> > >>> Decorators...
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> The question is: Should DS support
> > >>> Interceptors and Decorators
> > >>>>>> on
> > >>>>>>>>>>>>>> InvocationHandler beans? My answer
> > >>> would be: yes, if our
> > >>>>>>>> implementation
> > >>>>>>>>>>>>>> shall be a preview of CDI-110.
> > >>>>>>>>>>>>>> And that would make things
> > >>> complicated in the implementation...
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Am 20.12.12 12:11 schrieb
> > >>> "Romain Manni-Bucau" unter
> > >>>>>>>>>>>>>> <rm...@gmail.com>:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> is it an issue for
> > >>> servicehandler? i don't think so
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> it is often used to get util
> > >>> classes dynamically created, it is
> > >>>>>>>> rarely
> > >>>>>>>>>>>>>>> (i never saw it) decorated
> > >>> directly
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Romain Manni-Bucau
> > >>>>>>>>>>>>>>> Twitter: @rmannibucau
> > >>>>>>>>>>>>>>> Blog:
> > >>> http://rmannibucau.wordpress.com/
> > >>>>>>>>>>>>>>> LinkedIn:
> > >>> http://fr.linkedin.com/in/rmannibucau
> > >>>>>>>>>>>>>>> Github:
> > >>> https://github.com/rmannibucau
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2012/12/20 Mark Struberg
> > >>> <st...@yahoo.de>:
> > >>>>>>>>>>>>>>>> we stumbled about this
> > >>> lately. It seems CDI only forces
> > >>>>>> support
> > >>>>>>>> for
> > >>>>>>>>>>>>>>>> interceptors and
> > >>> decorators for CDI-annotated classes, but not
> > >>>>>>> for
> > >>>>>>>>>>>>>>>> Bean<T> which get
> > >>> added via extensions nor even producer
> > >>>>>> methods
> > >>>>>>>> and
> > >>>>>>>>>>>>>>>> fields :/
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Of course OWB does it, but
> > >>> it would be not portable...
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> LieGrue,
> > >>>>>>>>>>>>>>>> strub
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> ----- Original Message
> > >>> -----
> > >>>>>>>>>>>>>>>>> From: Arne Limburg
> > >>> <ar...@openknowledge.de>
> > >>>>>>>>>>>>>>>>> To:
> > >>> "deltaspike-dev@incubator.apache.org"
> > >>>>>>>>>>>>>>>>>
> > >>> <de...@incubator.apache.org>
> > >>>>>>>>>>>>>>>>> Cc:
> > >>>>>>>>>>>>>>>>> Sent: Thursday,
> > >>> December 20, 2012 10:18 AM
> > >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > >>> [DELTASPIKE-113] Review and Discuss
> > >>>>>>>>>>>>>>>>> ServiceHandler
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> T wo things about
> > >>> this: First: I don't like from the solder
> > >>>>>>>>>>> approach,
> > >>>>>>>>>>>>>>>>> because the interface
> > >>> is annotated instead of the
> > >>>>>>> implementation.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Second, if we
> > >>> implement this we should conceptually make
> > >>>>>> clear
> > >>>>>>>> how
> > >>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>> differentiates from
> > >>> Interceptors and Decorators. And
> > >>>>>>> personally I
> > >>>>>>>>>>>>> think
> > >>>>>>>>>>>>>>>>> this would work better
> > >>> with the InvocationHandler approach
> > >>>>>> than
> > >>>>>>>> with
> > >>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>> approach that is very
> > >>> similar to interceptors.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> So +1 for an approach
> > >>> like this:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>> @HandlesInvocationsOn(MyInterface.class)
> > >>>>>>>>>>>>>>>>> public class
> > >>> MyInvocationHandler implements
> > >>>>>> InvocationHandler {
> > >>>>>>>>>>>>>>>>> ...
> > >>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Technically we would
> > >>> register a custom Bean for every found
> > >>>>>>>>>>>>>>>>> InvocationHandler with
> > >>> that annotation and take over the
> > >>>>>>>>>>>>>>>>> interceptor-bindings
> > >>> from the interfaceŠ
> > >>>>>>>>>>>>>>>>> So the invocation
> > >>> stack would be clear, too:
> > >>>>>>>>>>>>>>>>> First Interceptors,
> > >>>>>>>>>>>>>>>>> Second Decorators,
> > >>>>>>>>>>>>>>>>> Third
> > >>> InvocationHandler
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Wdyt?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Arne
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Am 20.12.12 01:53
> > >>> schrieb "Romain Manni-Bucau" unter
> > >>>>>>>>>>>>>>>>>
> > >>> <rm...@gmail.com>:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> that's a need,
> > >>> DS targets CDI 1.0 for now so just make this
> > >>>>>>>> solder
> > >>>>>>>>>>>>>>>>>> part portable ans
> > >>> it should be fine
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Romain Manni-Bucau
> > >>>>>>>>>>>>>>>>>> Twitter:
> > >>> @rmannibucau
> > >>>>>>>>>>>>>>>>>> Blog:
> > >>> http://rmannibucau.wordpress.com/
> > >>>>>>>>>>>>>>>>>> LinkedIn:
> > >>> http://fr.linkedin.com/in/rmannibucau
> > >>>>>>>>>>>>>>>>>> Github:
> > >>> https://github.com/rmannibucau
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 2012/12/20 Jason
> > >>> Porter <li...@gmail.com>:
> > >>>>>>>>>>>>>>>>>>> At this point,
> > >>> I'd say just do it as is in solder.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Wed, Dec
> > >>> 19, 2012 at 5:25 PM, John D. Ament
> > >>>>>>>>>>>>>>>>>>>
> > >>> <jo...@gmail.com>wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Hi All,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Regarding
> > >>> the two open questions:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1) the
> > >>> approach (including the name/s) we agree on will be
> > >>>>>>>> used
> > >>>>>>>>>>>>>>>>> also
> > >>>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> cdi 1.1
> > >>> (the only difference is the package)
> > >>>>>>>>>>>>>>>>>>>> 2) the eg
> > >>> has a different opinion about it ->
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> It looks
> > >>> like the JSR's answer
> > >>>>>>>>>>>>>>>>>>>>
> > >>> (https://issues.jboss.org/browse/CDI-110 )
> > >>>>>>>>>>>>>>>>>>>> is still
> > >>> unresolved - I'm not sure if we can get any
> > >>>>>> further
> > >>>>>>>>>>>>>>>>> answer at
> > >>>>>>>>>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>>>>> time. The
> > >>> last posts on the subject seem to discuss using
> > >>>>>>>>>>>>>>>>> something
> > >>>>>>>>>>>>>>>>>>>> along
> > >>>>>>>>>>>>>>>>>>>> the lines
> > >>> of an invocation handler, which I think would
> > >>>>>> work
> > >>>>>>>>>>> well.
> > >>>>>>>>>>>>>>>>>>>> Since
> > >>>>>>>>>>>>>>>>>>>> we have
> > >>> some features coming up that are interested in
> > >>>>>>> having
> > >>>>>>>>>>>>>>>>> service
> > >>>>>>>>>>>>>>>>>>>> handlers
> > >>> available, do we
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1.
> > >>> Implement as is, or similar to, what is currently in
> > >>>>>>>> Solder?
> > >>>>>>>>>>>>>>>>>>>> 2. Push EG
> > >>> on a resolution
> > >>>>>>>>>>>>>>>>>>>> 3. Do it
> > >>> using invocation handlers.
> > >>>>>>>>>>>>>>>>>>>> 4. Do it
> > >>> some other way?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> John
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Wed,
> > >>> Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> > >>>>>>>>>>>>>>>>>>>>
> > >>> gerhard.petracek@gmail.com
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> hi
> > >>> john,
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> as
> > >>> mentioned before we need the answers to the existing
> > >>>>>>>>>>>>>>>>> questions.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/4/4 John D. Ament <jo...@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> All,
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I
> > >>> kind of let this one and the other drop off my radar,
> > >>>>>> I
> > >>>>>>>>>>>>>>>>>>>> apologize.
> > >>>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> looks like where we last left off, Gerhard was still
> > >>>>>>>>>>>>>>>>> requesting
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> additional
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> comments from everyone. Any other feedback?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> John
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On
> > >>> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard.petracek@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>> hi
> > >>> george,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>> thx
> > >>> for the information. i thought there might be at
> > >>>>>>>>>>>>>>>>> least some
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> additional
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> answers/clarifications, since pete asked for them in
> > >>>>>>>>>>>>>>>>> several
> > >>>>>>>>>>>>>>>>>>>> comments.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> -> imo we should continue with them.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/12 George Gastaldi
> > >>>>>>>>>>>>>>>>>
> > >>> <ge...@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> Hello Gerhard,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> Yeah, it´s the last state. I know it´s quite
> > >>>>>>>>>>>>>>>>> old, but I
> > >>>>>>>>>>>>>>>>>>>> haven´t
> > >>> had
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> time
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> to work on it after that.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> Regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> George
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/12 Gerhard Petracek
> > >>>>>>>>>>>>>>>>>
> > >>> <ge...@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> hi george,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> thx for the link.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> i'm not sure if it is the latest state
> > >>>>>>>>>>>>>>>>> of your discussion
> > >>>>>>>>>>>>>>>>>>>> and/or
> > >>>>>>>>>>>>>>>>>>>>> draft
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> (at least it's quite old already).
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/7 George Gastaldi
> > >>>>>>>>>>>>>>>>>
> > >>> <ge...@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Hi !
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> +1 to #1. I also agree that the term
> > >>>>>>>>>>>>>>>>> "Service
> > >>> Handler" might
> > >>>>>>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>>>> so
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> appropriate, so it should be discussed
> > >>>>>>>>>>>>>>>>> as well.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Here is the latest pull request with
> > >>>>>>>>>>>>>>>>> some comments from
> > >>> Pete
> > >>>>>>>>>>>>>>>>>>>> yet
> > >>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>> be
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> reviewed:
> > >>>>>>>>>>>>>>>>>
> > >>> https://github.com/jboss/cdi/pull/28
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/7 Pete Muir
> > >>>>>>>>>>>>>>>>>
> > >>> <pm...@redhat.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Agreed :-)
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> George is working on it for CDI
> > >>>>>>>>>>>>>>>>> 1.1. George, can you
> > >>> share
> > >>>>>>>>>>>>>>>>>>>> your
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> proposal
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> so far?
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On 7 Mar 2012, at 17:05, Gerhard
> > >>>>>>>>>>>>>>>>> Petracek wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> hi pete,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> independent of my opinion
> > >>>>>>>>>>>>>>>>> about the feature
> > >>> (which is
> > >>>>>>>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>>>>>> +0):
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> if it should be part of cdi
> > >>>>>>>>>>>>>>>>> 1.1, we have the
> > >>> following
> > >>>>>>>>>>>>>>>>>>>> options
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> imo:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 1) the approach (including
> > >>>>>>>>>>>>>>>>> the name/s) we agree
> > >>> on will
> > >>>>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>> used
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> also
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> for
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> cdi 1.1 (the only difference
> > >>>>>>>>>>>>>>>>> is the package)
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2) the eg has a different
> > >>>>>>>>>>>>>>>>> opinion about it ->
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2a) the rest of the eg joins
> > >>>>>>>>>>>>>>>>> this discussion
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2b) we wait for the final
> > >>>>>>>>>>>>>>>>> version and just allow
> > >>> the same
> > >>>>>>>>>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> cdi
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 1.0
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 3) if the eg doesn't
> > >>>>>>>>>>>>>>>>> agree on the idea, it
> > >>> should be
> > >>>>>>>>>>>>>>>>>>>> re-visited
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> for
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> deltaspike (if we really need
> > >>>>>>>>>>>>>>>>> it)
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 4) we agree on it independent
> > >>>>>>>>>>>>>>>>> of the result in cdi
> > >>> 1.1
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 1-3 is ok for me but -1 for
> > >>>>>>>>>>>>>>>>> #4
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/7 Pete Muir
> > >>>>>>>>>>>>>>>>>
> > >>> <pm...@redhat.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> I'm not sure what you
> > >>>>>>>>>>>>>>>>> mean by a "super
> > >>> interceptor",
> > >>>>>>>>>>>>>>>>>>>> but if
> > >>>>>>>>>>>>>>>>>>>>> you
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> mean it
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> as
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> in "super man"
> > >>>>>>>>>>>>>>>>> (something better than
> > >>> an interceptor),
> > >>>>>>>>>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>>>>>>> I
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> would
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> disagree, it's
> > >>>>>>>>>>>>>>>>> actually a specialised
> > >>> form of
> > >>>>>>>>>>>>>>>>>>>>
> > >>> interceptor.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> The best use case I know
> > >>>>>>>>>>>>>>>>> of is the one John
> > >>> mentions -
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> creating
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> type
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> safe
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> references to queries:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> @QueryService
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> interface UserQuery {
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> @Query("select u
> > >>>>>>>>>>>>>>>>> from User u")
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> public List<User>
> > >>>>>>>>>>>>>>>>> getAllUsers();
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> @Query("select u
> > >>>>>>>>>>>>>>>>> from User u order by
> > >>> u.name")
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> public List<User>
> > >>>>>>>>>>>>>>>>>
> > >>> getAllUsersSortedByName();
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> }
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Now, it may be the case
> > >>>>>>>>>>>>>>>>> that there aren't
> > >>> any other use
> > >>>>>>>>>>>>>>>>>>>> cases
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> for
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> service
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> handlers, in which case
> > >>>>>>>>>>>>>>>>> we should perhaps just
> > >>> offer
> > >>>>>>>>>>>>>>>>>>>> this
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> particular
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> service handler -
> > >>>>>>>>>>>>>>>>> references to type
> > >>> safe queries - as I
> > >>>>>>>>>>>>>>>>>>>> think
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> this
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> is
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> an
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> extremely powerful idea.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Note, that at the moment
> > >>>>>>>>>>>>>>>>> service handlers are
> > >>> scheduled
> > >>>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>> CDI
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> 1.1.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On 7 Mar 2012, at 02:35,
> > >>>>>>>>>>>>>>>>> Jason Porter wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Somewhat. I
> > >>>>>>>>>>>>>>>>> wouldn't really
> > >>> think of them as overrides,
> > >>>>>>>>>>>>>>>>>>>> they,
> > >>>>>>>>>>>>>>>>>>>>>> to
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> me,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> seem more like items to
> > >>>>>>>>>>>>>>>>> do in addition to
> > >>> whatever the
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> original
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> impl
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> does.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> ServiceHandlers to me
> > >>>>>>>>>>>>>>>>> seem more like super
> > >>>>>>>>>>>>>>>>>>>>
> > >>> interceptors.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Sent from my iPhone
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On Mar 6, 2012, at
> > >>>>>>>>>>>>>>>>> 19:23, "John D.
> > >>> Ament" <
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> john.d.ament@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> @jason
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> I think the
> > >>>>>>>>>>>>>>>>> concepts are very
> > >>> dissimilar.
> > >>>>>>>>>>>>>>>>>>>>
> > >>> servicehandlers
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> create
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> implementation.
> > >>>>>>>>>>>>>>>>> delegates are more
> > >>> like overrides and
> > >>>>>>>>>>>>>>>>>>>> need
> > >>>>>>>>>>>>>>>>>>>>> to
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> know
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> about
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the method
> > >>>>>>>>>>>>>>>>> signature.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On Tue, Mar 6,
> > >>>>>>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> > >>> Porter <
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> lightguard.jp@gmail.com
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> I think the
> > >>>>>>>>>>>>>>>>> idea of
> > >>> ServiceHandlers are good, but,
> > >>>>>>>>>>>>>>>>>>>> could
> > >>>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> not
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> do
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> this
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> with
> > >>>>>>>>>>>>>>>>> delegates?
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Sent from my
> > >>>>>>>>>>>>>>>>> iPhone
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On Mar 6,
> > >>>>>>>>>>>>>>>>> 2012, at 19:05,
> > >>> "John D. Ament" <
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> john.d.ament@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> @mark
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> I
> > >>>>>>>>>>>>>>>>> don't think
> > >>> it's a hard requirement for it to be
> > >>>>>>>>>>>>>>>>>>>> on an
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> interface.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> One of
> > >>>>>>>>>>>>>>>>> the best use-cases we
> > >>> built at my job is
> > >>>>>>>>>>>>>>>>>>>> using it
> > >>>>>>>>>>>>>>>>>>>>> for
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> calling
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> PL/SQL.
> > >>>>>>>>>>>>>>>>> The JDBC bindings do
> > >>> work, but not pretty.
> > >>>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>> were
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> able to
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> create
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> a fairly
> > >>>>>>>>>>>>>>>>> clean wrapper API,
> > >>> generic enough for
> > >>>>>>>>>>>>>>>>>>>> binding
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> in/out
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> parameters.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> JOhn
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On Tue,
> > >>>>>>>>>>>>>>>>> Mar 6, 2012 at 12:58
> > >>> PM, Mark Struberg <
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> struberg@yahoo.de>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> actually I don't
> > >>> really see a real benefit. I just
> > >>>>>>>>>>>>>>>>>>>> don't
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> yet
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> grok
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> use
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> case
> > >>>>>>>>>>>>>>>>> for real world
> > >>> projects.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Why
> > >>>>>>>>>>>>>>>>> would one intercept an
> > >>> Interface and delegate
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>> calls
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>> to
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> a
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> method
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> handler?
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> This
> > >>>>>>>>>>>>>>>>> could be neat for
> > >>> mocking, but there are
> > >>>>>>>>>>>>>>>>>>>> better
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> frameworks for
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> that.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> thus
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> -0.2
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> LieGrue,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> strub
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> -----
> > >>>>>>>>>>>>>>>>> Original Message -----
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> From: Gerhard Petracek
> > >>>>>>>>>>>>>>>>>>>>
> > >>> <ge...@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> To:
> > >>> deltaspike-dev@incubator.apache.org
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Cc:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Sent: Tuesday, March
> > >>> 6, 2012 5:15 PM
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > >>> [DELTASPIKE-113] Review and
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> Discuss
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> ServiceHandler
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> if you have a lot of
> > >>> shared code, you can extract
> > >>>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> 1-n
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> method/s or
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> an
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> abstract class which
> > >>> is still easier than a new
> > >>>>>>>>>>>>>>>>>>>> concept.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> at least i haven't
> > >>> seen an use-case which really
> > >>>>>>>>>>>>>>>>>>>> needed
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> it.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> that
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> was
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> reason for a +0 (which
> > >>> still means that i'm ok
> > >>>>>>>>>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>>>>>>>> adding
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> it).
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> > >>> <pm...@redhat.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> So, you mean just write a bean with all the
> > >>>>>>>>>>>>>>>>>>>>
> > >>> boilerplate
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> code
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> in
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> it?
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> hi pete,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> instead of the interface you can just
> > >>>>>>>>>>>>>>>>> implement
> > >>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>> bean
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> which
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> does
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> same.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/6 Pete Muir
> > >>>>>>>>>>>>>>>>>
> > >>> <pm...@redhat.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> What CDI mechanism would you use
> > >>>>>>>>>>>>>>>>> instead?
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> On 5 Mar 2012, at 08:47, Gerhard
> > >>>>>>>>>>>>>>>>> Petracek
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> +0
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> no -1 because there are
> > >>>>>>>>>>>>>>>>> use-cases for it.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> no +1 because i would use std.
> > >>>>>>>>>>>>>>>>> cdi mechanisms
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> instead.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/4 Gerhard Petracek <
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard.petracek@gmail.com
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> hi john,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the sub-task is perfectly
> > >>>>>>>>>>>>>>>>> fine.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> gerhard
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> 2012/3/4 John D. Ament
> > >>>>>>>>>>>>>>>>>>>>
> > >>> <jo...@gmail.com>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Hi All
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> I wanted to bring up
> > >>>>>>>>>>>>>>>>> the subject of
> > >>>>>>>>>>>>>>>>>>>>>
> > >>> ServiceHandler.
> > >>>>>>>>>>>>>>>>>>>>>> I
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> added 113 as a
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> child
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> of DELTASPIKE-2, looked
> > >>>>>>>>>>>>>>>>> appropriate but not
> > >>>>>>>>>>>>>>>>>>>> 100%
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> sure
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> (so please let
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> me
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> know if you think
> > >>>>>>>>>>>>>>>>> it's not
> > >>> appropriate as a
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> child).
> > >>> ServiceHandler
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> is
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> a
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> feature in Solder that
> > >>>>>>>>>>>>>>>>> allows you to define
> > >>>>>>>>>>>>>>>>>>>> an
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> interceptor that
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> manages
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> generic calls against
> > >>>>>>>>>>>>>>>>> an injected interface.
> > >>>>>>>>>>>>>>>>>>>> The
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> API
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> is as follows:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> -
> > >>>>>>>>>>>>>>>>>
> > >>> @ServiceHandlerType(Class<?> clazz) -
> > >>>>>>>>>>>>>>>>>>>> placed
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> on an annotation that
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> would
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> be placed on the
> > >>>>>>>>>>>>>>>>> interface. Indicates
> > >>> what
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> interceptor would be
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> invoked
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> for calls against this
> > >>>>>>>>>>>>>>>>> interface.
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> It's then up to the
> > >>>>>>>>>>>>>>>>> application
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> developer/framework
> > >>> author to define
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> annotations that go on
> > >>>>>>>>>>>>>>>>> methods, as well as
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> interceptor itself
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> that
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> will
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> be invoked. The
> > >>>>>>>>>>>>>>>>> feature for
> > >>> ServiceHandler
> > >>>>>>>>>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>>>>>>> be
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> to provide the
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> API of
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> the type and then the
> > >>>>>>>>>>>>>>>>> infrastructure
> > >>>>>>>>>>>>>>>>>>>> required
> > >>> to
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>> make
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> the interceptor
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> be
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> called. Existing
> > >>>>>>>>>>>>>>>>> documentation of the
> > >>>>>>>>>>>>>>>>>>>> feature:
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>
> > >>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> > >>>>>>>>>>>>>>>>>>>> ser
> > >>>>>>>>>>>>>>>>>>>>
> > >>> vicehandler.html
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> Regards,
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>> john
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>> Jason Porter
> > >>>>>>>>>>>>>>>>>>>
> > >>> http://lightguard-jp.blogspot.com
> > >>>>>>>>>>>>>>>>>>>
> > >>> http://twitter.com/lightguardjp
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Software
> > >>> Engineer
> > >>>>>>>>>>>>>>>>>>> Open Source
> > >>> Advocate
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> PGP key id:
> > >>> 926CCFF5
> > >>>>>>>>>>>>>>>>>>> PGP key
> > >>> available at: keyserver.net, pgp.mit.edu
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Jason Porter
> > >>>>>> http://lightguard-jp.blogspot.com
> > >>>>>> http://twitter.com/lightguardjp
> > >>>>>>
> > >>>>>> Software Engineer
> > >>>>>> Open Source Advocate
> > >>>>>>
> > >>>>>> PGP key id: 926CCFF5
> > >>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Pete,
What do you expect the "normal" way to be? I figured qualifiers made more
sense since a lot of the CDI functionality is based on qualifiers (though I
think a lot of applications mostly use a single type of an interface or
leverage alternatives).
On Mon, Dec 24, 2012 at 8:47 AM, Pete Muir <pm...@redhat.com> wrote:
> I think it should work, adding a qualifier, but I don't think it's the
> "normal" way to do it.
>
> On 23 Dec 2012, at 16:12, John D. Ament wrote:
>
> > Well, this object is used for a specific case. In my opinion, you should
> be
> > able to resolve it using
> >
> > @Inject @QueryHandler
> > private InvocationHandler queryHandler;
> >
> > Though why you may want to inject it in a client app is unknown to me; it
> > does make it easier from an implementation standpoint.
> >
> > Does the service handler need to have any specific scope? Can it inherit
> > the scope of what it's handling? I guess not, since it could be a handler
> > to n things. NormalScope would be appropriate then.
> >
> >
> > On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >> I guess because it might overlap with other qualifiers added in some
> cases.
> >>
> >> What do we gain for making it a qualifier?
> >>
> >> Another important difference to CDI interceptors is that they are always
> >> @Dependent to the intercepted instance.
> >> Whereas the ServiceHandler should be of NormalScope, isn't?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: John D. Ament <jo...@gmail.com>
> >>> To: deltaspike-dev@incubator.apache.org
> >>> Cc:
> >>> Sent: Saturday, December 22, 2012 7:56 PM
> >>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> ServiceHandler
> >>>
> >>> Pete,
> >>>
> >>> Regarding interceptors - I think what I have is pretty close to the
> >>> interceptor definition, except this should only end up working on a
> >>> class/interface (I think?)
> >>>
> >>> Also, why wouldn't we want the annotation to also be a qualifier?
> >>>
> >>> John
> >>>
> >>>
> >>> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
> >>>
> >>>>
> >>>> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> So just to summarize the current proposal:
> >>>>>
> >>>>> - Create a new annotation @ServiceHandlerBinding (in core/api) which
> >>> will
> >>>>> be placed on on the interface that defines points of the
> >>>>> - Create a new annotation @ServiceHandler (in core/api) (I think
> >> based
> >>> on
> >>>>> below this isn't needed since we have the interface now).
> >>>>> - Create an extension that can generate object proxies that link
> >> calls
> >>> to
> >>>>> methods on the - org.apache.deltaspike.core.api....
> >>>>>
> >>>>> Define the binding type annotation:
> >>>>>
> >>>>> @ServiceHandlerBinding
> >>>>> @Qualifier
> >>>>> public @interface QueryHandler {
> >>>>> }
> >>>>
> >>>> I don't think we want @Qualifier here.
> >>>>
> >>>>>
> >>>>> which will define the relationship between the interface/abstract
> >>> class
> >>>>> that will use the service handler and the class that will serve as
> >> the
> >>>>> invocation handler.
> >>>>>
> >>>>> For example, we can use @QueryHandler on an interface:
> >>>>>
> >>>>> @QueryHandler
> >>>>> public interface PersonDAO {
> >>>>> //...
> >>>>> }
> >>>>>
> >>>>> When the container finds this interface it will identify the
> >>> appropriate
> >>>>> InvocationHandler, based on the following matches:
> >>>>>
> >>>>> - Implements InvocationHandler
> >>>>
> >>>> Yes.
> >>>>
> >>>>> - Is annotated @QueryHandler
> >>>>
> >>>> Ish, this should follow standard CDI resolution rules, you can copy
> the
> >>>> way interceptor bindings work here.
> >>>>
> >>>>> - Is annotated @ServiceHandler
> >>>>
> >>>> Yes
> >>>>
> >>>>>
> >>>>> DeltaSpike will provide a proxied object where all abstract method
> >>> calls
> >>>>> are delegated to the InvocationHandler. The InvocationHandler will
> >>> need
> >>>> to
> >>>>> have logic to handle all methods as defined within the class, as long
> >>> as
> >>>>> that method is invoked through the InvocationHandler.
> >>>>>
> >>>>> @QueryHandler @ServiceHandler
> >>>>> public QueryHandlerInvoker implements InvocationHandler {
> >>>>>
> >>>>> public Object invoke(Object proxy, Method method, Object[] args) {
> >>>>> if(method.getName().startsWith("find..."){
> >>>>> //...
> >>>>> }
> >>>>> return null;
> >>>>>
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> In addition, the ServiceHandlerBinding can be placed on an abstract
> >>>> class.
> >>>>> In this case, only abstract methods will be passed to the
> >>>>> InvocationHandler.
> >>>>>
> >>>>> @QueryHandler
> >>>>> public abstract interface PersonDAO {
> >>>>> public String doSomethingConcrete() {
> >>>>> return "concrete";
> >>>>> }
> >>>>>
> >>>>> public abstract Person find(int id);
> >>>>> }
> >>>>>
> >>>>> Only the find method will be wrapped, the method doSomethingConcrete
> >>> will
> >>>>> be invoked directly. When interacting with an abstract class, the
> >>>>> InvocationHandler can call methods on the proxied object.
> >>>>>
> >>>>> Finally, the app developer will be able to simply inject their
> >>>>> interface/abstract class in to their beans to perform work:
> >>>>>
> >>>>> @Inject @QueryHandler PersonDAO dao;
> >>>>>
> >>>>> Questions:
> >>>>>
> >>>>> Should we provide a store (simple key/value map) to keep a history of
> >>>> found
> >>>>> object types and how they map?
> >>>>
> >>>> You mean like BeanManager.resolveInterceptors() ? I guess this is
> >> useful.
> >>>>
> >>>>> Should we depend on certain libraries for proxying (e.g. javassist, I
> >>>> think
> >>>>> both Weld & OWB use this still?)
> >>>>
> >>>> If you want to just cover interfaces, it's easy, you can use proxying
> >>> from
> >>>> the JDK. Otherwise yes you need to pick a lib.
> >>>>
> >>>> Weld doesn't use javassist for proxying, but does for other stuff.
> >>>>
> >>>>> Since we now use the interface InvocationHandler should we rename the
> >>>>> binding to be InvocationHandlerBinding?
> >>>>
> >>>> Yes, this makes sense
> >>>>
> >>>>> I also think it's not necessary to
> >>>>> have @ServiceHandler since the marker interface now exists.
> >>>>
> >>>> +1
> >>>>
> >>>>>
> >>>>> Comments welcome..
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> >>> <lightguard.jp@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> +1 for @ServiceHandler
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> >>> <john.d.ament@gmail.com
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> If we're still calling the feature
> >>> "ServiceHandler" then why not
> >>>>>>> @ServiceHandler?
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> >>>>>>> <rm...@gmail.com>wrote:
> >>>>>>>
> >>>>>>>> if we don't need it perfect, if we need it we'll
> >>> just use another name
> >>>>>>>> @DSHandler, @Handler...whatever it is ;)
> >>>>>>>>
> >>>>>>>> Romain Manni-Bucau
> >>>>>>>> Twitter: @rmannibucau
> >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> >>>>>>>>> :-) Yes for sure. I suspect we dont' need
> >>> @InvocationHandler at all.
> >>>>>>>>>
> >>>>>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> >>>>>>>>>
> >>>>>>>>>> The problem I have is that now InvocationHandler
> >>> is both an
> >>>>>> interface
> >>>>>>>> and
> >>>>>>>>>> an @interface which will make it impossible for
> >>> imports. I don't
> >>>>>>> think
> >>>>>>>>>> they should have the same name.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> >>> <pm...@redhat.com>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> All,
> >>>>>>>>>>>>
> >>>>>>>>>>>> So mostly ok from my perspective. One
> >>> thing to note:
> >>>>>>>>>>>>
> >>>>>>>>>>>> @InvocationHandlerBinding
> >>>>>>>>>>>> public @interface Repository {}
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Repository
> >>>>>>>>>>>> public interface MyRepository {
> >>>>>>>>>>>> ...
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Repository @InvocationHandler
> >>>>>>>>>>>> public class MyInvocationHandler
> >>> implements InvocationHandler {
> >>>>>>>>>>>> ...
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why do we have a @InvocationHandler here?
> >>> Is it supposed to be
> >>>>>>>>>>>> @InvocationHandlerBinding instead? If so,
> >>> is it really needed
> >>>>>> here?
> >>>>>>>>>>>
> >>>>>>>>>>> No, it should be @InvocationHandler, it's
> >>> analagous to
> >>>>>> @Interceptor.
> >>>>>>>> It's
> >>>>>>>>>>> not 100% necessary as we already implement the
> >>> interface, which is
> >>>>>>>> enough
> >>>>>>>>>>> of the marker.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thinking about the implementation for
> >>> this, I think this actually
> >>>>>>>> becomes
> >>>>>>>>>>>> easier to use and easier to understand
> >>> over the Solder solution.
> >>>>>>> The
> >>>>>>>>>>>> implementation of the InvocationHandler
> >>> becomes a true CDI bean.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Should DS support Interceptors and
> >>> Decorators on
> >>>>>>>>>>>> InvocationHandler beans?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Do you mean the implementation class or
> >>> the interface?
> >>>>>>>>>>>>
> >>>>>>>>>>>> John
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> >>> Manni-Bucau
> >>>>>>>>>>>> <rm...@gmail.com>wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> i'd rather say no because the idea
> >>> is to ease "util" extension
> >>>>>>>>>>>>> writing. that's clearly not
> >>> intended to be full business beans
> >>>>>> IMO
> >>>>>>>> (at
> >>>>>>>>>>>>> least for a first step)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That's why i'd leave it as
> >>> this for now
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> wdyt?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>>>>> Blog:
> >>> http://rmannibucau.wordpress.com/
> >>>>>>>>>>>>> LinkedIn:
> >>> http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/12/20 Arne Limburg
> >>> <ar...@openknowledge.de>:
> >>>>>>>>>>>>>> Mark refers to my call stack.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Out of the box this call stack
> >>> would exist just in OWB, because
> >>>>>>> Weld
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>> not apply any Interceptors or
> >>> Decorators...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The question is: Should DS support
> >>> Interceptors and Decorators
> >>>>>> on
> >>>>>>>>>>>>>> InvocationHandler beans? My answer
> >>> would be: yes, if our
> >>>>>>>> implementation
> >>>>>>>>>>>>>> shall be a preview of CDI-110.
> >>>>>>>>>>>>>> And that would make things
> >>> complicated in the implementation...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Am 20.12.12 12:11 schrieb
> >>> "Romain Manni-Bucau" unter
> >>>>>>>>>>>>>> <rm...@gmail.com>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> is it an issue for
> >>> servicehandler? i don't think so
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> it is often used to get util
> >>> classes dynamically created, it is
> >>>>>>>> rarely
> >>>>>>>>>>>>>>> (i never saw it) decorated
> >>> directly
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>>>>>>> Blog:
> >>> http://rmannibucau.wordpress.com/
> >>>>>>>>>>>>>>> LinkedIn:
> >>> http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>>>>>>> Github:
> >>> https://github.com/rmannibucau
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2012/12/20 Mark Struberg
> >>> <st...@yahoo.de>:
> >>>>>>>>>>>>>>>> we stumbled about this
> >>> lately. It seems CDI only forces
> >>>>>> support
> >>>>>>>> for
> >>>>>>>>>>>>>>>> interceptors and
> >>> decorators for CDI-annotated classes, but not
> >>>>>>> for
> >>>>>>>>>>>>>>>> Bean<T> which get
> >>> added via extensions nor even producer
> >>>>>> methods
> >>>>>>>> and
> >>>>>>>>>>>>>>>> fields :/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Of course OWB does it, but
> >>> it would be not portable...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ----- Original Message
> >>> -----
> >>>>>>>>>>>>>>>>> From: Arne Limburg
> >>> <ar...@openknowledge.de>
> >>>>>>>>>>>>>>>>> To:
> >>> "deltaspike-dev@incubator.apache.org"
> >>>>>>>>>>>>>>>>>
> >>> <de...@incubator.apache.org>
> >>>>>>>>>>>>>>>>> Cc:
> >>>>>>>>>>>>>>>>> Sent: Thursday,
> >>> December 20, 2012 10:18 AM
> >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> >>> [DELTASPIKE-113] Review and Discuss
> >>>>>>>>>>>>>>>>> ServiceHandler
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> T wo things about
> >>> this: First: I don't like from the solder
> >>>>>>>>>>> approach,
> >>>>>>>>>>>>>>>>> because the interface
> >>> is annotated instead of the
> >>>>>>> implementation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Second, if we
> >>> implement this we should conceptually make
> >>>>>> clear
> >>>>>>>> how
> >>>>>>>>>>> it
> >>>>>>>>>>>>>>>>> differentiates from
> >>> Interceptors and Decorators. And
> >>>>>>> personally I
> >>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>> this would work better
> >>> with the InvocationHandler approach
> >>>>>> than
> >>>>>>>> with
> >>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>> approach that is very
> >>> similar to interceptors.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So +1 for an approach
> >>> like this:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>> @HandlesInvocationsOn(MyInterface.class)
> >>>>>>>>>>>>>>>>> public class
> >>> MyInvocationHandler implements
> >>>>>> InvocationHandler {
> >>>>>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Technically we would
> >>> register a custom Bean for every found
> >>>>>>>>>>>>>>>>> InvocationHandler with
> >>> that annotation and take over the
> >>>>>>>>>>>>>>>>> interceptor-bindings
> >>> from the interfaceŠ
> >>>>>>>>>>>>>>>>> So the invocation
> >>> stack would be clear, too:
> >>>>>>>>>>>>>>>>> First Interceptors,
> >>>>>>>>>>>>>>>>> Second Decorators,
> >>>>>>>>>>>>>>>>> Third
> >>> InvocationHandler
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Wdyt?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Arne
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Am 20.12.12 01:53
> >>> schrieb "Romain Manni-Bucau" unter
> >>>>>>>>>>>>>>>>>
> >>> <rm...@gmail.com>:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> that's a need,
> >>> DS targets CDI 1.0 for now so just make this
> >>>>>>>> solder
> >>>>>>>>>>>>>>>>>> part portable ans
> >>> it should be fine
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>>>>>>> Twitter:
> >>> @rmannibucau
> >>>>>>>>>>>>>>>>>> Blog:
> >>> http://rmannibucau.wordpress.com/
> >>>>>>>>>>>>>>>>>> LinkedIn:
> >>> http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>>>>>>>>>> Github:
> >>> https://github.com/rmannibucau
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2012/12/20 Jason
> >>> Porter <li...@gmail.com>:
> >>>>>>>>>>>>>>>>>>> At this point,
> >>> I'd say just do it as is in solder.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Wed, Dec
> >>> 19, 2012 at 5:25 PM, John D. Ament
> >>>>>>>>>>>>>>>>>>>
> >>> <jo...@gmail.com>wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Regarding
> >>> the two open questions:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1) the
> >>> approach (including the name/s) we agree on will be
> >>>>>>>> used
> >>>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> cdi 1.1
> >>> (the only difference is the package)
> >>>>>>>>>>>>>>>>>>>> 2) the eg
> >>> has a different opinion about it ->
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It looks
> >>> like the JSR's answer
> >>>>>>>>>>>>>>>>>>>>
> >>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>>>>>>>>>>>>>>> is still
> >>> unresolved - I'm not sure if we can get any
> >>>>>> further
> >>>>>>>>>>>>>>>>> answer at
> >>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>> time. The
> >>> last posts on the subject seem to discuss using
> >>>>>>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>>>>>> along
> >>>>>>>>>>>>>>>>>>>> the lines
> >>> of an invocation handler, which I think would
> >>>>>> work
> >>>>>>>>>>> well.
> >>>>>>>>>>>>>>>>>>>> Since
> >>>>>>>>>>>>>>>>>>>> we have
> >>> some features coming up that are interested in
> >>>>>>> having
> >>>>>>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>>>>>> handlers
> >>> available, do we
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1.
> >>> Implement as is, or similar to, what is currently in
> >>>>>>>> Solder?
> >>>>>>>>>>>>>>>>>>>> 2. Push EG
> >>> on a resolution
> >>>>>>>>>>>>>>>>>>>> 3. Do it
> >>> using invocation handlers.
> >>>>>>>>>>>>>>>>>>>> 4. Do it
> >>> some other way?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> John
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Wed,
> >>> Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>>>>>>>>>>>>>>>
> >>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> hi
> >>> john,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> as
> >>> mentioned before we need the answers to the existing
> >>>>>>>>>>>>>>>>> questions.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>> 2012/4/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> All,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I
> >>> kind of let this one and the other drop off my radar,
> >>>>>> I
> >>>>>>>>>>>>>>>>>>>> apologize.
> >>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>
> >>> looks like where we last left off, Gerhard was still
> >>>>>>>>>>>>>>>>> requesting
> >>>>>>>>>>>>>>>>>>>>>
> >>> additional
> >>>>>>>>>>>>>>>>>>>>>>
> >>> comments from everyone. Any other feedback?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> John
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On
> >>> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard.petracek@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>> hi
> >>> george,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>> thx
> >>> for the information. i thought there might be at
> >>>>>>>>>>>>>>>>> least some
> >>>>>>>>>>>>>>>>>>>>>>
> >>> additional
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> answers/clarifications, since pete asked for them in
> >>>>>>>>>>>>>>>>> several
> >>>>>>>>>>>>>>>>>>>> comments.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> -> imo we should continue with them.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/12 George Gastaldi
> >>>>>>>>>>>>>>>>>
> >>> <ge...@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> Hello Gerhard,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> Yeah, it´s the last state. I know it´s quite
> >>>>>>>>>>>>>>>>> old, but I
> >>>>>>>>>>>>>>>>>>>> haven´t
> >>> had
> >>>>>>>>>>>>>>>>>>>>>>
> >>> time
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> to work on it after that.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> Regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> George
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/12 Gerhard Petracek
> >>>>>>>>>>>>>>>>>
> >>> <ge...@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> hi george,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> thx for the link.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> i'm not sure if it is the latest state
> >>>>>>>>>>>>>>>>> of your discussion
> >>>>>>>>>>>>>>>>>>>> and/or
> >>>>>>>>>>>>>>>>>>>>> draft
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> (at least it's quite old already).
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/7 George Gastaldi
> >>>>>>>>>>>>>>>>>
> >>> <ge...@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Hi !
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> +1 to #1. I also agree that the term
> >>>>>>>>>>>>>>>>> "Service
> >>> Handler" might
> >>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>> so
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> appropriate, so it should be discussed
> >>>>>>>>>>>>>>>>> as well.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Here is the latest pull request with
> >>>>>>>>>>>>>>>>> some comments from
> >>> Pete
> >>>>>>>>>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> be
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> reviewed:
> >>>>>>>>>>>>>>>>>
> >>> https://github.com/jboss/cdi/pull/28
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/7 Pete Muir
> >>>>>>>>>>>>>>>>>
> >>> <pm...@redhat.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Agreed :-)
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> George is working on it for CDI
> >>>>>>>>>>>>>>>>> 1.1. George, can you
> >>> share
> >>>>>>>>>>>>>>>>>>>> your
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> proposal
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> so far?
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On 7 Mar 2012, at 17:05, Gerhard
> >>>>>>>>>>>>>>>>> Petracek wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> hi pete,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> independent of my opinion
> >>>>>>>>>>>>>>>>> about the feature
> >>> (which is
> >>>>>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>>>> +0):
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> if it should be part of cdi
> >>>>>>>>>>>>>>>>> 1.1, we have the
> >>> following
> >>>>>>>>>>>>>>>>>>>> options
> >>>>>>>>>>>>>>>>>>>>>>
> >>> imo:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 1) the approach (including
> >>>>>>>>>>>>>>>>> the name/s) we agree
> >>> on will
> >>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> used
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> also
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> for
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> cdi 1.1 (the only difference
> >>>>>>>>>>>>>>>>> is the package)
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2) the eg has a different
> >>>>>>>>>>>>>>>>> opinion about it ->
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2a) the rest of the eg joins
> >>>>>>>>>>>>>>>>> this discussion
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2b) we wait for the final
> >>>>>>>>>>>>>>>>> version and just allow
> >>> the same
> >>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>
> >>> cdi
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 1.0
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 3) if the eg doesn't
> >>>>>>>>>>>>>>>>> agree on the idea, it
> >>> should be
> >>>>>>>>>>>>>>>>>>>> re-visited
> >>>>>>>>>>>>>>>>>>>>>>
> >>> for
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> deltaspike (if we really need
> >>>>>>>>>>>>>>>>> it)
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 4) we agree on it independent
> >>>>>>>>>>>>>>>>> of the result in cdi
> >>> 1.1
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 1-3 is ok for me but -1 for
> >>>>>>>>>>>>>>>>> #4
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/7 Pete Muir
> >>>>>>>>>>>>>>>>>
> >>> <pm...@redhat.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> I'm not sure what you
> >>>>>>>>>>>>>>>>> mean by a "super
> >>> interceptor",
> >>>>>>>>>>>>>>>>>>>> but if
> >>>>>>>>>>>>>>>>>>>>> you
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> mean it
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> as
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> in "super man"
> >>>>>>>>>>>>>>>>> (something better than
> >>> an interceptor),
> >>>>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> I
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> would
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> disagree, it's
> >>>>>>>>>>>>>>>>> actually a specialised
> >>> form of
> >>>>>>>>>>>>>>>>>>>>
> >>> interceptor.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> The best use case I know
> >>>>>>>>>>>>>>>>> of is the one John
> >>> mentions -
> >>>>>>>>>>>>>>>>>>>>>
> >>> creating
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> type
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> safe
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> references to queries:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> @QueryService
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> interface UserQuery {
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> @Query("select u
> >>>>>>>>>>>>>>>>> from User u")
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> public List<User>
> >>>>>>>>>>>>>>>>> getAllUsers();
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> @Query("select u
> >>>>>>>>>>>>>>>>> from User u order by
> >>> u.name")
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> public List<User>
> >>>>>>>>>>>>>>>>>
> >>> getAllUsersSortedByName();
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> }
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Now, it may be the case
> >>>>>>>>>>>>>>>>> that there aren't
> >>> any other use
> >>>>>>>>>>>>>>>>>>>> cases
> >>>>>>>>>>>>>>>>>>>>>>
> >>> for
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> service
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> handlers, in which case
> >>>>>>>>>>>>>>>>> we should perhaps just
> >>> offer
> >>>>>>>>>>>>>>>>>>>> this
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> particular
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> service handler -
> >>>>>>>>>>>>>>>>> references to type
> >>> safe queries - as I
> >>>>>>>>>>>>>>>>>>>> think
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> this
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> is
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> an
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> extremely powerful idea.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Note, that at the moment
> >>>>>>>>>>>>>>>>> service handlers are
> >>> scheduled
> >>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>> CDI
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> 1.1.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On 7 Mar 2012, at 02:35,
> >>>>>>>>>>>>>>>>> Jason Porter wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Somewhat. I
> >>>>>>>>>>>>>>>>> wouldn't really
> >>> think of them as overrides,
> >>>>>>>>>>>>>>>>>>>> they,
> >>>>>>>>>>>>>>>>>>>>>> to
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> me,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> seem more like items to
> >>>>>>>>>>>>>>>>> do in addition to
> >>> whatever the
> >>>>>>>>>>>>>>>>>>>>>
> >>> original
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> impl
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> does.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> ServiceHandlers to me
> >>>>>>>>>>>>>>>>> seem more like super
> >>>>>>>>>>>>>>>>>>>>
> >>> interceptors.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Sent from my iPhone
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On Mar 6, 2012, at
> >>>>>>>>>>>>>>>>> 19:23, "John D.
> >>> Ament" <
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> john.d.ament@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> @jason
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> I think the
> >>>>>>>>>>>>>>>>> concepts are very
> >>> dissimilar.
> >>>>>>>>>>>>>>>>>>>>
> >>> servicehandlers
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> create
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> implementation.
> >>>>>>>>>>>>>>>>> delegates are more
> >>> like overrides and
> >>>>>>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>>>>> to
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> know
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> about
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the method
> >>>>>>>>>>>>>>>>> signature.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On Tue, Mar 6,
> >>>>>>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> >>> Porter <
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> lightguard.jp@gmail.com
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> I think the
> >>>>>>>>>>>>>>>>> idea of
> >>> ServiceHandlers are good, but,
> >>>>>>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>
> >>> not
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> do
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> this
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> with
> >>>>>>>>>>>>>>>>> delegates?
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Sent from my
> >>>>>>>>>>>>>>>>> iPhone
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On Mar 6,
> >>>>>>>>>>>>>>>>> 2012, at 19:05,
> >>> "John D. Ament" <
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> john.d.ament@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> @mark
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> I
> >>>>>>>>>>>>>>>>> don't think
> >>> it's a hard requirement for it to be
> >>>>>>>>>>>>>>>>>>>> on an
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> interface.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> One of
> >>>>>>>>>>>>>>>>> the best use-cases we
> >>> built at my job is
> >>>>>>>>>>>>>>>>>>>> using it
> >>>>>>>>>>>>>>>>>>>>> for
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> calling
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> PL/SQL.
> >>>>>>>>>>>>>>>>> The JDBC bindings do
> >>> work, but not pretty.
> >>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>> were
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> able to
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> create
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> a fairly
> >>>>>>>>>>>>>>>>> clean wrapper API,
> >>> generic enough for
> >>>>>>>>>>>>>>>>>>>> binding
> >>>>>>>>>>>>>>>>>>>>>>
> >>> in/out
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> parameters.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> JOhn
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On Tue,
> >>>>>>>>>>>>>>>>> Mar 6, 2012 at 12:58
> >>> PM, Mark Struberg <
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> struberg@yahoo.de>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> actually I don't
> >>> really see a real benefit. I just
> >>>>>>>>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>>>>>
> >>> yet
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> grok
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> use
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> case
> >>>>>>>>>>>>>>>>> for real world
> >>> projects.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Why
> >>>>>>>>>>>>>>>>> would one intercept an
> >>> Interface and delegate
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> calls
> >>>>
> >>>>>>>>>>>>>>>>>>>>>> to
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> a
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> method
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> handler?
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> This
> >>>>>>>>>>>>>>>>> could be neat for
> >>> mocking, but there are
> >>>>>>>>>>>>>>>>>>>> better
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> frameworks for
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> that.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> thus
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> -0.2
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> LieGrue,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> strub
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> -----
> >>>>>>>>>>>>>>>>> Original Message -----
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> From: Gerhard Petracek
> >>>>>>>>>>>>>>>>>>>>
> >>> <ge...@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> To:
> >>> deltaspike-dev@incubator.apache.org
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Cc:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sent: Tuesday, March
> >>> 6, 2012 5:15 PM
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
> >>> [DELTASPIKE-113] Review and
> >>>>>>>>>>>>>>>>>>>>>
> >>> Discuss
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ServiceHandler
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> if you have a lot of
> >>> shared code, you can extract
> >>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>
> >>> 1-n
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> method/s or
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> an
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> abstract class which
> >>> is still easier than a new
> >>>>>>>>>>>>>>>>>>>> concept.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> at least i haven't
> >>> seen an use-case which really
> >>>>>>>>>>>>>>>>>>>> needed
> >>>>>>>>>>>>>>>>>>>>>>
> >>> it.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> that
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> was
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> reason for a +0 (which
> >>> still means that i'm ok
> >>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>> adding
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> it).
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>> <pm...@redhat.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> So, you mean just write a bean with all the
> >>>>>>>>>>>>>>>>>>>>
> >>> boilerplate
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> code
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> in
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> it?
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>>>>>>>>>>>>>>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> hi pete,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> instead of the interface you can just
> >>>>>>>>>>>>>>>>> implement
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>> bean
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>> which
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> does
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> same.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/6 Pete Muir
> >>>>>>>>>>>>>>>>>
> >>> <pm...@redhat.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> What CDI mechanism would you use
> >>>>>>>>>>>>>>>>> instead?
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> On 5 Mar 2012, at 08:47, Gerhard
> >>>>>>>>>>>>>>>>> Petracek
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> +0
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> no -1 because there are
> >>>>>>>>>>>>>>>>> use-cases for it.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> no +1 because i would use std.
> >>>>>>>>>>>>>>>>> cdi mechanisms
> >>>>>>>>>>>>>>>>>>>>>
> >>> instead.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/4 Gerhard Petracek <
> >>>>>>>>>>>>>>>>>>>>>
> >>> gerhard.petracek@gmail.com
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> hi john,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the sub-task is perfectly
> >>>>>>>>>>>>>>>>> fine.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> gerhard
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> 2012/3/4 John D. Ament
> >>>>>>>>>>>>>>>>>>>>
> >>> <jo...@gmail.com>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Hi All
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> I wanted to bring up
> >>>>>>>>>>>>>>>>> the subject of
> >>>>>>>>>>>>>>>>>>>>>
> >>> ServiceHandler.
> >>>>>>>>>>>>>>>>>>>>>> I
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> added 113 as a
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> child
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> of DELTASPIKE-2, looked
> >>>>>>>>>>>>>>>>> appropriate but not
> >>>>>>>>>>>>>>>>>>>> 100%
> >>>>>>>>>>>>>>>>>>>>>>
> >>> sure
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (so please let
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> me
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> know if you think
> >>>>>>>>>>>>>>>>> it's not
> >>> appropriate as a
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> child).
> >>> ServiceHandler
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> is
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> a
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> feature in Solder that
> >>>>>>>>>>>>>>>>> allows you to define
> >>>>>>>>>>>>>>>>>>>> an
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> interceptor that
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> manages
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> generic calls against
> >>>>>>>>>>>>>>>>> an injected interface.
> >>>>>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>>>
> >>> API
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> is as follows:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> -
> >>>>>>>>>>>>>>>>>
> >>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>>>>>>>>>>>>>>> placed
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> on an annotation that
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> would
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> be placed on the
> >>>>>>>>>>>>>>>>> interface. Indicates
> >>> what
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> interceptor would be
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> invoked
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> for calls against this
> >>>>>>>>>>>>>>>>> interface.
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> It's then up to the
> >>>>>>>>>>>>>>>>> application
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> developer/framework
> >>> author to define
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> annotations that go on
> >>>>>>>>>>>>>>>>> methods, as well as
> >>>>>>>>>>>>>>>>>>>> the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> interceptor itself
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>> that
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> will
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> be invoked. The
> >>>>>>>>>>>>>>>>> feature for
> >>> ServiceHandler
> >>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>> be
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to provide the
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> API of
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> the type and then the
> >>>>>>>>>>>>>>>>> infrastructure
> >>>>>>>>>>>>>>>>>>>> required
> >>> to
> >>>>>>>>>>>>>>>>>>>>>>
> >>> make
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> the interceptor
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> be
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> called. Existing
> >>>>>>>>>>>>>>>>> documentation of the
> >>>>>>>>>>>>>>>>>>>> feature:
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>>>>>>>>>>>>>> ser
> >>>>>>>>>>>>>>>>>>>>
> >>> vicehandler.html
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Regards,
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> john
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Jason Porter
> >>>>>>>>>>>>>>>>>>>
> >>> http://lightguard-jp.blogspot.com
> >>>>>>>>>>>>>>>>>>>
> >>> http://twitter.com/lightguardjp
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Software
> >>> Engineer
> >>>>>>>>>>>>>>>>>>> Open Source
> >>> Advocate
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> PGP key id:
> >>> 926CCFF5
> >>>>>>>>>>>>>>>>>>> PGP key
> >>> available at: keyserver.net, pgp.mit.edu
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jason Porter
> >>>>>> http://lightguard-jp.blogspot.com
> >>>>>> http://twitter.com/lightguardjp
> >>>>>>
> >>>>>> Software Engineer
> >>>>>> Open Source Advocate
> >>>>>>
> >>>>>> PGP key id: 926CCFF5
> >>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
I think it should work, adding a qualifier, but I don't think it's the "normal" way to do it.
On 23 Dec 2012, at 16:12, John D. Ament wrote:
> Well, this object is used for a specific case. In my opinion, you should be
> able to resolve it using
>
> @Inject @QueryHandler
> private InvocationHandler queryHandler;
>
> Though why you may want to inject it in a client app is unknown to me; it
> does make it easier from an implementation standpoint.
>
> Does the service handler need to have any specific scope? Can it inherit
> the scope of what it's handling? I guess not, since it could be a handler
> to n things. NormalScope would be appropriate then.
>
>
> On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> I guess because it might overlap with other qualifiers added in some cases.
>>
>> What do we gain for making it a qualifier?
>>
>> Another important difference to CDI interceptors is that they are always
>> @Dependent to the intercepted instance.
>> Whereas the ServiceHandler should be of NormalScope, isn't?
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: John D. Ament <jo...@gmail.com>
>>> To: deltaspike-dev@incubator.apache.org
>>> Cc:
>>> Sent: Saturday, December 22, 2012 7:56 PM
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>>>
>>> Pete,
>>>
>>> Regarding interceptors - I think what I have is pretty close to the
>>> interceptor definition, except this should only end up working on a
>>> class/interface (I think?)
>>>
>>> Also, why wouldn't we want the annotation to also be a qualifier?
>>>
>>> John
>>>
>>>
>>> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
>>>
>>>>
>>>> On 21 Dec 2012, at 02:21, John D. Ament wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> So just to summarize the current proposal:
>>>>>
>>>>> - Create a new annotation @ServiceHandlerBinding (in core/api) which
>>> will
>>>>> be placed on on the interface that defines points of the
>>>>> - Create a new annotation @ServiceHandler (in core/api) (I think
>> based
>>> on
>>>>> below this isn't needed since we have the interface now).
>>>>> - Create an extension that can generate object proxies that link
>> calls
>>> to
>>>>> methods on the - org.apache.deltaspike.core.api....
>>>>>
>>>>> Define the binding type annotation:
>>>>>
>>>>> @ServiceHandlerBinding
>>>>> @Qualifier
>>>>> public @interface QueryHandler {
>>>>> }
>>>>
>>>> I don't think we want @Qualifier here.
>>>>
>>>>>
>>>>> which will define the relationship between the interface/abstract
>>> class
>>>>> that will use the service handler and the class that will serve as
>> the
>>>>> invocation handler.
>>>>>
>>>>> For example, we can use @QueryHandler on an interface:
>>>>>
>>>>> @QueryHandler
>>>>> public interface PersonDAO {
>>>>> //...
>>>>> }
>>>>>
>>>>> When the container finds this interface it will identify the
>>> appropriate
>>>>> InvocationHandler, based on the following matches:
>>>>>
>>>>> - Implements InvocationHandler
>>>>
>>>> Yes.
>>>>
>>>>> - Is annotated @QueryHandler
>>>>
>>>> Ish, this should follow standard CDI resolution rules, you can copy the
>>>> way interceptor bindings work here.
>>>>
>>>>> - Is annotated @ServiceHandler
>>>>
>>>> Yes
>>>>
>>>>>
>>>>> DeltaSpike will provide a proxied object where all abstract method
>>> calls
>>>>> are delegated to the InvocationHandler. The InvocationHandler will
>>> need
>>>> to
>>>>> have logic to handle all methods as defined within the class, as long
>>> as
>>>>> that method is invoked through the InvocationHandler.
>>>>>
>>>>> @QueryHandler @ServiceHandler
>>>>> public QueryHandlerInvoker implements InvocationHandler {
>>>>>
>>>>> public Object invoke(Object proxy, Method method, Object[] args) {
>>>>> if(method.getName().startsWith("find..."){
>>>>> //...
>>>>> }
>>>>> return null;
>>>>>
>>>>> }
>>>>> }
>>>>>
>>>>> In addition, the ServiceHandlerBinding can be placed on an abstract
>>>> class.
>>>>> In this case, only abstract methods will be passed to the
>>>>> InvocationHandler.
>>>>>
>>>>> @QueryHandler
>>>>> public abstract interface PersonDAO {
>>>>> public String doSomethingConcrete() {
>>>>> return "concrete";
>>>>> }
>>>>>
>>>>> public abstract Person find(int id);
>>>>> }
>>>>>
>>>>> Only the find method will be wrapped, the method doSomethingConcrete
>>> will
>>>>> be invoked directly. When interacting with an abstract class, the
>>>>> InvocationHandler can call methods on the proxied object.
>>>>>
>>>>> Finally, the app developer will be able to simply inject their
>>>>> interface/abstract class in to their beans to perform work:
>>>>>
>>>>> @Inject @QueryHandler PersonDAO dao;
>>>>>
>>>>> Questions:
>>>>>
>>>>> Should we provide a store (simple key/value map) to keep a history of
>>>> found
>>>>> object types and how they map?
>>>>
>>>> You mean like BeanManager.resolveInterceptors() ? I guess this is
>> useful.
>>>>
>>>>> Should we depend on certain libraries for proxying (e.g. javassist, I
>>>> think
>>>>> both Weld & OWB use this still?)
>>>>
>>>> If you want to just cover interfaces, it's easy, you can use proxying
>>> from
>>>> the JDK. Otherwise yes you need to pick a lib.
>>>>
>>>> Weld doesn't use javassist for proxying, but does for other stuff.
>>>>
>>>>> Since we now use the interface InvocationHandler should we rename the
>>>>> binding to be InvocationHandlerBinding?
>>>>
>>>> Yes, this makes sense
>>>>
>>>>> I also think it's not necessary to
>>>>> have @ServiceHandler since the marker interface now exists.
>>>>
>>>> +1
>>>>
>>>>>
>>>>> Comments welcome..
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
>>> <lightguard.jp@gmail.com
>>>>> wrote:
>>>>>
>>>>>> +1 for @ServiceHandler
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
>>> <john.d.ament@gmail.com
>>>>>>> wrote:
>>>>>>
>>>>>>> If we're still calling the feature
>>> "ServiceHandler" then why not
>>>>>>> @ServiceHandler?
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>
>>>>>>>> if we don't need it perfect, if we need it we'll
>>> just use another name
>>>>>>>> @DSHandler, @Handler...whatever it is ;)
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> Twitter: @rmannibucau
>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
>>>>>>>>> :-) Yes for sure. I suspect we dont' need
>>> @InvocationHandler at all.
>>>>>>>>>
>>>>>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
>>>>>>>>>
>>>>>>>>>> The problem I have is that now InvocationHandler
>>> is both an
>>>>>> interface
>>>>>>>> and
>>>>>>>>>> an @interface which will make it impossible for
>>> imports. I don't
>>>>>>> think
>>>>>>>>>> they should have the same name.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
>>> <pm...@redhat.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>>>>>>>>>>>
>>>>>>>>>>>> All,
>>>>>>>>>>>>
>>>>>>>>>>>> So mostly ok from my perspective. One
>>> thing to note:
>>>>>>>>>>>>
>>>>>>>>>>>> @InvocationHandlerBinding
>>>>>>>>>>>> public @interface Repository {}
>>>>>>>>>>>>
>>>>>>>>>>>> @Repository
>>>>>>>>>>>> public interface MyRepository {
>>>>>>>>>>>> ...
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> @Repository @InvocationHandler
>>>>>>>>>>>> public class MyInvocationHandler
>>> implements InvocationHandler {
>>>>>>>>>>>> ...
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Why do we have a @InvocationHandler here?
>>> Is it supposed to be
>>>>>>>>>>>> @InvocationHandlerBinding instead? If so,
>>> is it really needed
>>>>>> here?
>>>>>>>>>>>
>>>>>>>>>>> No, it should be @InvocationHandler, it's
>>> analagous to
>>>>>> @Interceptor.
>>>>>>>> It's
>>>>>>>>>>> not 100% necessary as we already implement the
>>> interface, which is
>>>>>>>> enough
>>>>>>>>>>> of the marker.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thinking about the implementation for
>>> this, I think this actually
>>>>>>>> becomes
>>>>>>>>>>>> easier to use and easier to understand
>>> over the Solder solution.
>>>>>>> The
>>>>>>>>>>>> implementation of the InvocationHandler
>>> becomes a true CDI bean.
>>>>>>>>>>>>
>>>>>>>>>>>> Should DS support Interceptors and
>>> Decorators on
>>>>>>>>>>>> InvocationHandler beans?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you mean the implementation class or
>>> the interface?
>>>>>>>>>>>>
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
>>> Manni-Bucau
>>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> i'd rather say no because the idea
>>> is to ease "util" extension
>>>>>>>>>>>>> writing. that's clearly not
>>> intended to be full business beans
>>>>>> IMO
>>>>>>>> (at
>>>>>>>>>>>>> least for a first step)
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's why i'd leave it as
>>> this for now
>>>>>>>>>>>>>
>>>>>>>>>>>>> wdyt?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>>>> Blog:
>>> http://rmannibucau.wordpress.com/
>>>>>>>>>>>>> LinkedIn:
>>> http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/12/20 Arne Limburg
>>> <ar...@openknowledge.de>:
>>>>>>>>>>>>>> Mark refers to my call stack.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Out of the box this call stack
>>> would exist just in OWB, because
>>>>>>> Weld
>>>>>>>>>>>>> would
>>>>>>>>>>>>>> not apply any Interceptors or
>>> Decorators...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The question is: Should DS support
>>> Interceptors and Decorators
>>>>>> on
>>>>>>>>>>>>>> InvocationHandler beans? My answer
>>> would be: yes, if our
>>>>>>>> implementation
>>>>>>>>>>>>>> shall be a preview of CDI-110.
>>>>>>>>>>>>>> And that would make things
>>> complicated in the implementation...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 20.12.12 12:11 schrieb
>>> "Romain Manni-Bucau" unter
>>>>>>>>>>>>>> <rm...@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is it an issue for
>>> servicehandler? i don't think so
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it is often used to get util
>>> classes dynamically created, it is
>>>>>>>> rarely
>>>>>>>>>>>>>>> (i never saw it) decorated
>>> directly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>>>>>> Blog:
>>> http://rmannibucau.wordpress.com/
>>>>>>>>>>>>>>> LinkedIn:
>>> http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>>>>>> Github:
>>> https://github.com/rmannibucau
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/12/20 Mark Struberg
>>> <st...@yahoo.de>:
>>>>>>>>>>>>>>>> we stumbled about this
>>> lately. It seems CDI only forces
>>>>>> support
>>>>>>>> for
>>>>>>>>>>>>>>>> interceptors and
>>> decorators for CDI-annotated classes, but not
>>>>>>> for
>>>>>>>>>>>>>>>> Bean<T> which get
>>> added via extensions nor even producer
>>>>>> methods
>>>>>>>> and
>>>>>>>>>>>>>>>> fields :/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Of course OWB does it, but
>>> it would be not portable...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ----- Original Message
>>> -----
>>>>>>>>>>>>>>>>> From: Arne Limburg
>>> <ar...@openknowledge.de>
>>>>>>>>>>>>>>>>> To:
>>> "deltaspike-dev@incubator.apache.org"
>>>>>>>>>>>>>>>>>
>>> <de...@incubator.apache.org>
>>>>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>>>> Sent: Thursday,
>>> December 20, 2012 10:18 AM
>>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
>>> [DELTASPIKE-113] Review and Discuss
>>>>>>>>>>>>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> T wo things about
>>> this: First: I don't like from the solder
>>>>>>>>>>> approach,
>>>>>>>>>>>>>>>>> because the interface
>>> is annotated instead of the
>>>>>>> implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Second, if we
>>> implement this we should conceptually make
>>>>>> clear
>>>>>>>> how
>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> differentiates from
>>> Interceptors and Decorators. And
>>>>>>> personally I
>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> this would work better
>>> with the InvocationHandler approach
>>>>>> than
>>>>>>>> with
>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>> approach that is very
>>> similar to interceptors.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So +1 for an approach
>>> like this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>>>>>>>>>>>>> public class
>>> MyInvocationHandler implements
>>>>>> InvocationHandler {
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Technically we would
>>> register a custom Bean for every found
>>>>>>>>>>>>>>>>> InvocationHandler with
>>> that annotation and take over the
>>>>>>>>>>>>>>>>> interceptor-bindings
>>> from the interfaceŠ
>>>>>>>>>>>>>>>>> So the invocation
>>> stack would be clear, too:
>>>>>>>>>>>>>>>>> First Interceptors,
>>>>>>>>>>>>>>>>> Second Decorators,
>>>>>>>>>>>>>>>>> Third
>>> InvocationHandler
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Wdyt?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Arne
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Am 20.12.12 01:53
>>> schrieb "Romain Manni-Bucau" unter
>>>>>>>>>>>>>>>>>
>>> <rm...@gmail.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> that's a need,
>>> DS targets CDI 1.0 for now so just make this
>>>>>>>> solder
>>>>>>>>>>>>>>>>>> part portable ans
>>> it should be fine
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>>>>>> Twitter:
>>> @rmannibucau
>>>>>>>>>>>>>>>>>> Blog:
>>> http://rmannibucau.wordpress.com/
>>>>>>>>>>>>>>>>>> LinkedIn:
>>> http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>>>>>>>>> Github:
>>> https://github.com/rmannibucau
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2012/12/20 Jason
>>> Porter <li...@gmail.com>:
>>>>>>>>>>>>>>>>>>> At this point,
>>> I'd say just do it as is in solder.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Dec
>>> 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>>>>>>>>>>>>>
>>> <jo...@gmail.com>wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regarding
>>> the two open questions:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1) the
>>> approach (including the name/s) we agree on will be
>>>>>>>> used
>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> cdi 1.1
>>> (the only difference is the package)
>>>>>>>>>>>>>>>>>>>> 2) the eg
>>> has a different opinion about it ->
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It looks
>>> like the JSR's answer
>>>>>>>>>>>>>>>>>>>>
>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>>>>>>>>>>>>> is still
>>> unresolved - I'm not sure if we can get any
>>>>>> further
>>>>>>>>>>>>>>>>> answer at
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> time. The
>>> last posts on the subject seem to discuss using
>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>> along
>>>>>>>>>>>>>>>>>>>> the lines
>>> of an invocation handler, which I think would
>>>>>> work
>>>>>>>>>>> well.
>>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>>> we have
>>> some features coming up that are interested in
>>>>>>> having
>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>> handlers
>>> available, do we
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1.
>>> Implement as is, or similar to, what is currently in
>>>>>>>> Solder?
>>>>>>>>>>>>>>>>>>>> 2. Push EG
>>> on a resolution
>>>>>>>>>>>>>>>>>>>> 3. Do it
>>> using invocation handlers.
>>>>>>>>>>>>>>>>>>>> 4. Do it
>>> some other way?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed,
>>> Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>>>>>>>>>>>>>
>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> hi
>>> john,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> as
>>> mentioned before we need the answers to the existing
>>>>>>>>>>>>>>>>> questions.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> All,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I
>>> kind of let this one and the other drop off my radar,
>>>>>> I
>>>>>>>>>>>>>>>>>>>> apologize.
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>
>>> looks like where we last left off, Gerhard was still
>>>>>>>>>>>>>>>>> requesting
>>>>>>>>>>>>>>>>>>>>>
>>> additional
>>>>>>>>>>>>>>>>>>>>>>
>>> comments from everyone. Any other feedback?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> John
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On
>>> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>> hi
>>> george,
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>> thx
>>> for the information. i thought there might be at
>>>>>>>>>>>>>>>>> least some
>>>>>>>>>>>>>>>>>>>>>>
>>> additional
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> answers/clarifications, since pete asked for them in
>>>>>>>>>>>>>>>>> several
>>>>>>>>>>>>>>>>>>>> comments.
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> -> imo we should continue with them.
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/12 George Gastaldi
>>>>>>>>>>>>>>>>>
>>> <ge...@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> Hello Gerhard,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> Yeah, it´s the last state. I know it´s quite
>>>>>>>>>>>>>>>>> old, but I
>>>>>>>>>>>>>>>>>>>> haven´t
>>> had
>>>>>>>>>>>>>>>>>>>>>>
>>> time
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> to work on it after that.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> Regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> George
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/12 Gerhard Petracek
>>>>>>>>>>>>>>>>>
>>> <ge...@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> hi george,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> thx for the link.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> i'm not sure if it is the latest state
>>>>>>>>>>>>>>>>> of your discussion
>>>>>>>>>>>>>>>>>>>> and/or
>>>>>>>>>>>>>>>>>>>>> draft
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> (at least it's quite old already).
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/7 George Gastaldi
>>>>>>>>>>>>>>>>>
>>> <ge...@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Hi !
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> +1 to #1. I also agree that the term
>>>>>>>>>>>>>>>>> "Service
>>> Handler" might
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> so
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> appropriate, so it should be discussed
>>>>>>>>>>>>>>>>> as well.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Here is the latest pull request with
>>>>>>>>>>>>>>>>> some comments from
>>> Pete
>>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> be
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> reviewed:
>>>>>>>>>>>>>>>>>
>>> https://github.com/jboss/cdi/pull/28
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/7 Pete Muir
>>>>>>>>>>>>>>>>>
>>> <pm...@redhat.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Agreed :-)
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> George is working on it for CDI
>>>>>>>>>>>>>>>>> 1.1. George, can you
>>> share
>>>>>>>>>>>>>>>>>>>> your
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> proposal
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> so far?
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>>>>>>>>>>>>> Petracek wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> hi pete,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> independent of my opinion
>>>>>>>>>>>>>>>>> about the feature
>>> (which is
>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>> +0):
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> if it should be part of cdi
>>>>>>>>>>>>>>>>> 1.1, we have the
>>> following
>>>>>>>>>>>>>>>>>>>> options
>>>>>>>>>>>>>>>>>>>>>>
>>> imo:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 1) the approach (including
>>>>>>>>>>>>>>>>> the name/s) we agree
>>> on will
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> used
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> also
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> for
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> cdi 1.1 (the only difference
>>>>>>>>>>>>>>>>> is the package)
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2) the eg has a different
>>>>>>>>>>>>>>>>> opinion about it ->
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2a) the rest of the eg joins
>>>>>>>>>>>>>>>>> this discussion
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2b) we wait for the final
>>>>>>>>>>>>>>>>> version and just allow
>>> the same
>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>
>>> cdi
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 1.0
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 3) if the eg doesn't
>>>>>>>>>>>>>>>>> agree on the idea, it
>>> should be
>>>>>>>>>>>>>>>>>>>> re-visited
>>>>>>>>>>>>>>>>>>>>>>
>>> for
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> deltaspike (if we really need
>>>>>>>>>>>>>>>>> it)
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 4) we agree on it independent
>>>>>>>>>>>>>>>>> of the result in cdi
>>> 1.1
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 1-3 is ok for me but -1 for
>>>>>>>>>>>>>>>>> #4
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/7 Pete Muir
>>>>>>>>>>>>>>>>>
>>> <pm...@redhat.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> I'm not sure what you
>>>>>>>>>>>>>>>>> mean by a "super
>>> interceptor",
>>>>>>>>>>>>>>>>>>>> but if
>>>>>>>>>>>>>>>>>>>>> you
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> mean it
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> as
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> in "super man"
>>>>>>>>>>>>>>>>> (something better than
>>> an interceptor),
>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> I
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> would
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> disagree, it's
>>>>>>>>>>>>>>>>> actually a specialised
>>> form of
>>>>>>>>>>>>>>>>>>>>
>>> interceptor.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> The best use case I know
>>>>>>>>>>>>>>>>> of is the one John
>>> mentions -
>>>>>>>>>>>>>>>>>>>>>
>>> creating
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> type
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> safe
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> references to queries:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> @QueryService
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> interface UserQuery {
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> @Query("select u
>>>>>>>>>>>>>>>>> from User u")
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> public List<User>
>>>>>>>>>>>>>>>>> getAllUsers();
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> @Query("select u
>>>>>>>>>>>>>>>>> from User u order by
>>> u.name")
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> public List<User>
>>>>>>>>>>>>>>>>>
>>> getAllUsersSortedByName();
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> }
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Now, it may be the case
>>>>>>>>>>>>>>>>> that there aren't
>>> any other use
>>>>>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>>>>>>>
>>> for
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> service
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> handlers, in which case
>>>>>>>>>>>>>>>>> we should perhaps just
>>> offer
>>>>>>>>>>>>>>>>>>>> this
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> particular
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> service handler -
>>>>>>>>>>>>>>>>> references to type
>>> safe queries - as I
>>>>>>>>>>>>>>>>>>>> think
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> this
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> is
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> an
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> extremely powerful idea.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Note, that at the moment
>>>>>>>>>>>>>>>>> service handlers are
>>> scheduled
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> CDI
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> 1.1.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On 7 Mar 2012, at 02:35,
>>>>>>>>>>>>>>>>> Jason Porter wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Somewhat. I
>>>>>>>>>>>>>>>>> wouldn't really
>>> think of them as overrides,
>>>>>>>>>>>>>>>>>>>> they,
>>>>>>>>>>>>>>>>>>>>>> to
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> me,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> seem more like items to
>>>>>>>>>>>>>>>>> do in addition to
>>> whatever the
>>>>>>>>>>>>>>>>>>>>>
>>> original
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> impl
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> does.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> ServiceHandlers to me
>>>>>>>>>>>>>>>>> seem more like super
>>>>>>>>>>>>>>>>>>>>
>>> interceptors.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Sent from my iPhone
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On Mar 6, 2012, at
>>>>>>>>>>>>>>>>> 19:23, "John D.
>>> Ament" <
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> john.d.ament@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> @jason
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> I think the
>>>>>>>>>>>>>>>>> concepts are very
>>> dissimilar.
>>>>>>>>>>>>>>>>>>>>
>>> servicehandlers
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> create
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> implementation.
>>>>>>>>>>>>>>>>> delegates are more
>>> like overrides and
>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>> to
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> know
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> about
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the method
>>>>>>>>>>>>>>>>> signature.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On Tue, Mar 6,
>>>>>>>>>>>>>>>>> 2012 at 9:17 PM, Jason
>>> Porter <
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> lightguard.jp@gmail.com
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> I think the
>>>>>>>>>>>>>>>>> idea of
>>> ServiceHandlers are good, but,
>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>
>>> not
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> do
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> this
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> with
>>>>>>>>>>>>>>>>> delegates?
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Sent from my
>>>>>>>>>>>>>>>>> iPhone
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On Mar 6,
>>>>>>>>>>>>>>>>> 2012, at 19:05,
>>> "John D. Ament" <
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> john.d.ament@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> @mark
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> I
>>>>>>>>>>>>>>>>> don't think
>>> it's a hard requirement for it to be
>>>>>>>>>>>>>>>>>>>> on an
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> interface.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> One of
>>>>>>>>>>>>>>>>> the best use-cases we
>>> built at my job is
>>>>>>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>>>>>>>> for
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> calling
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> PL/SQL.
>>>>>>>>>>>>>>>>> The JDBC bindings do
>>> work, but not pretty.
>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> were
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> able to
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> create
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> a fairly
>>>>>>>>>>>>>>>>> clean wrapper API,
>>> generic enough for
>>>>>>>>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>>>>>>>>>
>>> in/out
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> parameters.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> JOhn
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On Tue,
>>>>>>>>>>>>>>>>> Mar 6, 2012 at 12:58
>>> PM, Mark Struberg <
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> struberg@yahoo.de>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> actually I don't
>>> really see a real benefit. I just
>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>
>>> yet
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> grok
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> use
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> case
>>>>>>>>>>>>>>>>> for real world
>>> projects.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Why
>>>>>>>>>>>>>>>>> would one intercept an
>>> Interface and delegate
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> calls
>>>>
>>>>>>>>>>>>>>>>>>>>>> to
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> a
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> method
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> handler?
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> This
>>>>>>>>>>>>>>>>> could be neat for
>>> mocking, but there are
>>>>>>>>>>>>>>>>>>>> better
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> frameworks for
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> that.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> thus
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> -0.2
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LieGrue,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> strub
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> -----
>>>>>>>>>>>>>>>>> Original Message -----
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From: Gerhard Petracek
>>>>>>>>>>>>>>>>>>>>
>>> <ge...@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To:
>>> deltaspike-dev@incubator.apache.org
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cc:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sent: Tuesday, March
>>> 6, 2012 5:15 PM
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS]
>>> [DELTASPIKE-113] Review and
>>>>>>>>>>>>>>>>>>>>>
>>> Discuss
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ServiceHandler
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> if you have a lot of
>>> shared code, you can extract
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>
>>> 1-n
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> method/s or
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> an
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> abstract class which
>>> is still easier than a new
>>>>>>>>>>>>>>>>>>>> concept.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at least i haven't
>>> seen an use-case which really
>>>>>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>>>>>>>
>>> it.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> that
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> was
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> reason for a +0 (which
>>> still means that i'm ok
>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> adding
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> it).
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>> <pm...@redhat.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> So, you mean just write a bean with all the
>>>>>>>>>>>>>>>>>>>>
>>> boilerplate
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> code
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> in
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> it?
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>>>>>>>>>>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> hi pete,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> instead of the interface you can just
>>>>>>>>>>>>>>>>> implement
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> bean
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>> which
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> does
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> same.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/6 Pete Muir
>>>>>>>>>>>>>>>>>
>>> <pm...@redhat.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> What CDI mechanism would you use
>>>>>>>>>>>>>>>>> instead?
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>>>>>>>>>>>>> Petracek
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> +0
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> no -1 because there are
>>>>>>>>>>>>>>>>> use-cases for it.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> no +1 because i would use std.
>>>>>>>>>>>>>>>>> cdi mechanisms
>>>>>>>>>>>>>>>>>>>>>
>>> instead.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>>>>>>>>>>>>>
>>> gerhard.petracek@gmail.com
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> hi john,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the sub-task is perfectly
>>>>>>>>>>>>>>>>> fine.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/4 John D. Ament
>>>>>>>>>>>>>>>>>>>>
>>> <jo...@gmail.com>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Hi All
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> I wanted to bring up
>>>>>>>>>>>>>>>>> the subject of
>>>>>>>>>>>>>>>>>>>>>
>>> ServiceHandler.
>>>>>>>>>>>>>>>>>>>>>> I
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> added 113 as a
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> child
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> of DELTASPIKE-2, looked
>>>>>>>>>>>>>>>>> appropriate but not
>>>>>>>>>>>>>>>>>>>> 100%
>>>>>>>>>>>>>>>>>>>>>>
>>> sure
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (so please let
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> me
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> know if you think
>>>>>>>>>>>>>>>>> it's not
>>> appropriate as a
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> child).
>>> ServiceHandler
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> is
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> a
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> feature in Solder that
>>>>>>>>>>>>>>>>> allows you to define
>>>>>>>>>>>>>>>>>>>> an
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> interceptor that
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> manages
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> generic calls against
>>>>>>>>>>>>>>>>> an injected interface.
>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>
>>> API
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is as follows:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> -
>>>>>>>>>>>>>>>>>
>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>>>>>>>>>>>>> placed
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> on an annotation that
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> would
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> be placed on the
>>>>>>>>>>>>>>>>> interface. Indicates
>>> what
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> interceptor would be
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> invoked
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> for calls against this
>>>>>>>>>>>>>>>>> interface.
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> It's then up to the
>>>>>>>>>>>>>>>>> application
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> developer/framework
>>> author to define
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> annotations that go on
>>>>>>>>>>>>>>>>> methods, as well as
>>>>>>>>>>>>>>>>>>>> the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> interceptor itself
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>> that
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> will
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> be invoked. The
>>>>>>>>>>>>>>>>> feature for
>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> be
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to provide the
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> API of
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> the type and then the
>>>>>>>>>>>>>>>>> infrastructure
>>>>>>>>>>>>>>>>>>>> required
>>> to
>>>>>>>>>>>>>>>>>>>>>>
>>> make
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the interceptor
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> be
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> called. Existing
>>>>>>>>>>>>>>>>> documentation of the
>>>>>>>>>>>>>>>>>>>> feature:
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>>>>>>>>>>>>> ser
>>>>>>>>>>>>>>>>>>>>
>>> vicehandler.html
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Regards,
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> john
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Jason Porter
>>>>>>>>>>>>>>>>>>>
>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>>>>>>>>>>
>>> http://twitter.com/lightguardjp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Software
>>> Engineer
>>>>>>>>>>>>>>>>>>> Open Source
>>> Advocate
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> PGP key id:
>>> 926CCFF5
>>>>>>>>>>>>>>>>>>> PGP key
>>> available at: keyserver.net, pgp.mit.edu
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason Porter
>>>>>> http://lightguard-jp.blogspot.com
>>>>>> http://twitter.com/lightguardjp
>>>>>>
>>>>>> Software Engineer
>>>>>> Open Source Advocate
>>>>>>
>>>>>> PGP key id: 926CCFF5
>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
that's not needed. as a contextual instance you just have a (custom) proxy
instead of a simple instance of a class. the custom proxy executes the
handler logic >or< the implemented method provided via the abstract class.
the rest is std. cdi.
regards,
gerhard
2012/12/23 Mark Struberg <st...@yahoo.de>
> Well, the big difference (apart from working on interfaces/abstract
> classes and not on distinct instances) is that CDI Interceptors and
> Decorators are defined as being @Dependent _on that particular instance_!
>
> This cannot be done in a portable way via an Extension as any @Dependent
> instances are stored in _and later restored from_ the CreationalContext.
> But there is no way to get an instance from the CreationalContext in a
> portable way.
>
> Thus either the handler has a specific NormalScope or if it's @Dependent
> we must create it for each method invocation. And of course (this is the
> part which most of the time is missing in other CDI extensions) we also
> must properly clean it up after each method invocation if the scope is
> @Dependent.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Gerhard Petracek <ge...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Sunday, December 23, 2012 8:37 PM
> > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> >
> > imo it should be as simple as possible, because so far we just heard one
> > use-case for which it really makes sense (DELTASPIKE-60 + abstract
> classes).
> > -> the following should be enough:
> >
> > @InvocationHandlerBinding
> > public @interface GenericDaoHandler {
> > }
> >
> > @GenericDaoHandler
> > public GenericDaoHandlerImpl implements InvocationHandler {
> > //...
> > }
> >
> > @GenericDaoHandler
> > @ApplicationScoped //or any other scope
> > public abstract class PersonDao { //or interface
> > //...
> > }
> >
> > @mark:
> > in the end it's just like an interceptor, but it just executes the
> > interceptor logic (without InvocationContext#proceed) >or< the
> implemented
> > method provided via an abstract class.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/12/23 John D. Ament <jo...@gmail.com>
> >
> >> Well, this object is used for a specific case. In my opinion, you
> should be
> >> able to resolve it using
> >>
> >> @Inject @QueryHandler
> >> private InvocationHandler queryHandler;
> >>
> >> Though why you may want to inject it in a client app is unknown to me;
> it
> >> does make it easier from an implementation standpoint.
> >>
> >> Does the service handler need to have any specific scope? Can it
> inherit
> >> the scope of what it's handling? I guess not, since it could be a
> > handler
> >> to n things. NormalScope would be appropriate then.
> >>
> >>
> >> On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de>
> > wrote:
> >>
> >> > I guess because it might overlap with other qualifiers added in some
> >> cases.
> >> >
> >> > What do we gain for making it a qualifier?
> >> >
> >> > Another important difference to CDI interceptors is that they are
> > always
> >> > @Dependent to the intercepted instance.
> >> > Whereas the ServiceHandler should be of NormalScope, isn't?
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> > > From: John D. Ament <jo...@gmail.com>
> >> > > To: deltaspike-dev@incubator.apache.org
> >> > > Cc:
> >> > > Sent: Saturday, December 22, 2012 7:56 PM
> >> > > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >> ServiceHandler
> >> > >
> >> > > Pete,
> >> > >
> >> > > Regarding interceptors - I think what I have is pretty close to
> > the
> >> > > interceptor definition, except this should only end up working on
> > a
> >> > > class/interface (I think?)
> >> > >
> >> > > Also, why wouldn't we want the annotation to also be a
> > qualifier?
> >> > >
> >> > > John
> >> > >
> >> > >
> >> > > On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir
> > <pm...@redhat.com> wrote:
> >> > >
> >> > >>
> >> > >> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> >> > >>
> >> > >> > Hi all,
> >> > >> >
> >> > >> > So just to summarize the current proposal:
> >> > >> >
> >> > >> > - Create a new annotation @ServiceHandlerBinding (in
> > core/api)
> >> which
> >> > > will
> >> > >> > be placed on on the interface that defines points of
> > the
> >> > >> > - Create a new annotation @ServiceHandler (in core/api)
> > (I think
> >> > based
> >> > > on
> >> > >> > below this isn't needed since we have the interface
> > now).
> >> > >> > - Create an extension that can generate object proxies
> > that link
> >> > calls
> >> > > to
> >> > >> > methods on the - org.apache.deltaspike.core.api....
> >> > >> >
> >> > >> > Define the binding type annotation:
> >> > >> >
> >> > >> > @ServiceHandlerBinding
> >> > >> > @Qualifier
> >> > >> > public @interface QueryHandler {
> >> > >> > }
> >> > >>
> >> > >> I don't think we want @Qualifier here.
> >> > >>
> >> > >> >
> >> > >> > which will define the relationship between the
> > interface/abstract
> >> > > class
> >> > >> > that will use the service handler and the class that
> > will serve as
> >> > the
> >> > >> > invocation handler.
> >> > >> >
> >> > >> > For example, we can use @QueryHandler on an interface:
> >> > >> >
> >> > >> > @QueryHandler
> >> > >> > public interface PersonDAO {
> >> > >> > //...
> >> > >> > }
> >> > >> >
> >> > >> > When the container finds this interface it will
> > identify the
> >> > > appropriate
> >> > >> > InvocationHandler, based on the following matches:
> >> > >> >
> >> > >> > - Implements InvocationHandler
> >> > >>
> >> > >> Yes.
> >> > >>
> >> > >> > - Is annotated @QueryHandler
> >> > >>
> >> > >> Ish, this should follow standard CDI resolution rules, you
> > can copy
> >> the
> >> > >> way interceptor bindings work here.
> >> > >>
> >> > >> > - Is annotated @ServiceHandler
> >> > >>
> >> > >> Yes
> >> > >>
> >> > >> >
> >> > >> > DeltaSpike will provide a proxied object where all
> > abstract method
> >> > > calls
> >> > >> > are delegated to the InvocationHandler. The
> > InvocationHandler will
> >> > > need
> >> > >> to
> >> > >> > have logic to handle all methods as defined within the
> > class, as
> >> long
> >> > > as
> >> > >> > that method is invoked through the InvocationHandler.
> >> > >> >
> >> > >> > @QueryHandler @ServiceHandler
> >> > >> > public QueryHandlerInvoker implements InvocationHandler
> > {
> >> > >> >
> >> > >> > public Object invoke(Object proxy, Method method,
> > Object[] args) {
> >> > >> > if(method.getName().startsWith("find..."){
> >> > >> > //...
> >> > >> > }
> >> > >> > return null;
> >> > >> >
> >> > >> > }
> >> > >> > }
> >> > >> >
> >> > >> > In addition, the ServiceHandlerBinding can be placed on
> > an abstract
> >> > >> class.
> >> > >> > In this case, only abstract methods will be passed to
> > the
> >> > >> > InvocationHandler.
> >> > >> >
> >> > >> > @QueryHandler
> >> > >> > public abstract interface PersonDAO {
> >> > >> > public String doSomethingConcrete() {
> >> > >> > return "concrete";
> >> > >> > }
> >> > >> >
> >> > >> > public abstract Person find(int id);
> >> > >> > }
> >> > >> >
> >> > >> > Only the find method will be wrapped, the method
> >> doSomethingConcrete
> >> > > will
> >> > >> > be invoked directly. When interacting with an abstract
> > class, the
> >> > >> > InvocationHandler can call methods on the proxied
> > object.
> >> > >> >
> >> > >> > Finally, the app developer will be able to simply
> > inject their
> >> > >> > interface/abstract class in to their beans to perform
> > work:
> >> > >> >
> >> > >> > @Inject @QueryHandler PersonDAO dao;
> >> > >> >
> >> > >> > Questions:
> >> > >> >
> >> > >> > Should we provide a store (simple key/value map) to
> > keep a history
> >> of
> >> > >> found
> >> > >> > object types and how they map?
> >> > >>
> >> > >> You mean like BeanManager.resolveInterceptors() ? I guess
> > this is
> >> > useful.
> >> > >>
> >> > >> > Should we depend on certain libraries for proxying
> > (e.g.
> >> javassist, I
> >> > >> think
> >> > >> > both Weld & OWB use this still?)
> >> > >>
> >> > >> If you want to just cover interfaces, it's easy, you can
> > use proxying
> >> > > from
> >> > >> the JDK. Otherwise yes you need to pick a lib.
> >> > >>
> >> > >> Weld doesn't use javassist for proxying, but does for
> > other stuff.
> >> > >>
> >> > >> > Since we now use the interface InvocationHandler should
> > we rename
> >> the
> >> > >> > binding to be InvocationHandlerBinding?
> >> > >>
> >> > >> Yes, this makes sense
> >> > >>
> >> > >> > I also think it's not necessary to
> >> > >> > have @ServiceHandler since the marker interface now
> > exists.
> >> > >>
> >> > >> +1
> >> > >>
> >> > >> >
> >> > >> > Comments welcome..
> >> > >> >
> >> > >> > John
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> >> > > <lightguard.jp@gmail.com
> >> > >> >wrote:
> >> > >> >
> >> > >> >> +1 for @ServiceHandler
> >> > >> >>
> >> > >> >>
> >> > >> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> >> > > <john.d.ament@gmail.com
> >> > >> >>> wrote:
> >> > >> >>
> >> > >> >>> If we're still calling the feature
> >> > > "ServiceHandler" then why not
> >> > >> >>> @ServiceHandler?
> >> > >> >>>
> >> > >> >>>
> >> > >> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain
> > Manni-Bucau
> >> > >> >>> <rm...@gmail.com>wrote:
> >> > >> >>>
> >> > >> >>>> if we don't need it perfect, if we need
> > it we'll
> >> > > just use another name
> >> > >> >>>> @DSHandler, @Handler...whatever it is ;)
> >> > >> >>>>
> >> > >> >>>> Romain Manni-Bucau
> >> > >> >>>> Twitter: @rmannibucau
> >> > >> >>>> Blog: http://rmannibucau.wordpress.com/
> >> > >> >>>> LinkedIn:
> > http://fr.linkedin.com/in/rmannibucau
> >> > >> >>>> Github: https://github.com/rmannibucau
> >> > >> >>>>
> >> > >> >>>>
> >> > >> >>>>
> >> > >> >>>> 2012/12/20 Pete Muir
> > <pm...@redhat.com>:
> >> > >> >>>>> :-) Yes for sure. I suspect we
> > dont' need
> >> > > @InvocationHandler at all.
> >> > >> >>>>>
> >> > >> >>>>> On 20 Dec 2012, at 16:30, John D. Ament
> > wrote:
> >> > >> >>>>>
> >> > >> >>>>>> The problem I have is that now
> > InvocationHandler
> >> > > is both an
> >> > >> >> interface
> >> > >> >>>> and
> >> > >> >>>>>> an @interface which will make it
> > impossible for
> >> > > imports. I don't
> >> > >> >>> think
> >> > >> >>>>>> they should have the same name.
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM,
> > Pete Muir
> >> > > <pm...@redhat.com>
> >> > >> >> wrote:
> >> > >> >>>>>>
> >> > >> >>>>>>>
> >> > >> >>>>>>> On 20 Dec 2012, at 12:32, John
> > D. Ament wrote:
> >> > >> >>>>>>>
> >> > >> >>>>>>>> All,
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> So mostly ok from my
> > perspective. One
> >> > > thing to note:
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> @InvocationHandlerBinding
> >> > >> >>>>>>>> public @interface
> > Repository {}
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> @Repository
> >> > >> >>>>>>>> public interface
> > MyRepository {
> >> > >> >>>>>>>> ...
> >> > >> >>>>>>>> }
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> @Repository
> > @InvocationHandler
> >> > >> >>>>>>>> public class
> > MyInvocationHandler
> >> > > implements InvocationHandler {
> >> > >> >>>>>>>> ...
> >> > >> >>>>>>>> }
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Why do we have a
> > @InvocationHandler here?
> >> > > Is it supposed to be
> >> > >> >>>>>>>> @InvocationHandlerBinding
> > instead? If so,
> >> > > is it really needed
> >> > >> >> here?
> >> > >> >>>>>>>
> >> > >> >>>>>>> No, it should be
> > @InvocationHandler, it's
> >> > > analagous to
> >> > >> >> @Interceptor.
> >> > >> >>>> It's
> >> > >> >>>>>>> not 100% necessary as we
> > already implement the
> >> > > interface, which is
> >> > >> >>>> enough
> >> > >> >>>>>>> of the marker.
> >> > >> >>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Thinking about the
> > implementation for
> >> > > this, I think this actually
> >> > >> >>>> becomes
> >> > >> >>>>>>>> easier to use and easier to
> > understand
> >> > > over the Solder solution.
> >> > >> >>> The
> >> > >> >>>>>>>> implementation of the
> > InvocationHandler
> >> > > becomes a true CDI bean.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Should DS support
> > Interceptors and
> >> > > Decorators on
> >> > >> >>>>>>>> InvocationHandler beans?
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Do you mean the
> > implementation class or
> >> > > the interface?
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> John
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> On Thu, Dec 20, 2012 at
> > 7:06 AM, Romain
> >> > > Manni-Bucau
> >> > >> >>>>>>>>
> > <rm...@gmail.com>wrote:
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>> i'd rather say no
> > because the idea
> >> > > is to ease "util" extension
> >> > >> >>>>>>>>> writing. that's
> > clearly not
> >> > > intended to be full business beans
> >> > >> >> IMO
> >> > >> >>>> (at
> >> > >> >>>>>>>>> least for a first step)
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> That's why i'd
> > leave it as
> >> > > this for now
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> wdyt?
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> Romain Manni-Bucau
> >> > >> >>>>>>>>> Twitter: @rmannibucau
> >> > >> >>>>>>>>> Blog:
> >> > > http://rmannibucau.wordpress.com/
> >> > >> >>>>>>>>> LinkedIn:
> >> > > http://fr.linkedin.com/in/rmannibucau
> >> > >> >>>>>>>>> Github:
> > https://github.com/rmannibucau
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> 2012/12/20 Arne Limburg
> >> > > <ar...@openknowledge.de>:
> >> > >> >>>>>>>>>> Mark refers to my
> > call stack.
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> Out of the box this
> > call stack
> >> > > would exist just in OWB, because
> >> > >> >>> Weld
> >> > >> >>>>>>>>> would
> >> > >> >>>>>>>>>> not apply any
> > Interceptors or
> >> > > Decorators...
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> The question is:
> > Should DS support
> >> > > Interceptors and Decorators
> >> > >> >> on
> >> > >> >>>>>>>>>> InvocationHandler
> > beans? My answer
> >> > > would be: yes, if our
> >> > >> >>>> implementation
> >> > >> >>>>>>>>>> shall be a preview
> > of CDI-110.
> >> > >> >>>>>>>>>> And that would make
> > things
> >> > > complicated in the implementation...
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> Am 20.12.12 12:11
> > schrieb
> >> > > "Romain Manni-Bucau" unter
> >> > >> >>>>>>>>>>
> > <rm...@gmail.com>:
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>>> is it an issue
> > for
> >> > > servicehandler? i don't think so
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>> it is often
> > used to get util
> >> > > classes dynamically created, it is
> >> > >> >>>> rarely
> >> > >> >>>>>>>>>>> (i never saw
> > it) decorated
> >> > > directly
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>> Romain
> > Manni-Bucau
> >> > >> >>>>>>>>>>> Twitter:
> > @rmannibucau
> >> > >> >>>>>>>>>>> Blog:
> >> > > http://rmannibucau.wordpress.com/
> >> > >> >>>>>>>>>>> LinkedIn:
> >> > > http://fr.linkedin.com/in/rmannibucau
> >> > >> >>>>>>>>>>> Github:
> >> > > https://github.com/rmannibucau
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>>
> >> > >> >>>>>>>>>>> 2012/12/20 Mark
> > Struberg
> >> > > <st...@yahoo.de>:
> >> > >> >>>>>>>>>>>> we stumbled
> > about this
> >> > > lately. It seems CDI only forces
> >> > >> >> support
> >> > >> >>>> for
> >> > >> >>>>>>>>>>>>
> > interceptors and
> >> > > decorators for CDI-annotated classes, but not
> >> > >> >>> for
> >> > >> >>>>>>>>>>>>
> > Bean<T> which get
> >> > > added via extensions nor even producer
> >> > >> >> methods
> >> > >> >>>> and
> >> > >> >>>>>>>>>>>> fields :/
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>> Of course
> > OWB does it, but
> >> > > it would be not portable...
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>> LieGrue,
> >> > >> >>>>>>>>>>>> strub
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>
> >> > >> >>>>>>>>>>>> -----
> > Original Message
> >> > > -----
> >> > >> >>>>>>>>>>>>> From:
> > Arne Limburg
> >> > > <ar...@openknowledge.de>
> >> > >> >>>>>>>>>>>>> To:
> >> > > "deltaspike-dev@incubator.apache.org"
> >> > >> >>>>>>>>>>>>>
> >> > > <de...@incubator.apache.org>
> >> > >> >>>>>>>>>>>>> Cc:
> >> > >> >>>>>>>>>>>>> Sent:
> > Thursday,
> >> > > December 20, 2012 10:18 AM
> >> > >> >>>>>>>>>>>>>
> > Subject: Re: [DISCUSS]
> >> > > [DELTASPIKE-113] Review and Discuss
> >> > >> >>>>>>>>>>>>>
> > ServiceHandler
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> T wo
> > things about
> >> > > this: First: I don't like from the solder
> >> > >> >>>>>>> approach,
> >> > >> >>>>>>>>>>>>> because
> > the interface
> >> > > is annotated instead of the
> >> > >> >>> implementation.
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Second,
> > if we
> >> > > implement this we should conceptually make
> >> > >> >> clear
> >> > >> >>>> how
> >> > >> >>>>>>> it
> >> > >> >>>>>>>>>>>>>
> > differentiates from
> >> > > Interceptors and Decorators. And
> >> > >> >>> personally I
> >> > >> >>>>>>>>> think
> >> > >> >>>>>>>>>>>>> this
> > would work better
> >> > > with the InvocationHandler approach
> >> > >> >> than
> >> > >> >>>> with
> >> > >> >>>>>>>>> an
> >> > >> >>>>>>>>>>>>>
> > approach that is very
> >> > > similar to interceptors.
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> So +1
> > for an approach
> >> > > like this:
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> >> > > @HandlesInvocationsOn(MyInterface.class)
> >> > >> >>>>>>>>>>>>> public
> > class
> >> > > MyInvocationHandler implements
> >> > >> >> InvocationHandler {
> >> > >> >>>>>>>>>>>>> ...
> >> > >> >>>>>>>>>>>>> }
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > Technically we would
> >> > > register a custom Bean for every found
> >> > >> >>>>>>>>>>>>>
> > InvocationHandler with
> >> > > that annotation and take over the
> >> > >> >>>>>>>>>>>>>
> > interceptor-bindings
> >> > > from the interfaceŠ
> >> > >> >>>>>>>>>>>>> So the
> > invocation
> >> > > stack would be clear, too:
> >> > >> >>>>>>>>>>>>> First
> > Interceptors,
> >> > >> >>>>>>>>>>>>> Second
> > Decorators,
> >> > >> >>>>>>>>>>>>> Third
> >> > > InvocationHandler
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Wdyt?
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Arne
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Am
> > 20.12.12 01:53
> >> > > schrieb "Romain Manni-Bucau" unter
> >> > >> >>>>>>>>>>>>>
> >> > > <rm...@gmail.com>:
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>> +1
> >> > >> >>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>
> > that's a need,
> >> > > DS targets CDI 1.0 for now so just make this
> >> > >> >>>> solder
> >> > >> >>>>>>>>>>>>>>
> > part portable ans
> >> > > it should be fine
> >> > >> >>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>
> > Romain Manni-Bucau
> >> > >> >>>>>>>>>>>>>>
> > Twitter:
> >> > > @rmannibucau
> >> > >> >>>>>>>>>>>>>>
> > Blog:
> >> > > http://rmannibucau.wordpress.com/
> >> > >> >>>>>>>>>>>>>>
> > LinkedIn:
> >> > > http://fr.linkedin.com/in/rmannibucau
> >> > >> >>>>>>>>>>>>>>
> > Github:
> >> > > https://github.com/rmannibucau
> >> > >> >>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>
> > 2012/12/20 Jason
> >> > > Porter <li...@gmail.com>:
> >> > >> >>>>>>>>>>>>>>>
> > At this point,
> >> > > I'd say just do it as is in solder.
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> > On Wed, Dec
> >> > > 19, 2012 at 5:25 PM, John D. Ament
> >> > >> >>>>>>>>>>>>>>>
> >> > > <jo...@gmail.com>wrote:
> >> > >> >>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> Hi All,
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> Regarding
> >> > > the two open questions:
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> 1) the
> >> > > approach (including the name/s) we agree on will be
> >> > >> >>>> used
> >> > >> >>>>>>>>>>>>> also
> >> > >>
> >>>>>>>>>>>>>>>>> for
> >> > >>
> >>>>>>>>>>>>>>>>> cdi 1.1
> >> > > (the only difference is the package)
> >> > >>
> >>>>>>>>>>>>>>>>> 2) the eg
> >> > > has a different opinion about it ->
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> It looks
> >> > > like the JSR's answer
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > (https://issues.jboss.org/browse/CDI-110 )
> >> > >>
> >>>>>>>>>>>>>>>>> is still
> >> > > unresolved - I'm not sure if we can get any
> >> > >> >> further
> >> > >> >>>>>>>>>>>>> answer
> > at
> >> > >>
> >>>>>>>>>>>>>>>>> this
> >> > >>
> >>>>>>>>>>>>>>>>> time. The
> >> > > last posts on the subject seem to discuss using
> >> > >> >>>>>>>>>>>>>
> > something
> >> > >>
> >>>>>>>>>>>>>>>>> along
> >> > >>
> >>>>>>>>>>>>>>>>> the lines
> >> > > of an invocation handler, which I think would
> >> > >> >> work
> >> > >> >>>>>>> well.
> >> > >>
> >>>>>>>>>>>>>>>>> Since
> >> > >>
> >>>>>>>>>>>>>>>>> we have
> >> > > some features coming up that are interested in
> >> > >> >>> having
> >> > >> >>>>>>>>>>>>> service
> >> > >>
> >>>>>>>>>>>>>>>>> handlers
> >> > > available, do we
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> 1.
> >> > > Implement as is, or similar to, what is currently in
> >> > >> >>>> Solder?
> >> > >>
> >>>>>>>>>>>>>>>>> 2. Push EG
> >> > > on a resolution
> >> > >>
> >>>>>>>>>>>>>>>>> 3. Do it
> >> > > using invocation handlers.
> >> > >>
> >>>>>>>>>>>>>>>>> 4. Do it
> >> > > some other way?
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> John
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>> On Wed,
> >> > > Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > gerhard.petracek@gmail.com
> >> > >>
> >>>>>>>>>>>>>>>>>> wrote:
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>> hi
> >> > > john,
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>> as
> >> > > mentioned before we need the answers to the existing
> >> > >> >>>>>>>>>>>>>
> > questions.
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > 2012/4/4 John D. Ament <jo...@gmail.com>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > All,
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>> I
> >> > > kind of let this one and the other drop off my radar,
> >> > >> >> I
> >> > >>
> >>>>>>>>>>>>>>>>> apologize.
> >> > >>
> >>>>>>>>>>>>>>>>> it
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > looks like where we last left off, Gerhard was still
> >> > >> >>>>>>>>>>>>>
> > requesting
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > additional
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > comments from everyone. Any other feedback?
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > John
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>> On
> >> > > Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > gerhard.petracek@gmail.com> wrote:
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> > hi
> >> > > george,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> > thx
> >> > > for the information. i thought there might be at
> >> > >> >>>>>>>>>>>>> least
> > some
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > additional
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > answers/clarifications, since pete asked for them in
> >> > >> >>>>>>>>>>>>> several
> >> > >>
> >>>>>>>>>>>>>>>>> comments.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > -> imo we should continue with them.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/12 George Gastaldi
> >> > >> >>>>>>>>>>>>>
> >> > > <ge...@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > Hello Gerhard,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > Yeah, it´s the last state. I know it´s quite
> >> > >> >>>>>>>>>>>>> old,
> > but I
> >> > >>
> >>>>>>>>>>>>>>>>> haven´t
> >> > > had
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > time
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > to work on it after that.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > Regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > George
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/12 Gerhard Petracek
> >> > >> >>>>>>>>>>>>>
> >> > > <ge...@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > hi george,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > thx for the link.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > i'm not sure if it is the latest state
> >> > >> >>>>>>>>>>>>> of your
> > discussion
> >> > >>
> >>>>>>>>>>>>>>>>> and/or
> >> > >>
> >>>>>>>>>>>>>>>>>> draft
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > (at least it's quite old already).
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/7 George Gastaldi
> >> > >> >>>>>>>>>>>>>
> >> > > <ge...@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Hi !
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > +1 to #1. I also agree that the term
> >> > >> >>>>>>>>>>>>>
> > "Service
> >> > > Handler" might
> >> > >>
> >>>>>>>>>>>>>>>>> not
> >> > >>
> >>>>>>>>>>>>>>>>> be
> >> > >>
> >>>>>>>>>>>>>>>>>>> so
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > appropriate, so it should be discussed
> >> > >> >>>>>>>>>>>>> as
> > well.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Here is the latest pull request with
> >> > >> >>>>>>>>>>>>> some
> > comments from
> >> > > Pete
> >> > >>
> >>>>>>>>>>>>>>>>> yet
> >> > >>
> >>>>>>>>>>>>>>>>> to
> >> > >>
> >>>>>>>>>>>>>>>>>>> be
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > reviewed:
> >> > >> >>>>>>>>>>>>>
> >> > > https://github.com/jboss/cdi/pull/28
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/7 Pete Muir
> >> > >> >>>>>>>>>>>>>
> >> > > <pm...@redhat.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Agreed :-)
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > George is working on it for CDI
> >> > >> >>>>>>>>>>>>> 1.1.
> > George, can you
> >> > > share
> >> > >>
> >>>>>>>>>>>>>>>>> your
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > proposal
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > so far?
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On 7 Mar 2012, at 17:05, Gerhard
> >> > >> >>>>>>>>>>>>>
> > Petracek wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > hi pete,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > independent of my opinion
> >> > >> >>>>>>>>>>>>> about
> > the feature
> >> > > (which is
> >> > >>
> >>>>>>>>>>>>>>>>> still
> >> > >>
> >>>>>>>>>>>>>>>>>> +0):
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > if it should be part of cdi
> >> > >> >>>>>>>>>>>>> 1.1, we
> > have the
> >> > > following
> >> > >>
> >>>>>>>>>>>>>>>>> options
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > imo:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 1) the approach (including
> >> > >> >>>>>>>>>>>>> the
> > name/s) we agree
> >> > > on will
> >> > >>
> >>>>>>>>>>>>>>>>> be
> >> > >>
> >>>>>>>>>>>>>>>>> used
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > also
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > for
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > cdi 1.1 (the only difference
> >> > >> >>>>>>>>>>>>> is the
> > package)
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2) the eg has a different
> >> > >> >>>>>>>>>>>>> opinion
> > about it ->
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2a) the rest of the eg joins
> >> > >> >>>>>>>>>>>>> this
> > discussion
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2b) we wait for the final
> >> > >> >>>>>>>>>>>>> version
> > and just allow
> >> > > the same
> >> > >>
> >>>>>>>>>>>>>>>>> with
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > cdi
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 1.0
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 3) if the eg doesn't
> >> > >> >>>>>>>>>>>>> agree
> > on the idea, it
> >> > > should be
> >> > >>
> >>>>>>>>>>>>>>>>> re-visited
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > for
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > deltaspike (if we really need
> >> > >> >>>>>>>>>>>>> it)
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 4) we agree on it independent
> >> > >> >>>>>>>>>>>>> of the
> > result in cdi
> >> > > 1.1
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 1-3 is ok for me but -1 for
> >> > >> >>>>>>>>>>>>> #4
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/7 Pete Muir
> >> > >> >>>>>>>>>>>>>
> >> > > <pm...@redhat.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > I'm not sure what you
> >> > >> >>>>>>>>>>>>> mean by
> > a "super
> >> > > interceptor",
> >> > >>
> >>>>>>>>>>>>>>>>> but if
> >> > >>
> >>>>>>>>>>>>>>>>>> you
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > mean it
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > as
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > in "super man"
> >> > >> >>>>>>>>>>>>>
> > (something better than
> >> > > an interceptor),
> >> > >>
> >>>>>>>>>>>>>>>>> then
> >> > >>
> >>>>>>>>>>>>>>>>> I
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > would
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > disagree, it's
> >> > >> >>>>>>>>>>>>>
> > actually a specialised
> >> > > form of
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > interceptor.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > The best use case I know
> >> > >> >>>>>>>>>>>>> of is
> > the one John
> >> > > mentions -
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > creating
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > type
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > safe
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > references to queries:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > @QueryService
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > interface UserQuery {
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > @Query("select u
> >> > >> >>>>>>>>>>>>> from
> > User u")
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > public List<User>
> >> > >> >>>>>>>>>>>>>
> > getAllUsers();
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > @Query("select u
> >> > >> >>>>>>>>>>>>> from
> > User u order by
> >> > > u.name")
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > public List<User>
> >> > >> >>>>>>>>>>>>>
> >> > > getAllUsersSortedByName();
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > }
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Now, it may be the case
> >> > >> >>>>>>>>>>>>> that
> > there aren't
> >> > > any other use
> >> > >>
> >>>>>>>>>>>>>>>>> cases
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > for
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > service
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > handlers, in which case
> >> > >> >>>>>>>>>>>>> we
> > should perhaps just
> >> > > offer
> >> > >>
> >>>>>>>>>>>>>>>>> this
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > particular
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > service handler -
> >> > >> >>>>>>>>>>>>>
> > references to type
> >> > > safe queries - as I
> >> > >>
> >>>>>>>>>>>>>>>>> think
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > this
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > is
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > an
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > extremely powerful idea.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Note, that at the moment
> >> > >> >>>>>>>>>>>>> service
> > handlers are
> >> > > scheduled
> >> > >>
> >>>>>>>>>>>>>>>>> for
> >> > >>
> >>>>>>>>>>>>>>>>>> CDI
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > 1.1.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On 7 Mar 2012, at 02:35,
> >> > >> >>>>>>>>>>>>> Jason
> > Porter wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Somewhat. I
> >> > >> >>>>>>>>>>>>>
> > wouldn't really
> >> > > think of them as overrides,
> >> > >>
> >>>>>>>>>>>>>>>>> they,
> >> > >>
> >>>>>>>>>>>>>>>>>>> to
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > me,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > seem more like items to
> >> > >> >>>>>>>>>>>>> do in
> > addition to
> >> > > whatever the
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > original
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > impl
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > does.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > ServiceHandlers to me
> >> > >> >>>>>>>>>>>>> seem
> > more like super
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > interceptors.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Sent from my iPhone
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On Mar 6, 2012, at
> >> > >> >>>>>>>>>>>>> 19:23,
> > "John D.
> >> > > Ament" <
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > john.d.ament@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > @jason
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > I think the
> >> > >> >>>>>>>>>>>>>
> > concepts are very
> >> > > dissimilar.
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > servicehandlers
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > create
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > implementation.
> >> > >> >>>>>>>>>>>>>
> > delegates are more
> >> > > like overrides and
> >> > >>
> >>>>>>>>>>>>>>>>> need
> >> > >>
> >>>>>>>>>>>>>>>>>> to
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > know
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > about
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the method
> >> > >> >>>>>>>>>>>>>
> > signature.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On Tue, Mar 6,
> >> > >> >>>>>>>>>>>>> 2012 at
> > 9:17 PM, Jason
> >> > > Porter <
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > lightguard.jp@gmail.com
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > I think the
> >> > >> >>>>>>>>>>>>> idea of
> >> > > ServiceHandlers are good, but,
> >> > >>
> >>>>>>>>>>>>>>>>> could
> >> > >>
> >>>>>>>>>>>>>>>>> we
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > not
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > do
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > this
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > with
> >> > >> >>>>>>>>>>>>>
> > delegates?
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Sent from my
> >> > >> >>>>>>>>>>>>> iPhone
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On Mar 6,
> >> > >> >>>>>>>>>>>>> 2012,
> > at 19:05,
> >> > > "John D. Ament" <
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > john.d.ament@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > @mark
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > I
> >> > >> >>>>>>>>>>>>>
> > don't think
> >> > > it's a hard requirement for it to be
> >> > >>
> >>>>>>>>>>>>>>>>> on an
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > interface.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > One of
> >> > >> >>>>>>>>>>>>> the
> > best use-cases we
> >> > > built at my job is
> >> > >>
> >>>>>>>>>>>>>>>>> using it
> >> > >>
> >>>>>>>>>>>>>>>>>> for
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > calling
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > PL/SQL.
> >> > >> >>>>>>>>>>>>> The
> > JDBC bindings do
> >> > > work, but not pretty.
> >> > >>
> >>>>>>>>>>>>>>>>> we
> >> > >>
> >>>>>>>>>>>>>>>>>> were
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > able to
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > create
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > a fairly
> >> > >> >>>>>>>>>>>>> clean
> > wrapper API,
> >> > > generic enough for
> >> > >>
> >>>>>>>>>>>>>>>>> binding
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > in/out
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > parameters.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > JOhn
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On Tue,
> >> > >> >>>>>>>>>>>>> Mar 6,
> > 2012 at 12:58
> >> > > PM, Mark Struberg <
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > struberg@yahoo.de>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > actually I don't
> >> > > really see a real benefit. I just
> >> > >>
> >>>>>>>>>>>>>>>>> don't
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > yet
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > grok
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > use
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > case
> >> > >> >>>>>>>>>>>>> for
> > real world
> >> > > projects.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Why
> >> > >> >>>>>>>>>>>>> would
> > one intercept an
> >> > > Interface and delegate
> >> > >>
> >>>>>>>>>>>>>>>>> the
> >> > >>
> >>>>>>>>>>>>>>>>>> calls
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> > to
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > a
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > method
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > handler?
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > This
> >> > >> >>>>>>>>>>>>> could
> > be neat for
> >> > > mocking, but there are
> >> > >>
> >>>>>>>>>>>>>>>>> better
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > frameworks for
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > that.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > thus
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > -0.2
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > LieGrue,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > strub
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > -----
> >> > >> >>>>>>>>>>>>>
> > Original Message -----
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> From:
> > Gerhard Petracek
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > <ge...@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> To:
> >> > > deltaspike-dev@incubator.apache.org
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Cc:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> Sent:
> > Tuesday, March
> >> > > 6, 2012 5:15 PM
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > Subject: Re: [DISCUSS]
> >> > > [DELTASPIKE-113] Review and
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > Discuss
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > ServiceHandler
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> if you
> > have a lot of
> >> > > shared code, you can extract
> >> > >>
> >>>>>>>>>>>>>>>>> it
> >> > >>
> >>>>>>>>>>>>>>>>> in
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > 1-n
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > method/s or
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > an
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > abstract class which
> >> > > is still easier than a new
> >> > >>
> >>>>>>>>>>>>>>>>> concept.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> at
> > least i haven't
> >> > > seen an use-case which really
> >> > >>
> >>>>>>>>>>>>>>>>> needed
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > it.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > that
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > was
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> reason
> > for a +0 (which
> >> > > still means that i'm ok
> >> > >>
> >>>>>>>>>>>>>>>>> with
> >> > >>
> >>>>>>>>>>>>>>>>>> adding
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > it).
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > 2012/3/6 Pete Muir
> >> > > <pm...@redhat.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > So, you mean just write a bean with all the
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > boilerplate
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > code
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > in
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > it?
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On 6 Mar 2012, at 15:58, Gerhard Petracek
> >> > >> >>>>>>>>>>>>> wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > hi pete,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > instead of the interface you can just
> >> > >> >>>>>>>>>>>>>
> > implement
> >> > >>
> >>>>>>>>>>>>>>>>> a
> >> > >>
> >>>>>>>>>>>>>>>>> bean
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > > which
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > does
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > same.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/6 Pete Muir
> >> > >> >>>>>>>>>>>>>
> >> > > <pm...@redhat.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > What CDI mechanism would you use
> >> > >> >>>>>>>>>>>>>
> > instead?
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > On 5 Mar 2012, at 08:47, Gerhard
> >> > >> >>>>>>>>>>>>>
> > Petracek
> >> > >>
> >>>>>>>>>>>>>>>>> wrote:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > +0
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > no -1 because there are
> >> > >> >>>>>>>>>>>>>
> > use-cases for it.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > no +1 because i would use std.
> >> > >> >>>>>>>>>>>>> cdi
> > mechanisms
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > instead.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/4 Gerhard Petracek <
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > gerhard.petracek@gmail.com
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > hi john,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the sub-task is perfectly
> >> > >> >>>>>>>>>>>>> fine.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > gerhard
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > 2012/3/4 John D. Ament
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > <jo...@gmail.com>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Hi All
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > I wanted to bring up
> >> > >> >>>>>>>>>>>>> the
> > subject of
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > > ServiceHandler.
> >> > >>
> >>>>>>>>>>>>>>>>>>> I
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> added
> > 113 as a
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > child
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > of DELTASPIKE-2, looked
> >> > >> >>>>>>>>>>>>>
> > appropriate but not
> >> > >>
> >>>>>>>>>>>>>>>>> 100%
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > sure
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> (so
> > please let
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > me
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > know if you think
> >> > >> >>>>>>>>>>>>>
> > it's not
> >> > > appropriate as a
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> child).
> >> > > ServiceHandler
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > is
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > a
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > feature in Solder that
> >> > >> >>>>>>>>>>>>> allows
> > you to define
> >> > >>
> >>>>>>>>>>>>>>>>> an
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > interceptor that
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > manages
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > generic calls against
> >> > >> >>>>>>>>>>>>> an
> > injected interface.
> >> > >>
> >>>>>>>>>>>>>>>>> The
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > API
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> is as
> > follows:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > -
> >> > >> >>>>>>>>>>>>>
> >> > > @ServiceHandlerType(Class<?> clazz) -
> >> > >>
> >>>>>>>>>>>>>>>>> placed
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> on an
> > annotation that
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > would
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > be placed on the
> >> > >> >>>>>>>>>>>>>
> > interface. Indicates
> >> > > what
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > interceptor would be
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > invoked
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > for calls against this
> >> > >> >>>>>>>>>>>>>
> > interface.
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > It's then up to the
> >> > >> >>>>>>>>>>>>>
> > application
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > developer/framework
> >> > > author to define
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > annotations that go on
> >> > >> >>>>>>>>>>>>>
> > methods, as well as
> >> > >>
> >>>>>>>>>>>>>>>>> the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>
> > interceptor itself
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > > that
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > will
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > be invoked. The
> >> > >> >>>>>>>>>>>>> feature
> > for
> >> > > ServiceHandler
> >> > >>
> >>>>>>>>>>>>>>>>> would
> >> > >>
> >>>>>>>>>>>>>>>>>> be
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> to
> > provide the
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > API of
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > the type and then the
> >> > >> >>>>>>>>>>>>>
> > infrastructure
> >> > >>
> >>>>>>>>>>>>>>>>> required
> >> > > to
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > > make
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>> the
> > interceptor
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > be
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > called. Existing
> >> > >> >>>>>>>>>>>>>
> > documentation of the
> >> > >>
> >>>>>>>>>>>>>>>>> feature:
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>
> >> > >
> > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >> > >>
> >>>>>>>>>>>>>>>>> ser
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > > vicehandler.html
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > Regards,
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > > john
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >> >
> >>>>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>>
> >> > >>
> >>>>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> > --
> >> > >> >>>>>>>>>>>>>>>
> > Jason Porter
> >> > >> >>>>>>>>>>>>>>>
> >> > > http://lightguard-jp.blogspot.com
> >> > >> >>>>>>>>>>>>>>>
> >> > > http://twitter.com/lightguardjp
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> > Software
> >> > > Engineer
> >> > >> >>>>>>>>>>>>>>>
> > Open Source
> >> > > Advocate
> >> > >> >>>>>>>>>>>>>>>
> >> > >> >>>>>>>>>>>>>>>
> > PGP key id:
> >> > > 926CCFF5
> >> > >> >>>>>>>>>>>>>>>
> > PGP key
> >> > > available at: keyserver.net, pgp.mit.edu
> >> > >> >>>>>>>>>>>>>
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>
> >> > >> >>>>>>>
> >> > >> >>>>>
> >> > >> >>>>
> >> > >> >>>
> >> > >> >>
> >> > >> >>
> >> > >> >>
> >> > >> >> --
> >> > >> >> Jason Porter
> >> > >> >> http://lightguard-jp.blogspot.com
> >> > >> >> http://twitter.com/lightguardjp
> >> > >> >>
> >> > >> >> Software Engineer
> >> > >> >> Open Source Advocate
> >> > >> >>
> >> > >> >> PGP key id: 926CCFF5
> >> > >> >> PGP key available at: keyserver.net, pgp.mit.edu
> >> > >> >>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
Well, the big difference (apart from working on interfaces/abstract classes and not on distinct instances) is that CDI Interceptors and Decorators are defined as being @Dependent _on that particular instance_!
This cannot be done in a portable way via an Extension as any @Dependent instances are stored in _and later restored from_ the CreationalContext. But there is no way to get an instance from the CreationalContext in a portable way.
Thus either the handler has a specific NormalScope or if it's @Dependent we must create it for each method invocation. And of course (this is the part which most of the time is missing in other CDI extensions) we also must properly clean it up after each method invocation if the scope is @Dependent.
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Sunday, December 23, 2012 8:37 PM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>
> imo it should be as simple as possible, because so far we just heard one
> use-case for which it really makes sense (DELTASPIKE-60 + abstract classes).
> -> the following should be enough:
>
> @InvocationHandlerBinding
> public @interface GenericDaoHandler {
> }
>
> @GenericDaoHandler
> public GenericDaoHandlerImpl implements InvocationHandler {
> //...
> }
>
> @GenericDaoHandler
> @ApplicationScoped //or any other scope
> public abstract class PersonDao { //or interface
> //...
> }
>
> @mark:
> in the end it's just like an interceptor, but it just executes the
> interceptor logic (without InvocationContext#proceed) >or< the implemented
> method provided via an abstract class.
>
> regards,
> gerhard
>
>
>
> 2012/12/23 John D. Ament <jo...@gmail.com>
>
>> Well, this object is used for a specific case. In my opinion, you should be
>> able to resolve it using
>>
>> @Inject @QueryHandler
>> private InvocationHandler queryHandler;
>>
>> Though why you may want to inject it in a client app is unknown to me; it
>> does make it easier from an implementation standpoint.
>>
>> Does the service handler need to have any specific scope? Can it inherit
>> the scope of what it's handling? I guess not, since it could be a
> handler
>> to n things. NormalScope would be appropriate then.
>>
>>
>> On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de>
> wrote:
>>
>> > I guess because it might overlap with other qualifiers added in some
>> cases.
>> >
>> > What do we gain for making it a qualifier?
>> >
>> > Another important difference to CDI interceptors is that they are
> always
>> > @Dependent to the intercepted instance.
>> > Whereas the ServiceHandler should be of NormalScope, isn't?
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> > > From: John D. Ament <jo...@gmail.com>
>> > > To: deltaspike-dev@incubator.apache.org
>> > > Cc:
>> > > Sent: Saturday, December 22, 2012 7:56 PM
>> > > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>> ServiceHandler
>> > >
>> > > Pete,
>> > >
>> > > Regarding interceptors - I think what I have is pretty close to
> the
>> > > interceptor definition, except this should only end up working on
> a
>> > > class/interface (I think?)
>> > >
>> > > Also, why wouldn't we want the annotation to also be a
> qualifier?
>> > >
>> > > John
>> > >
>> > >
>> > > On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir
> <pm...@redhat.com> wrote:
>> > >
>> > >>
>> > >> On 21 Dec 2012, at 02:21, John D. Ament wrote:
>> > >>
>> > >> > Hi all,
>> > >> >
>> > >> > So just to summarize the current proposal:
>> > >> >
>> > >> > - Create a new annotation @ServiceHandlerBinding (in
> core/api)
>> which
>> > > will
>> > >> > be placed on on the interface that defines points of
> the
>> > >> > - Create a new annotation @ServiceHandler (in core/api)
> (I think
>> > based
>> > > on
>> > >> > below this isn't needed since we have the interface
> now).
>> > >> > - Create an extension that can generate object proxies
> that link
>> > calls
>> > > to
>> > >> > methods on the - org.apache.deltaspike.core.api....
>> > >> >
>> > >> > Define the binding type annotation:
>> > >> >
>> > >> > @ServiceHandlerBinding
>> > >> > @Qualifier
>> > >> > public @interface QueryHandler {
>> > >> > }
>> > >>
>> > >> I don't think we want @Qualifier here.
>> > >>
>> > >> >
>> > >> > which will define the relationship between the
> interface/abstract
>> > > class
>> > >> > that will use the service handler and the class that
> will serve as
>> > the
>> > >> > invocation handler.
>> > >> >
>> > >> > For example, we can use @QueryHandler on an interface:
>> > >> >
>> > >> > @QueryHandler
>> > >> > public interface PersonDAO {
>> > >> > //...
>> > >> > }
>> > >> >
>> > >> > When the container finds this interface it will
> identify the
>> > > appropriate
>> > >> > InvocationHandler, based on the following matches:
>> > >> >
>> > >> > - Implements InvocationHandler
>> > >>
>> > >> Yes.
>> > >>
>> > >> > - Is annotated @QueryHandler
>> > >>
>> > >> Ish, this should follow standard CDI resolution rules, you
> can copy
>> the
>> > >> way interceptor bindings work here.
>> > >>
>> > >> > - Is annotated @ServiceHandler
>> > >>
>> > >> Yes
>> > >>
>> > >> >
>> > >> > DeltaSpike will provide a proxied object where all
> abstract method
>> > > calls
>> > >> > are delegated to the InvocationHandler. The
> InvocationHandler will
>> > > need
>> > >> to
>> > >> > have logic to handle all methods as defined within the
> class, as
>> long
>> > > as
>> > >> > that method is invoked through the InvocationHandler.
>> > >> >
>> > >> > @QueryHandler @ServiceHandler
>> > >> > public QueryHandlerInvoker implements InvocationHandler
> {
>> > >> >
>> > >> > public Object invoke(Object proxy, Method method,
> Object[] args) {
>> > >> > if(method.getName().startsWith("find..."){
>> > >> > //...
>> > >> > }
>> > >> > return null;
>> > >> >
>> > >> > }
>> > >> > }
>> > >> >
>> > >> > In addition, the ServiceHandlerBinding can be placed on
> an abstract
>> > >> class.
>> > >> > In this case, only abstract methods will be passed to
> the
>> > >> > InvocationHandler.
>> > >> >
>> > >> > @QueryHandler
>> > >> > public abstract interface PersonDAO {
>> > >> > public String doSomethingConcrete() {
>> > >> > return "concrete";
>> > >> > }
>> > >> >
>> > >> > public abstract Person find(int id);
>> > >> > }
>> > >> >
>> > >> > Only the find method will be wrapped, the method
>> doSomethingConcrete
>> > > will
>> > >> > be invoked directly. When interacting with an abstract
> class, the
>> > >> > InvocationHandler can call methods on the proxied
> object.
>> > >> >
>> > >> > Finally, the app developer will be able to simply
> inject their
>> > >> > interface/abstract class in to their beans to perform
> work:
>> > >> >
>> > >> > @Inject @QueryHandler PersonDAO dao;
>> > >> >
>> > >> > Questions:
>> > >> >
>> > >> > Should we provide a store (simple key/value map) to
> keep a history
>> of
>> > >> found
>> > >> > object types and how they map?
>> > >>
>> > >> You mean like BeanManager.resolveInterceptors() ? I guess
> this is
>> > useful.
>> > >>
>> > >> > Should we depend on certain libraries for proxying
> (e.g.
>> javassist, I
>> > >> think
>> > >> > both Weld & OWB use this still?)
>> > >>
>> > >> If you want to just cover interfaces, it's easy, you can
> use proxying
>> > > from
>> > >> the JDK. Otherwise yes you need to pick a lib.
>> > >>
>> > >> Weld doesn't use javassist for proxying, but does for
> other stuff.
>> > >>
>> > >> > Since we now use the interface InvocationHandler should
> we rename
>> the
>> > >> > binding to be InvocationHandlerBinding?
>> > >>
>> > >> Yes, this makes sense
>> > >>
>> > >> > I also think it's not necessary to
>> > >> > have @ServiceHandler since the marker interface now
> exists.
>> > >>
>> > >> +1
>> > >>
>> > >> >
>> > >> > Comments welcome..
>> > >> >
>> > >> > John
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
>> > > <lightguard.jp@gmail.com
>> > >> >wrote:
>> > >> >
>> > >> >> +1 for @ServiceHandler
>> > >> >>
>> > >> >>
>> > >> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
>> > > <john.d.ament@gmail.com
>> > >> >>> wrote:
>> > >> >>
>> > >> >>> If we're still calling the feature
>> > > "ServiceHandler" then why not
>> > >> >>> @ServiceHandler?
>> > >> >>>
>> > >> >>>
>> > >> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain
> Manni-Bucau
>> > >> >>> <rm...@gmail.com>wrote:
>> > >> >>>
>> > >> >>>> if we don't need it perfect, if we need
> it we'll
>> > > just use another name
>> > >> >>>> @DSHandler, @Handler...whatever it is ;)
>> > >> >>>>
>> > >> >>>> Romain Manni-Bucau
>> > >> >>>> Twitter: @rmannibucau
>> > >> >>>> Blog: http://rmannibucau.wordpress.com/
>> > >> >>>> LinkedIn:
> http://fr.linkedin.com/in/rmannibucau
>> > >> >>>> Github: https://github.com/rmannibucau
>> > >> >>>>
>> > >> >>>>
>> > >> >>>>
>> > >> >>>> 2012/12/20 Pete Muir
> <pm...@redhat.com>:
>> > >> >>>>> :-) Yes for sure. I suspect we
> dont' need
>> > > @InvocationHandler at all.
>> > >> >>>>>
>> > >> >>>>> On 20 Dec 2012, at 16:30, John D. Ament
> wrote:
>> > >> >>>>>
>> > >> >>>>>> The problem I have is that now
> InvocationHandler
>> > > is both an
>> > >> >> interface
>> > >> >>>> and
>> > >> >>>>>> an @interface which will make it
> impossible for
>> > > imports. I don't
>> > >> >>> think
>> > >> >>>>>> they should have the same name.
>> > >> >>>>>>
>> > >> >>>>>>
>> > >> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM,
> Pete Muir
>> > > <pm...@redhat.com>
>> > >> >> wrote:
>> > >> >>>>>>
>> > >> >>>>>>>
>> > >> >>>>>>> On 20 Dec 2012, at 12:32, John
> D. Ament wrote:
>> > >> >>>>>>>
>> > >> >>>>>>>> All,
>> > >> >>>>>>>>
>> > >> >>>>>>>> So mostly ok from my
> perspective. One
>> > > thing to note:
>> > >> >>>>>>>>
>> > >> >>>>>>>> @InvocationHandlerBinding
>> > >> >>>>>>>> public @interface
> Repository {}
>> > >> >>>>>>>>
>> > >> >>>>>>>> @Repository
>> > >> >>>>>>>> public interface
> MyRepository {
>> > >> >>>>>>>> ...
>> > >> >>>>>>>> }
>> > >> >>>>>>>>
>> > >> >>>>>>>> @Repository
> @InvocationHandler
>> > >> >>>>>>>> public class
> MyInvocationHandler
>> > > implements InvocationHandler {
>> > >> >>>>>>>> ...
>> > >> >>>>>>>> }
>> > >> >>>>>>>>
>> > >> >>>>>>>> Why do we have a
> @InvocationHandler here?
>> > > Is it supposed to be
>> > >> >>>>>>>> @InvocationHandlerBinding
> instead? If so,
>> > > is it really needed
>> > >> >> here?
>> > >> >>>>>>>
>> > >> >>>>>>> No, it should be
> @InvocationHandler, it's
>> > > analagous to
>> > >> >> @Interceptor.
>> > >> >>>> It's
>> > >> >>>>>>> not 100% necessary as we
> already implement the
>> > > interface, which is
>> > >> >>>> enough
>> > >> >>>>>>> of the marker.
>> > >> >>>>>>>
>> > >> >>>>>>>>
>> > >> >>>>>>>> Thinking about the
> implementation for
>> > > this, I think this actually
>> > >> >>>> becomes
>> > >> >>>>>>>> easier to use and easier to
> understand
>> > > over the Solder solution.
>> > >> >>> The
>> > >> >>>>>>>> implementation of the
> InvocationHandler
>> > > becomes a true CDI bean.
>> > >> >>>>>>>>
>> > >> >>>>>>>> Should DS support
> Interceptors and
>> > > Decorators on
>> > >> >>>>>>>> InvocationHandler beans?
>> > >> >>>>>>>>
>> > >> >>>>>>>> Do you mean the
> implementation class or
>> > > the interface?
>> > >> >>>>>>>>
>> > >> >>>>>>>> John
>> > >> >>>>>>>>
>> > >> >>>>>>>>
>> > >> >>>>>>>> On Thu, Dec 20, 2012 at
> 7:06 AM, Romain
>> > > Manni-Bucau
>> > >> >>>>>>>>
> <rm...@gmail.com>wrote:
>> > >> >>>>>>>>
>> > >> >>>>>>>>> i'd rather say no
> because the idea
>> > > is to ease "util" extension
>> > >> >>>>>>>>> writing. that's
> clearly not
>> > > intended to be full business beans
>> > >> >> IMO
>> > >> >>>> (at
>> > >> >>>>>>>>> least for a first step)
>> > >> >>>>>>>>>
>> > >> >>>>>>>>> That's why i'd
> leave it as
>> > > this for now
>> > >> >>>>>>>>>
>> > >> >>>>>>>>> wdyt?
>> > >> >>>>>>>>>
>> > >> >>>>>>>>> Romain Manni-Bucau
>> > >> >>>>>>>>> Twitter: @rmannibucau
>> > >> >>>>>>>>> Blog:
>> > > http://rmannibucau.wordpress.com/
>> > >> >>>>>>>>> LinkedIn:
>> > > http://fr.linkedin.com/in/rmannibucau
>> > >> >>>>>>>>> Github:
> https://github.com/rmannibucau
>> > >> >>>>>>>>>
>> > >> >>>>>>>>>
>> > >> >>>>>>>>>
>> > >> >>>>>>>>> 2012/12/20 Arne Limburg
>> > > <ar...@openknowledge.de>:
>> > >> >>>>>>>>>> Mark refers to my
> call stack.
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>> Out of the box this
> call stack
>> > > would exist just in OWB, because
>> > >> >>> Weld
>> > >> >>>>>>>>> would
>> > >> >>>>>>>>>> not apply any
> Interceptors or
>> > > Decorators...
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>> The question is:
> Should DS support
>> > > Interceptors and Decorators
>> > >> >> on
>> > >> >>>>>>>>>> InvocationHandler
> beans? My answer
>> > > would be: yes, if our
>> > >> >>>> implementation
>> > >> >>>>>>>>>> shall be a preview
> of CDI-110.
>> > >> >>>>>>>>>> And that would make
> things
>> > > complicated in the implementation...
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>> Am 20.12.12 12:11
> schrieb
>> > > "Romain Manni-Bucau" unter
>> > >> >>>>>>>>>>
> <rm...@gmail.com>:
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>>> is it an issue
> for
>> > > servicehandler? i don't think so
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>> it is often
> used to get util
>> > > classes dynamically created, it is
>> > >> >>>> rarely
>> > >> >>>>>>>>>>> (i never saw
> it) decorated
>> > > directly
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>> Romain
> Manni-Bucau
>> > >> >>>>>>>>>>> Twitter:
> @rmannibucau
>> > >> >>>>>>>>>>> Blog:
>> > > http://rmannibucau.wordpress.com/
>> > >> >>>>>>>>>>> LinkedIn:
>> > > http://fr.linkedin.com/in/rmannibucau
>> > >> >>>>>>>>>>> Github:
>> > > https://github.com/rmannibucau
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>>
>> > >> >>>>>>>>>>> 2012/12/20 Mark
> Struberg
>> > > <st...@yahoo.de>:
>> > >> >>>>>>>>>>>> we stumbled
> about this
>> > > lately. It seems CDI only forces
>> > >> >> support
>> > >> >>>> for
>> > >> >>>>>>>>>>>>
> interceptors and
>> > > decorators for CDI-annotated classes, but not
>> > >> >>> for
>> > >> >>>>>>>>>>>>
> Bean<T> which get
>> > > added via extensions nor even producer
>> > >> >> methods
>> > >> >>>> and
>> > >> >>>>>>>>>>>> fields :/
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>> Of course
> OWB does it, but
>> > > it would be not portable...
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>> LieGrue,
>> > >> >>>>>>>>>>>> strub
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>>
>> > >> >>>>>>>>>>>> -----
> Original Message
>> > > -----
>> > >> >>>>>>>>>>>>> From:
> Arne Limburg
>> > > <ar...@openknowledge.de>
>> > >> >>>>>>>>>>>>> To:
>> > > "deltaspike-dev@incubator.apache.org"
>> > >> >>>>>>>>>>>>>
>> > > <de...@incubator.apache.org>
>> > >> >>>>>>>>>>>>> Cc:
>> > >> >>>>>>>>>>>>> Sent:
> Thursday,
>> > > December 20, 2012 10:18 AM
>> > >> >>>>>>>>>>>>>
> Subject: Re: [DISCUSS]
>> > > [DELTASPIKE-113] Review and Discuss
>> > >> >>>>>>>>>>>>>
> ServiceHandler
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> T wo
> things about
>> > > this: First: I don't like from the solder
>> > >> >>>>>>> approach,
>> > >> >>>>>>>>>>>>> because
> the interface
>> > > is annotated instead of the
>> > >> >>> implementation.
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Second,
> if we
>> > > implement this we should conceptually make
>> > >> >> clear
>> > >> >>>> how
>> > >> >>>>>>> it
>> > >> >>>>>>>>>>>>>
> differentiates from
>> > > Interceptors and Decorators. And
>> > >> >>> personally I
>> > >> >>>>>>>>> think
>> > >> >>>>>>>>>>>>> this
> would work better
>> > > with the InvocationHandler approach
>> > >> >> than
>> > >> >>>> with
>> > >> >>>>>>>>> an
>> > >> >>>>>>>>>>>>>
> approach that is very
>> > > similar to interceptors.
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> So +1
> for an approach
>> > > like this:
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
>> > > @HandlesInvocationsOn(MyInterface.class)
>> > >> >>>>>>>>>>>>> public
> class
>> > > MyInvocationHandler implements
>> > >> >> InvocationHandler {
>> > >> >>>>>>>>>>>>> ...
>> > >> >>>>>>>>>>>>> }
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> Technically we would
>> > > register a custom Bean for every found
>> > >> >>>>>>>>>>>>>
> InvocationHandler with
>> > > that annotation and take over the
>> > >> >>>>>>>>>>>>>
> interceptor-bindings
>> > > from the interfaceŠ
>> > >> >>>>>>>>>>>>> So the
> invocation
>> > > stack would be clear, too:
>> > >> >>>>>>>>>>>>> First
> Interceptors,
>> > >> >>>>>>>>>>>>> Second
> Decorators,
>> > >> >>>>>>>>>>>>> Third
>> > > InvocationHandler
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Wdyt?
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Arne
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Am
> 20.12.12 01:53
>> > > schrieb "Romain Manni-Bucau" unter
>> > >> >>>>>>>>>>>>>
>> > > <rm...@gmail.com>:
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>> +1
>> > >> >>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>
> that's a need,
>> > > DS targets CDI 1.0 for now so just make this
>> > >> >>>> solder
>> > >> >>>>>>>>>>>>>>
> part portable ans
>> > > it should be fine
>> > >> >>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>
> Romain Manni-Bucau
>> > >> >>>>>>>>>>>>>>
> Twitter:
>> > > @rmannibucau
>> > >> >>>>>>>>>>>>>>
> Blog:
>> > > http://rmannibucau.wordpress.com/
>> > >> >>>>>>>>>>>>>>
> LinkedIn:
>> > > http://fr.linkedin.com/in/rmannibucau
>> > >> >>>>>>>>>>>>>>
> Github:
>> > > https://github.com/rmannibucau
>> > >> >>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>
> 2012/12/20 Jason
>> > > Porter <li...@gmail.com>:
>> > >> >>>>>>>>>>>>>>>
> At this point,
>> > > I'd say just do it as is in solder.
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
> On Wed, Dec
>> > > 19, 2012 at 5:25 PM, John D. Ament
>> > >> >>>>>>>>>>>>>>>
>> > > <jo...@gmail.com>wrote:
>> > >> >>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> Hi All,
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> Regarding
>> > > the two open questions:
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> 1) the
>> > > approach (including the name/s) we agree on will be
>> > >> >>>> used
>> > >> >>>>>>>>>>>>> also
>> > >>
>>>>>>>>>>>>>>>>> for
>> > >>
>>>>>>>>>>>>>>>>> cdi 1.1
>> > > (the only difference is the package)
>> > >>
>>>>>>>>>>>>>>>>> 2) the eg
>> > > has a different opinion about it ->
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> It looks
>> > > like the JSR's answer
>> > >>
>>>>>>>>>>>>>>>>>
>> > > (https://issues.jboss.org/browse/CDI-110 )
>> > >>
>>>>>>>>>>>>>>>>> is still
>> > > unresolved - I'm not sure if we can get any
>> > >> >> further
>> > >> >>>>>>>>>>>>> answer
> at
>> > >>
>>>>>>>>>>>>>>>>> this
>> > >>
>>>>>>>>>>>>>>>>> time. The
>> > > last posts on the subject seem to discuss using
>> > >> >>>>>>>>>>>>>
> something
>> > >>
>>>>>>>>>>>>>>>>> along
>> > >>
>>>>>>>>>>>>>>>>> the lines
>> > > of an invocation handler, which I think would
>> > >> >> work
>> > >> >>>>>>> well.
>> > >>
>>>>>>>>>>>>>>>>> Since
>> > >>
>>>>>>>>>>>>>>>>> we have
>> > > some features coming up that are interested in
>> > >> >>> having
>> > >> >>>>>>>>>>>>> service
>> > >>
>>>>>>>>>>>>>>>>> handlers
>> > > available, do we
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> 1.
>> > > Implement as is, or similar to, what is currently in
>> > >> >>>> Solder?
>> > >>
>>>>>>>>>>>>>>>>> 2. Push EG
>> > > on a resolution
>> > >>
>>>>>>>>>>>>>>>>> 3. Do it
>> > > using invocation handlers.
>> > >>
>>>>>>>>>>>>>>>>> 4. Do it
>> > > some other way?
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> John
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>> On Wed,
>> > > Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>> > >>
>>>>>>>>>>>>>>>>>
>> > > gerhard.petracek@gmail.com
>> > >>
>>>>>>>>>>>>>>>>>> wrote:
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>> hi
>> > > john,
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>> as
>> > > mentioned before we need the answers to the existing
>> > >> >>>>>>>>>>>>>
> questions.
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > 2012/4/4 John D. Ament <jo...@gmail.com>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > All,
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>> I
>> > > kind of let this one and the other drop off my radar,
>> > >> >> I
>> > >>
>>>>>>>>>>>>>>>>> apologize.
>> > >>
>>>>>>>>>>>>>>>>> it
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > looks like where we last left off, Gerhard was still
>> > >> >>>>>>>>>>>>>
> requesting
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > additional
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > comments from everyone. Any other feedback?
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > John
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>> On
>> > > Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > gerhard.petracek@gmail.com> wrote:
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
> hi
>> > > george,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
> thx
>> > > for the information. i thought there might be at
>> > >> >>>>>>>>>>>>> least
> some
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > additional
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > answers/clarifications, since pete asked for them in
>> > >> >>>>>>>>>>>>> several
>> > >>
>>>>>>>>>>>>>>>>> comments.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > -> imo we should continue with them.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/12 George Gastaldi
>> > >> >>>>>>>>>>>>>
>> > > <ge...@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > Hello Gerhard,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > Yeah, it´s the last state. I know it´s quite
>> > >> >>>>>>>>>>>>> old,
> but I
>> > >>
>>>>>>>>>>>>>>>>> haven´t
>> > > had
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > time
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > to work on it after that.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > Regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > George
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/12 Gerhard Petracek
>> > >> >>>>>>>>>>>>>
>> > > <ge...@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > hi george,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > thx for the link.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > i'm not sure if it is the latest state
>> > >> >>>>>>>>>>>>> of your
> discussion
>> > >>
>>>>>>>>>>>>>>>>> and/or
>> > >>
>>>>>>>>>>>>>>>>>> draft
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > (at least it's quite old already).
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/7 George Gastaldi
>> > >> >>>>>>>>>>>>>
>> > > <ge...@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Hi !
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > +1 to #1. I also agree that the term
>> > >> >>>>>>>>>>>>>
> "Service
>> > > Handler" might
>> > >>
>>>>>>>>>>>>>>>>> not
>> > >>
>>>>>>>>>>>>>>>>> be
>> > >>
>>>>>>>>>>>>>>>>>>> so
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > appropriate, so it should be discussed
>> > >> >>>>>>>>>>>>> as
> well.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Here is the latest pull request with
>> > >> >>>>>>>>>>>>> some
> comments from
>> > > Pete
>> > >>
>>>>>>>>>>>>>>>>> yet
>> > >>
>>>>>>>>>>>>>>>>> to
>> > >>
>>>>>>>>>>>>>>>>>>> be
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > reviewed:
>> > >> >>>>>>>>>>>>>
>> > > https://github.com/jboss/cdi/pull/28
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/7 Pete Muir
>> > >> >>>>>>>>>>>>>
>> > > <pm...@redhat.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Agreed :-)
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > George is working on it for CDI
>> > >> >>>>>>>>>>>>> 1.1.
> George, can you
>> > > share
>> > >>
>>>>>>>>>>>>>>>>> your
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > proposal
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > so far?
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On 7 Mar 2012, at 17:05, Gerhard
>> > >> >>>>>>>>>>>>>
> Petracek wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > hi pete,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > independent of my opinion
>> > >> >>>>>>>>>>>>> about
> the feature
>> > > (which is
>> > >>
>>>>>>>>>>>>>>>>> still
>> > >>
>>>>>>>>>>>>>>>>>> +0):
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > if it should be part of cdi
>> > >> >>>>>>>>>>>>> 1.1, we
> have the
>> > > following
>> > >>
>>>>>>>>>>>>>>>>> options
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > imo:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 1) the approach (including
>> > >> >>>>>>>>>>>>> the
> name/s) we agree
>> > > on will
>> > >>
>>>>>>>>>>>>>>>>> be
>> > >>
>>>>>>>>>>>>>>>>> used
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > also
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > for
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > cdi 1.1 (the only difference
>> > >> >>>>>>>>>>>>> is the
> package)
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2) the eg has a different
>> > >> >>>>>>>>>>>>> opinion
> about it ->
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2a) the rest of the eg joins
>> > >> >>>>>>>>>>>>> this
> discussion
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2b) we wait for the final
>> > >> >>>>>>>>>>>>> version
> and just allow
>> > > the same
>> > >>
>>>>>>>>>>>>>>>>> with
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > cdi
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 1.0
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 3) if the eg doesn't
>> > >> >>>>>>>>>>>>> agree
> on the idea, it
>> > > should be
>> > >>
>>>>>>>>>>>>>>>>> re-visited
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > for
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > deltaspike (if we really need
>> > >> >>>>>>>>>>>>> it)
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 4) we agree on it independent
>> > >> >>>>>>>>>>>>> of the
> result in cdi
>> > > 1.1
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 1-3 is ok for me but -1 for
>> > >> >>>>>>>>>>>>> #4
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/7 Pete Muir
>> > >> >>>>>>>>>>>>>
>> > > <pm...@redhat.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > I'm not sure what you
>> > >> >>>>>>>>>>>>> mean by
> a "super
>> > > interceptor",
>> > >>
>>>>>>>>>>>>>>>>> but if
>> > >>
>>>>>>>>>>>>>>>>>> you
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > mean it
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > as
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > in "super man"
>> > >> >>>>>>>>>>>>>
> (something better than
>> > > an interceptor),
>> > >>
>>>>>>>>>>>>>>>>> then
>> > >>
>>>>>>>>>>>>>>>>> I
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > would
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > disagree, it's
>> > >> >>>>>>>>>>>>>
> actually a specialised
>> > > form of
>> > >>
>>>>>>>>>>>>>>>>>
>> > > interceptor.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > The best use case I know
>> > >> >>>>>>>>>>>>> of is
> the one John
>> > > mentions -
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > creating
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > type
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > safe
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > references to queries:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > @QueryService
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > interface UserQuery {
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > @Query("select u
>> > >> >>>>>>>>>>>>> from
> User u")
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > public List<User>
>> > >> >>>>>>>>>>>>>
> getAllUsers();
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > @Query("select u
>> > >> >>>>>>>>>>>>> from
> User u order by
>> > > u.name")
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > public List<User>
>> > >> >>>>>>>>>>>>>
>> > > getAllUsersSortedByName();
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > }
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Now, it may be the case
>> > >> >>>>>>>>>>>>> that
> there aren't
>> > > any other use
>> > >>
>>>>>>>>>>>>>>>>> cases
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > for
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > service
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > handlers, in which case
>> > >> >>>>>>>>>>>>> we
> should perhaps just
>> > > offer
>> > >>
>>>>>>>>>>>>>>>>> this
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > particular
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > service handler -
>> > >> >>>>>>>>>>>>>
> references to type
>> > > safe queries - as I
>> > >>
>>>>>>>>>>>>>>>>> think
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > this
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > is
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > an
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > extremely powerful idea.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Note, that at the moment
>> > >> >>>>>>>>>>>>> service
> handlers are
>> > > scheduled
>> > >>
>>>>>>>>>>>>>>>>> for
>> > >>
>>>>>>>>>>>>>>>>>> CDI
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > 1.1.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On 7 Mar 2012, at 02:35,
>> > >> >>>>>>>>>>>>> Jason
> Porter wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Somewhat. I
>> > >> >>>>>>>>>>>>>
> wouldn't really
>> > > think of them as overrides,
>> > >>
>>>>>>>>>>>>>>>>> they,
>> > >>
>>>>>>>>>>>>>>>>>>> to
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > me,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > seem more like items to
>> > >> >>>>>>>>>>>>> do in
> addition to
>> > > whatever the
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > original
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > impl
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > does.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > ServiceHandlers to me
>> > >> >>>>>>>>>>>>> seem
> more like super
>> > >>
>>>>>>>>>>>>>>>>>
>> > > interceptors.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Sent from my iPhone
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On Mar 6, 2012, at
>> > >> >>>>>>>>>>>>> 19:23,
> "John D.
>> > > Ament" <
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > john.d.ament@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > @jason
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > I think the
>> > >> >>>>>>>>>>>>>
> concepts are very
>> > > dissimilar.
>> > >>
>>>>>>>>>>>>>>>>>
>> > > servicehandlers
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > create
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > implementation.
>> > >> >>>>>>>>>>>>>
> delegates are more
>> > > like overrides and
>> > >>
>>>>>>>>>>>>>>>>> need
>> > >>
>>>>>>>>>>>>>>>>>> to
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > know
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > about
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the method
>> > >> >>>>>>>>>>>>>
> signature.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On Tue, Mar 6,
>> > >> >>>>>>>>>>>>> 2012 at
> 9:17 PM, Jason
>> > > Porter <
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > lightguard.jp@gmail.com
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > I think the
>> > >> >>>>>>>>>>>>> idea of
>> > > ServiceHandlers are good, but,
>> > >>
>>>>>>>>>>>>>>>>> could
>> > >>
>>>>>>>>>>>>>>>>> we
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > not
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > do
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > this
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > with
>> > >> >>>>>>>>>>>>>
> delegates?
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Sent from my
>> > >> >>>>>>>>>>>>> iPhone
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On Mar 6,
>> > >> >>>>>>>>>>>>> 2012,
> at 19:05,
>> > > "John D. Ament" <
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > john.d.ament@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > @mark
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > I
>> > >> >>>>>>>>>>>>>
> don't think
>> > > it's a hard requirement for it to be
>> > >>
>>>>>>>>>>>>>>>>> on an
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > interface.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > One of
>> > >> >>>>>>>>>>>>> the
> best use-cases we
>> > > built at my job is
>> > >>
>>>>>>>>>>>>>>>>> using it
>> > >>
>>>>>>>>>>>>>>>>>> for
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > calling
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > PL/SQL.
>> > >> >>>>>>>>>>>>> The
> JDBC bindings do
>> > > work, but not pretty.
>> > >>
>>>>>>>>>>>>>>>>> we
>> > >>
>>>>>>>>>>>>>>>>>> were
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > able to
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > create
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > a fairly
>> > >> >>>>>>>>>>>>> clean
> wrapper API,
>> > > generic enough for
>> > >>
>>>>>>>>>>>>>>>>> binding
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > in/out
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > parameters.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > JOhn
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On Tue,
>> > >> >>>>>>>>>>>>> Mar 6,
> 2012 at 12:58
>> > > PM, Mark Struberg <
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > struberg@yahoo.de>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> actually I don't
>> > > really see a real benefit. I just
>> > >>
>>>>>>>>>>>>>>>>> don't
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > yet
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > grok
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > use
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > case
>> > >> >>>>>>>>>>>>> for
> real world
>> > > projects.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Why
>> > >> >>>>>>>>>>>>> would
> one intercept an
>> > > Interface and delegate
>> > >>
>>>>>>>>>>>>>>>>> the
>> > >>
>>>>>>>>>>>>>>>>>> calls
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
> to
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > a
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > method
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> handler?
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > This
>> > >> >>>>>>>>>>>>> could
> be neat for
>> > > mocking, but there are
>> > >>
>>>>>>>>>>>>>>>>> better
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > frameworks for
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > that.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > thus
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > -0.2
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> LieGrue,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > strub
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > -----
>> > >> >>>>>>>>>>>>>
> Original Message -----
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> From:
> Gerhard Petracek
>> > >>
>>>>>>>>>>>>>>>>>
>> > > <ge...@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> To:
>> > > deltaspike-dev@incubator.apache.org
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Cc:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> Sent:
> Tuesday, March
>> > > 6, 2012 5:15 PM
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> Subject: Re: [DISCUSS]
>> > > [DELTASPIKE-113] Review and
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > Discuss
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> ServiceHandler
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> if you
> have a lot of
>> > > shared code, you can extract
>> > >>
>>>>>>>>>>>>>>>>> it
>> > >>
>>>>>>>>>>>>>>>>> in
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > 1-n
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > method/s or
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > an
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> abstract class which
>> > > is still easier than a new
>> > >>
>>>>>>>>>>>>>>>>> concept.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> at
> least i haven't
>> > > seen an use-case which really
>> > >>
>>>>>>>>>>>>>>>>> needed
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > it.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > that
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > was
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> reason
> for a +0 (which
>> > > still means that i'm ok
>> > >>
>>>>>>>>>>>>>>>>> with
>> > >>
>>>>>>>>>>>>>>>>>> adding
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > it).
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> 2012/3/6 Pete Muir
>> > > <pm...@redhat.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > So, you mean just write a bean with all the
>> > >>
>>>>>>>>>>>>>>>>>
>> > > boilerplate
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > code
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > in
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > it?
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On 6 Mar 2012, at 15:58, Gerhard Petracek
>> > >> >>>>>>>>>>>>> wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > hi pete,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > instead of the interface you can just
>> > >> >>>>>>>>>>>>>
> implement
>> > >>
>>>>>>>>>>>>>>>>> a
>> > >>
>>>>>>>>>>>>>>>>> bean
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > > which
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > does
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > same.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/6 Pete Muir
>> > >> >>>>>>>>>>>>>
>> > > <pm...@redhat.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > What CDI mechanism would you use
>> > >> >>>>>>>>>>>>>
> instead?
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > On 5 Mar 2012, at 08:47, Gerhard
>> > >> >>>>>>>>>>>>>
> Petracek
>> > >>
>>>>>>>>>>>>>>>>> wrote:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > +0
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > no -1 because there are
>> > >> >>>>>>>>>>>>>
> use-cases for it.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > no +1 because i would use std.
>> > >> >>>>>>>>>>>>> cdi
> mechanisms
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > instead.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/4 Gerhard Petracek <
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > gerhard.petracek@gmail.com
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > hi john,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the sub-task is perfectly
>> > >> >>>>>>>>>>>>> fine.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > gerhard
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > 2012/3/4 John D. Ament
>> > >>
>>>>>>>>>>>>>>>>>
>> > > <jo...@gmail.com>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Hi All
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > I wanted to bring up
>> > >> >>>>>>>>>>>>> the
> subject of
>> > >>
>>>>>>>>>>>>>>>>>>
>> > > ServiceHandler.
>> > >>
>>>>>>>>>>>>>>>>>>> I
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> added
> 113 as a
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > child
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > of DELTASPIKE-2, looked
>> > >> >>>>>>>>>>>>>
> appropriate but not
>> > >>
>>>>>>>>>>>>>>>>> 100%
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > sure
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> (so
> please let
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > me
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > know if you think
>> > >> >>>>>>>>>>>>>
> it's not
>> > > appropriate as a
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> child).
>> > > ServiceHandler
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > is
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > a
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > feature in Solder that
>> > >> >>>>>>>>>>>>> allows
> you to define
>> > >>
>>>>>>>>>>>>>>>>> an
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> interceptor that
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > manages
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > generic calls against
>> > >> >>>>>>>>>>>>> an
> injected interface.
>> > >>
>>>>>>>>>>>>>>>>> The
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > API
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> is as
> follows:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > -
>> > >> >>>>>>>>>>>>>
>> > > @ServiceHandlerType(Class<?> clazz) -
>> > >>
>>>>>>>>>>>>>>>>> placed
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> on an
> annotation that
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > would
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > be placed on the
>> > >> >>>>>>>>>>>>>
> interface. Indicates
>> > > what
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> interceptor would be
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > invoked
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > for calls against this
>> > >> >>>>>>>>>>>>>
> interface.
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > It's then up to the
>> > >> >>>>>>>>>>>>>
> application
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> developer/framework
>> > > author to define
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > annotations that go on
>> > >> >>>>>>>>>>>>>
> methods, as well as
>> > >>
>>>>>>>>>>>>>>>>> the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>
> interceptor itself
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > > that
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > will
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > be invoked. The
>> > >> >>>>>>>>>>>>> feature
> for
>> > > ServiceHandler
>> > >>
>>>>>>>>>>>>>>>>> would
>> > >>
>>>>>>>>>>>>>>>>>> be
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> to
> provide the
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > API of
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > the type and then the
>> > >> >>>>>>>>>>>>>
> infrastructure
>> > >>
>>>>>>>>>>>>>>>>> required
>> > > to
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > > make
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>> the
> interceptor
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > be
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > called. Existing
>> > >> >>>>>>>>>>>>>
> documentation of the
>> > >>
>>>>>>>>>>>>>>>>> feature:
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>
>> > >> >>>>
>> > >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>> > >>
>>>>>>>>>>>>>>>>> ser
>> > >>
>>>>>>>>>>>>>>>>>
>> > > vicehandler.html
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > Regards,
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > > john
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>>
>> > >>
>> >
>>>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>>
>> > >>
>>>>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
> --
>> > >> >>>>>>>>>>>>>>>
> Jason Porter
>> > >> >>>>>>>>>>>>>>>
>> > > http://lightguard-jp.blogspot.com
>> > >> >>>>>>>>>>>>>>>
>> > > http://twitter.com/lightguardjp
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
> Software
>> > > Engineer
>> > >> >>>>>>>>>>>>>>>
> Open Source
>> > > Advocate
>> > >> >>>>>>>>>>>>>>>
>> > >> >>>>>>>>>>>>>>>
> PGP key id:
>> > > 926CCFF5
>> > >> >>>>>>>>>>>>>>>
> PGP key
>> > > available at: keyserver.net, pgp.mit.edu
>> > >> >>>>>>>>>>>>>
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>
>> > >> >>>>>>>
>> > >> >>>>>>>
>> > >> >>>>>
>> > >> >>>>
>> > >> >>>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> --
>> > >> >> Jason Porter
>> > >> >> http://lightguard-jp.blogspot.com
>> > >> >> http://twitter.com/lightguardjp
>> > >> >>
>> > >> >> Software Engineer
>> > >> >> Open Source Advocate
>> > >> >>
>> > >> >> PGP key id: 926CCFF5
>> > >> >> PGP key available at: keyserver.net, pgp.mit.edu
>> > >> >>
>> > >>
>> > >>
>> > >
>> >
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
imo it should be as simple as possible, because so far we just heard one
use-case for which it really makes sense (DELTASPIKE-60 + abstract classes).
-> the following should be enough:
@InvocationHandlerBinding
public @interface GenericDaoHandler {
}
@GenericDaoHandler
public GenericDaoHandlerImpl implements InvocationHandler {
//...
}
@GenericDaoHandler
@ApplicationScoped //or any other scope
public abstract class PersonDao { //or interface
//...
}
@mark:
in the end it's just like an interceptor, but it just executes the
interceptor logic (without InvocationContext#proceed) >or< the implemented
method provided via an abstract class.
regards,
gerhard
2012/12/23 John D. Ament <jo...@gmail.com>
> Well, this object is used for a specific case. In my opinion, you should be
> able to resolve it using
>
> @Inject @QueryHandler
> private InvocationHandler queryHandler;
>
> Though why you may want to inject it in a client app is unknown to me; it
> does make it easier from an implementation standpoint.
>
> Does the service handler need to have any specific scope? Can it inherit
> the scope of what it's handling? I guess not, since it could be a handler
> to n things. NormalScope would be appropriate then.
>
>
> On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> > I guess because it might overlap with other qualifiers added in some
> cases.
> >
> > What do we gain for making it a qualifier?
> >
> > Another important difference to CDI interceptors is that they are always
> > @Dependent to the intercepted instance.
> > Whereas the ServiceHandler should be of NormalScope, isn't?
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: John D. Ament <jo...@gmail.com>
> > > To: deltaspike-dev@incubator.apache.org
> > > Cc:
> > > Sent: Saturday, December 22, 2012 7:56 PM
> > > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> ServiceHandler
> > >
> > > Pete,
> > >
> > > Regarding interceptors - I think what I have is pretty close to the
> > > interceptor definition, except this should only end up working on a
> > > class/interface (I think?)
> > >
> > > Also, why wouldn't we want the annotation to also be a qualifier?
> > >
> > > John
> > >
> > >
> > > On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
> > >
> > >>
> > >> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > So just to summarize the current proposal:
> > >> >
> > >> > - Create a new annotation @ServiceHandlerBinding (in core/api)
> which
> > > will
> > >> > be placed on on the interface that defines points of the
> > >> > - Create a new annotation @ServiceHandler (in core/api) (I think
> > based
> > > on
> > >> > below this isn't needed since we have the interface now).
> > >> > - Create an extension that can generate object proxies that link
> > calls
> > > to
> > >> > methods on the - org.apache.deltaspike.core.api....
> > >> >
> > >> > Define the binding type annotation:
> > >> >
> > >> > @ServiceHandlerBinding
> > >> > @Qualifier
> > >> > public @interface QueryHandler {
> > >> > }
> > >>
> > >> I don't think we want @Qualifier here.
> > >>
> > >> >
> > >> > which will define the relationship between the interface/abstract
> > > class
> > >> > that will use the service handler and the class that will serve as
> > the
> > >> > invocation handler.
> > >> >
> > >> > For example, we can use @QueryHandler on an interface:
> > >> >
> > >> > @QueryHandler
> > >> > public interface PersonDAO {
> > >> > //...
> > >> > }
> > >> >
> > >> > When the container finds this interface it will identify the
> > > appropriate
> > >> > InvocationHandler, based on the following matches:
> > >> >
> > >> > - Implements InvocationHandler
> > >>
> > >> Yes.
> > >>
> > >> > - Is annotated @QueryHandler
> > >>
> > >> Ish, this should follow standard CDI resolution rules, you can copy
> the
> > >> way interceptor bindings work here.
> > >>
> > >> > - Is annotated @ServiceHandler
> > >>
> > >> Yes
> > >>
> > >> >
> > >> > DeltaSpike will provide a proxied object where all abstract method
> > > calls
> > >> > are delegated to the InvocationHandler. The InvocationHandler will
> > > need
> > >> to
> > >> > have logic to handle all methods as defined within the class, as
> long
> > > as
> > >> > that method is invoked through the InvocationHandler.
> > >> >
> > >> > @QueryHandler @ServiceHandler
> > >> > public QueryHandlerInvoker implements InvocationHandler {
> > >> >
> > >> > public Object invoke(Object proxy, Method method, Object[] args) {
> > >> > if(method.getName().startsWith("find..."){
> > >> > //...
> > >> > }
> > >> > return null;
> > >> >
> > >> > }
> > >> > }
> > >> >
> > >> > In addition, the ServiceHandlerBinding can be placed on an abstract
> > >> class.
> > >> > In this case, only abstract methods will be passed to the
> > >> > InvocationHandler.
> > >> >
> > >> > @QueryHandler
> > >> > public abstract interface PersonDAO {
> > >> > public String doSomethingConcrete() {
> > >> > return "concrete";
> > >> > }
> > >> >
> > >> > public abstract Person find(int id);
> > >> > }
> > >> >
> > >> > Only the find method will be wrapped, the method
> doSomethingConcrete
> > > will
> > >> > be invoked directly. When interacting with an abstract class, the
> > >> > InvocationHandler can call methods on the proxied object.
> > >> >
> > >> > Finally, the app developer will be able to simply inject their
> > >> > interface/abstract class in to their beans to perform work:
> > >> >
> > >> > @Inject @QueryHandler PersonDAO dao;
> > >> >
> > >> > Questions:
> > >> >
> > >> > Should we provide a store (simple key/value map) to keep a history
> of
> > >> found
> > >> > object types and how they map?
> > >>
> > >> You mean like BeanManager.resolveInterceptors() ? I guess this is
> > useful.
> > >>
> > >> > Should we depend on certain libraries for proxying (e.g.
> javassist, I
> > >> think
> > >> > both Weld & OWB use this still?)
> > >>
> > >> If you want to just cover interfaces, it's easy, you can use proxying
> > > from
> > >> the JDK. Otherwise yes you need to pick a lib.
> > >>
> > >> Weld doesn't use javassist for proxying, but does for other stuff.
> > >>
> > >> > Since we now use the interface InvocationHandler should we rename
> the
> > >> > binding to be InvocationHandlerBinding?
> > >>
> > >> Yes, this makes sense
> > >>
> > >> > I also think it's not necessary to
> > >> > have @ServiceHandler since the marker interface now exists.
> > >>
> > >> +1
> > >>
> > >> >
> > >> > Comments welcome..
> > >> >
> > >> > John
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> > > <lightguard.jp@gmail.com
> > >> >wrote:
> > >> >
> > >> >> +1 for @ServiceHandler
> > >> >>
> > >> >>
> > >> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> > > <john.d.ament@gmail.com
> > >> >>> wrote:
> > >> >>
> > >> >>> If we're still calling the feature
> > > "ServiceHandler" then why not
> > >> >>> @ServiceHandler?
> > >> >>>
> > >> >>>
> > >> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> > >> >>> <rm...@gmail.com>wrote:
> > >> >>>
> > >> >>>> if we don't need it perfect, if we need it we'll
> > > just use another name
> > >> >>>> @DSHandler, @Handler...whatever it is ;)
> > >> >>>>
> > >> >>>> Romain Manni-Bucau
> > >> >>>> Twitter: @rmannibucau
> > >> >>>> Blog: http://rmannibucau.wordpress.com/
> > >> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> >>>> Github: https://github.com/rmannibucau
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> > >> >>>>> :-) Yes for sure. I suspect we dont' need
> > > @InvocationHandler at all.
> > >> >>>>>
> > >> >>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > >> >>>>>
> > >> >>>>>> The problem I have is that now InvocationHandler
> > > is both an
> > >> >> interface
> > >> >>>> and
> > >> >>>>>> an @interface which will make it impossible for
> > > imports. I don't
> > >> >>> think
> > >> >>>>>> they should have the same name.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> > > <pm...@redhat.com>
> > >> >> wrote:
> > >> >>>>>>
> > >> >>>>>>>
> > >> >>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> > >> >>>>>>>
> > >> >>>>>>>> All,
> > >> >>>>>>>>
> > >> >>>>>>>> So mostly ok from my perspective. One
> > > thing to note:
> > >> >>>>>>>>
> > >> >>>>>>>> @InvocationHandlerBinding
> > >> >>>>>>>> public @interface Repository {}
> > >> >>>>>>>>
> > >> >>>>>>>> @Repository
> > >> >>>>>>>> public interface MyRepository {
> > >> >>>>>>>> ...
> > >> >>>>>>>> }
> > >> >>>>>>>>
> > >> >>>>>>>> @Repository @InvocationHandler
> > >> >>>>>>>> public class MyInvocationHandler
> > > implements InvocationHandler {
> > >> >>>>>>>> ...
> > >> >>>>>>>> }
> > >> >>>>>>>>
> > >> >>>>>>>> Why do we have a @InvocationHandler here?
> > > Is it supposed to be
> > >> >>>>>>>> @InvocationHandlerBinding instead? If so,
> > > is it really needed
> > >> >> here?
> > >> >>>>>>>
> > >> >>>>>>> No, it should be @InvocationHandler, it's
> > > analagous to
> > >> >> @Interceptor.
> > >> >>>> It's
> > >> >>>>>>> not 100% necessary as we already implement the
> > > interface, which is
> > >> >>>> enough
> > >> >>>>>>> of the marker.
> > >> >>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> Thinking about the implementation for
> > > this, I think this actually
> > >> >>>> becomes
> > >> >>>>>>>> easier to use and easier to understand
> > > over the Solder solution.
> > >> >>> The
> > >> >>>>>>>> implementation of the InvocationHandler
> > > becomes a true CDI bean.
> > >> >>>>>>>>
> > >> >>>>>>>> Should DS support Interceptors and
> > > Decorators on
> > >> >>>>>>>> InvocationHandler beans?
> > >> >>>>>>>>
> > >> >>>>>>>> Do you mean the implementation class or
> > > the interface?
> > >> >>>>>>>>
> > >> >>>>>>>> John
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> > > Manni-Bucau
> > >> >>>>>>>> <rm...@gmail.com>wrote:
> > >> >>>>>>>>
> > >> >>>>>>>>> i'd rather say no because the idea
> > > is to ease "util" extension
> > >> >>>>>>>>> writing. that's clearly not
> > > intended to be full business beans
> > >> >> IMO
> > >> >>>> (at
> > >> >>>>>>>>> least for a first step)
> > >> >>>>>>>>>
> > >> >>>>>>>>> That's why i'd leave it as
> > > this for now
> > >> >>>>>>>>>
> > >> >>>>>>>>> wdyt?
> > >> >>>>>>>>>
> > >> >>>>>>>>> Romain Manni-Bucau
> > >> >>>>>>>>> Twitter: @rmannibucau
> > >> >>>>>>>>> Blog:
> > > http://rmannibucau.wordpress.com/
> > >> >>>>>>>>> LinkedIn:
> > > http://fr.linkedin.com/in/rmannibucau
> > >> >>>>>>>>> Github: https://github.com/rmannibucau
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> 2012/12/20 Arne Limburg
> > > <ar...@openknowledge.de>:
> > >> >>>>>>>>>> Mark refers to my call stack.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> Out of the box this call stack
> > > would exist just in OWB, because
> > >> >>> Weld
> > >> >>>>>>>>> would
> > >> >>>>>>>>>> not apply any Interceptors or
> > > Decorators...
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> The question is: Should DS support
> > > Interceptors and Decorators
> > >> >> on
> > >> >>>>>>>>>> InvocationHandler beans? My answer
> > > would be: yes, if our
> > >> >>>> implementation
> > >> >>>>>>>>>> shall be a preview of CDI-110.
> > >> >>>>>>>>>> And that would make things
> > > complicated in the implementation...
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> Am 20.12.12 12:11 schrieb
> > > "Romain Manni-Bucau" unter
> > >> >>>>>>>>>> <rm...@gmail.com>:
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>> is it an issue for
> > > servicehandler? i don't think so
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> it is often used to get util
> > > classes dynamically created, it is
> > >> >>>> rarely
> > >> >>>>>>>>>>> (i never saw it) decorated
> > > directly
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> Romain Manni-Bucau
> > >> >>>>>>>>>>> Twitter: @rmannibucau
> > >> >>>>>>>>>>> Blog:
> > > http://rmannibucau.wordpress.com/
> > >> >>>>>>>>>>> LinkedIn:
> > > http://fr.linkedin.com/in/rmannibucau
> > >> >>>>>>>>>>> Github:
> > > https://github.com/rmannibucau
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> 2012/12/20 Mark Struberg
> > > <st...@yahoo.de>:
> > >> >>>>>>>>>>>> we stumbled about this
> > > lately. It seems CDI only forces
> > >> >> support
> > >> >>>> for
> > >> >>>>>>>>>>>> interceptors and
> > > decorators for CDI-annotated classes, but not
> > >> >>> for
> > >> >>>>>>>>>>>> Bean<T> which get
> > > added via extensions nor even producer
> > >> >> methods
> > >> >>>> and
> > >> >>>>>>>>>>>> fields :/
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> Of course OWB does it, but
> > > it would be not portable...
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> LieGrue,
> > >> >>>>>>>>>>>> strub
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> ----- Original Message
> > > -----
> > >> >>>>>>>>>>>>> From: Arne Limburg
> > > <ar...@openknowledge.de>
> > >> >>>>>>>>>>>>> To:
> > > "deltaspike-dev@incubator.apache.org"
> > >> >>>>>>>>>>>>>
> > > <de...@incubator.apache.org>
> > >> >>>>>>>>>>>>> Cc:
> > >> >>>>>>>>>>>>> Sent: Thursday,
> > > December 20, 2012 10:18 AM
> > >> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > > [DELTASPIKE-113] Review and Discuss
> > >> >>>>>>>>>>>>> ServiceHandler
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> T wo things about
> > > this: First: I don't like from the solder
> > >> >>>>>>> approach,
> > >> >>>>>>>>>>>>> because the interface
> > > is annotated instead of the
> > >> >>> implementation.
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Second, if we
> > > implement this we should conceptually make
> > >> >> clear
> > >> >>>> how
> > >> >>>>>>> it
> > >> >>>>>>>>>>>>> differentiates from
> > > Interceptors and Decorators. And
> > >> >>> personally I
> > >> >>>>>>>>> think
> > >> >>>>>>>>>>>>> this would work better
> > > with the InvocationHandler approach
> > >> >> than
> > >> >>>> with
> > >> >>>>>>>>> an
> > >> >>>>>>>>>>>>> approach that is very
> > > similar to interceptors.
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> So +1 for an approach
> > > like this:
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>
> > > @HandlesInvocationsOn(MyInterface.class)
> > >> >>>>>>>>>>>>> public class
> > > MyInvocationHandler implements
> > >> >> InvocationHandler {
> > >> >>>>>>>>>>>>> ...
> > >> >>>>>>>>>>>>> }
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Technically we would
> > > register a custom Bean for every found
> > >> >>>>>>>>>>>>> InvocationHandler with
> > > that annotation and take over the
> > >> >>>>>>>>>>>>> interceptor-bindings
> > > from the interfaceŠ
> > >> >>>>>>>>>>>>> So the invocation
> > > stack would be clear, too:
> > >> >>>>>>>>>>>>> First Interceptors,
> > >> >>>>>>>>>>>>> Second Decorators,
> > >> >>>>>>>>>>>>> Third
> > > InvocationHandler
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Wdyt?
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Arne
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Am 20.12.12 01:53
> > > schrieb "Romain Manni-Bucau" unter
> > >> >>>>>>>>>>>>>
> > > <rm...@gmail.com>:
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>> +1
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>> that's a need,
> > > DS targets CDI 1.0 for now so just make this
> > >> >>>> solder
> > >> >>>>>>>>>>>>>> part portable ans
> > > it should be fine
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>> Romain Manni-Bucau
> > >> >>>>>>>>>>>>>> Twitter:
> > > @rmannibucau
> > >> >>>>>>>>>>>>>> Blog:
> > > http://rmannibucau.wordpress.com/
> > >> >>>>>>>>>>>>>> LinkedIn:
> > > http://fr.linkedin.com/in/rmannibucau
> > >> >>>>>>>>>>>>>> Github:
> > > https://github.com/rmannibucau
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>> 2012/12/20 Jason
> > > Porter <li...@gmail.com>:
> > >> >>>>>>>>>>>>>>> At this point,
> > > I'd say just do it as is in solder.
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>> On Wed, Dec
> > > 19, 2012 at 5:25 PM, John D. Ament
> > >> >>>>>>>>>>>>>>>
> > > <jo...@gmail.com>wrote:
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> Hi All,
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> Regarding
> > > the two open questions:
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> 1) the
> > > approach (including the name/s) we agree on will be
> > >> >>>> used
> > >> >>>>>>>>>>>>> also
> > >> >>>>>>>>>>>>>>>> for
> > >> >>>>>>>>>>>>>>>> cdi 1.1
> > > (the only difference is the package)
> > >> >>>>>>>>>>>>>>>> 2) the eg
> > > has a different opinion about it ->
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> It looks
> > > like the JSR's answer
> > >> >>>>>>>>>>>>>>>>
> > > (https://issues.jboss.org/browse/CDI-110 )
> > >> >>>>>>>>>>>>>>>> is still
> > > unresolved - I'm not sure if we can get any
> > >> >> further
> > >> >>>>>>>>>>>>> answer at
> > >> >>>>>>>>>>>>>>>> this
> > >> >>>>>>>>>>>>>>>> time. The
> > > last posts on the subject seem to discuss using
> > >> >>>>>>>>>>>>> something
> > >> >>>>>>>>>>>>>>>> along
> > >> >>>>>>>>>>>>>>>> the lines
> > > of an invocation handler, which I think would
> > >> >> work
> > >> >>>>>>> well.
> > >> >>>>>>>>>>>>>>>> Since
> > >> >>>>>>>>>>>>>>>> we have
> > > some features coming up that are interested in
> > >> >>> having
> > >> >>>>>>>>>>>>> service
> > >> >>>>>>>>>>>>>>>> handlers
> > > available, do we
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> 1.
> > > Implement as is, or similar to, what is currently in
> > >> >>>> Solder?
> > >> >>>>>>>>>>>>>>>> 2. Push EG
> > > on a resolution
> > >> >>>>>>>>>>>>>>>> 3. Do it
> > > using invocation handlers.
> > >> >>>>>>>>>>>>>>>> 4. Do it
> > > some other way?
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> John
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>> On Wed,
> > > Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> > >> >>>>>>>>>>>>>>>>
> > > gerhard.petracek@gmail.com
> > >> >>>>>>>>>>>>>>>>> wrote:
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>> hi
> > > john,
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>> as
> > > mentioned before we need the answers to the existing
> > >> >>>>>>>>>>>>> questions.
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > > regards,
> > >> >>>>>>>>>>>>>>>>>
> > > gerhard
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > > 2012/4/4 John D. Ament <jo...@gmail.com>
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>>
> > > All,
> > >> >>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>> I
> > > kind of let this one and the other drop off my radar,
> > >> >> I
> > >> >>>>>>>>>>>>>>>> apologize.
> > >> >>>>>>>>>>>>>>>> it
> > >> >>>>>>>>>>>>>>>>>>
> > > looks like where we last left off, Gerhard was still
> > >> >>>>>>>>>>>>> requesting
> > >> >>>>>>>>>>>>>>>>>
> > > additional
> > >> >>>>>>>>>>>>>>>>>>
> > > comments from everyone. Any other feedback?
> > >> >>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>>
> > > John
> > >> >>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>> On
> > > Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > >> >>>>>>>>>>>>>>>>>>
> > > gerhard.petracek@gmail.com> wrote:
> > >> >>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>> hi
> > > george,
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>> thx
> > > for the information. i thought there might be at
> > >> >>>>>>>>>>>>> least some
> > >> >>>>>>>>>>>>>>>>>>
> > > additional
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > answers/clarifications, since pete asked for them in
> > >> >>>>>>>>>>>>> several
> > >> >>>>>>>>>>>>>>>> comments.
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > -> imo we should continue with them.
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > 2012/3/12 George Gastaldi
> > >> >>>>>>>>>>>>>
> > > <ge...@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > Hello Gerhard,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > Yeah, it´s the last state. I know it´s quite
> > >> >>>>>>>>>>>>> old, but I
> > >> >>>>>>>>>>>>>>>> haven´t
> > > had
> > >> >>>>>>>>>>>>>>>>>>
> > > time
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > to work on it after that.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > Regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > George
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/12 Gerhard Petracek
> > >> >>>>>>>>>>>>>
> > > <ge...@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > hi george,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > thx for the link.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > i'm not sure if it is the latest state
> > >> >>>>>>>>>>>>> of your discussion
> > >> >>>>>>>>>>>>>>>> and/or
> > >> >>>>>>>>>>>>>>>>> draft
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > (at least it's quite old already).
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/7 George Gastaldi
> > >> >>>>>>>>>>>>>
> > > <ge...@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > Hi !
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > +1 to #1. I also agree that the term
> > >> >>>>>>>>>>>>> "Service
> > > Handler" might
> > >> >>>>>>>>>>>>>>>> not
> > >> >>>>>>>>>>>>>>>> be
> > >> >>>>>>>>>>>>>>>>>> so
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > appropriate, so it should be discussed
> > >> >>>>>>>>>>>>> as well.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > Here is the latest pull request with
> > >> >>>>>>>>>>>>> some comments from
> > > Pete
> > >> >>>>>>>>>>>>>>>> yet
> > >> >>>>>>>>>>>>>>>> to
> > >> >>>>>>>>>>>>>>>>>> be
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > reviewed:
> > >> >>>>>>>>>>>>>
> > > https://github.com/jboss/cdi/pull/28
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/7 Pete Muir
> > >> >>>>>>>>>>>>>
> > > <pm...@redhat.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > Agreed :-)
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > George is working on it for CDI
> > >> >>>>>>>>>>>>> 1.1. George, can you
> > > share
> > >> >>>>>>>>>>>>>>>> your
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > proposal
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > so far?
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > On 7 Mar 2012, at 17:05, Gerhard
> > >> >>>>>>>>>>>>> Petracek wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > hi pete,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > independent of my opinion
> > >> >>>>>>>>>>>>> about the feature
> > > (which is
> > >> >>>>>>>>>>>>>>>> still
> > >> >>>>>>>>>>>>>>>>> +0):
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > if it should be part of cdi
> > >> >>>>>>>>>>>>> 1.1, we have the
> > > following
> > >> >>>>>>>>>>>>>>>> options
> > >> >>>>>>>>>>>>>>>>>>
> > > imo:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 1) the approach (including
> > >> >>>>>>>>>>>>> the name/s) we agree
> > > on will
> > >> >>>>>>>>>>>>>>>> be
> > >> >>>>>>>>>>>>>>>> used
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > also
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > for
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > cdi 1.1 (the only difference
> > >> >>>>>>>>>>>>> is the package)
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2) the eg has a different
> > >> >>>>>>>>>>>>> opinion about it ->
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2a) the rest of the eg joins
> > >> >>>>>>>>>>>>> this discussion
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2b) we wait for the final
> > >> >>>>>>>>>>>>> version and just allow
> > > the same
> > >> >>>>>>>>>>>>>>>> with
> > >> >>>>>>>>>>>>>>>>>>
> > > cdi
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > 1.0
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 3) if the eg doesn't
> > >> >>>>>>>>>>>>> agree on the idea, it
> > > should be
> > >> >>>>>>>>>>>>>>>> re-visited
> > >> >>>>>>>>>>>>>>>>>>
> > > for
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > deltaspike (if we really need
> > >> >>>>>>>>>>>>> it)
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 4) we agree on it independent
> > >> >>>>>>>>>>>>> of the result in cdi
> > > 1.1
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 1-3 is ok for me but -1 for
> > >> >>>>>>>>>>>>> #4
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/7 Pete Muir
> > >> >>>>>>>>>>>>>
> > > <pm...@redhat.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > I'm not sure what you
> > >> >>>>>>>>>>>>> mean by a "super
> > > interceptor",
> > >> >>>>>>>>>>>>>>>> but if
> > >> >>>>>>>>>>>>>>>>> you
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > mean it
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > as
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > in "super man"
> > >> >>>>>>>>>>>>> (something better than
> > > an interceptor),
> > >> >>>>>>>>>>>>>>>> then
> > >> >>>>>>>>>>>>>>>> I
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > would
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > disagree, it's
> > >> >>>>>>>>>>>>> actually a specialised
> > > form of
> > >> >>>>>>>>>>>>>>>>
> > > interceptor.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > The best use case I know
> > >> >>>>>>>>>>>>> of is the one John
> > > mentions -
> > >> >>>>>>>>>>>>>>>>>
> > > creating
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > type
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > safe
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > references to queries:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > @QueryService
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > interface UserQuery {
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > @Query("select u
> > >> >>>>>>>>>>>>> from User u")
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > public List<User>
> > >> >>>>>>>>>>>>> getAllUsers();
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > @Query("select u
> > >> >>>>>>>>>>>>> from User u order by
> > > u.name")
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > public List<User>
> > >> >>>>>>>>>>>>>
> > > getAllUsersSortedByName();
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > }
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Now, it may be the case
> > >> >>>>>>>>>>>>> that there aren't
> > > any other use
> > >> >>>>>>>>>>>>>>>> cases
> > >> >>>>>>>>>>>>>>>>>>
> > > for
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > service
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > handlers, in which case
> > >> >>>>>>>>>>>>> we should perhaps just
> > > offer
> > >> >>>>>>>>>>>>>>>> this
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > particular
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > service handler -
> > >> >>>>>>>>>>>>> references to type
> > > safe queries - as I
> > >> >>>>>>>>>>>>>>>> think
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > this
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > is
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > an
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > extremely powerful idea.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Note, that at the moment
> > >> >>>>>>>>>>>>> service handlers are
> > > scheduled
> > >> >>>>>>>>>>>>>>>> for
> > >> >>>>>>>>>>>>>>>>> CDI
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > 1.1.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > On 7 Mar 2012, at 02:35,
> > >> >>>>>>>>>>>>> Jason Porter wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Somewhat. I
> > >> >>>>>>>>>>>>> wouldn't really
> > > think of them as overrides,
> > >> >>>>>>>>>>>>>>>> they,
> > >> >>>>>>>>>>>>>>>>>> to
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > me,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > seem more like items to
> > >> >>>>>>>>>>>>> do in addition to
> > > whatever the
> > >> >>>>>>>>>>>>>>>>>
> > > original
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > impl
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > does.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > ServiceHandlers to me
> > >> >>>>>>>>>>>>> seem more like super
> > >> >>>>>>>>>>>>>>>>
> > > interceptors.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Sent from my iPhone
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > On Mar 6, 2012, at
> > >> >>>>>>>>>>>>> 19:23, "John D.
> > > Ament" <
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > john.d.ament@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > @jason
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > I think the
> > >> >>>>>>>>>>>>> concepts are very
> > > dissimilar.
> > >> >>>>>>>>>>>>>>>>
> > > servicehandlers
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > create
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > implementation.
> > >> >>>>>>>>>>>>> delegates are more
> > > like overrides and
> > >> >>>>>>>>>>>>>>>> need
> > >> >>>>>>>>>>>>>>>>> to
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > know
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > about
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > the method
> > >> >>>>>>>>>>>>> signature.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > On Tue, Mar 6,
> > >> >>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> > > Porter <
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > lightguard.jp@gmail.com
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > I think the
> > >> >>>>>>>>>>>>> idea of
> > > ServiceHandlers are good, but,
> > >> >>>>>>>>>>>>>>>> could
> > >> >>>>>>>>>>>>>>>> we
> > >> >>>>>>>>>>>>>>>>>>
> > > not
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > do
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > this
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > with
> > >> >>>>>>>>>>>>> delegates?
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Sent from my
> > >> >>>>>>>>>>>>> iPhone
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > On Mar 6,
> > >> >>>>>>>>>>>>> 2012, at 19:05,
> > > "John D. Ament" <
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > john.d.ament@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > @mark
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > I
> > >> >>>>>>>>>>>>> don't think
> > > it's a hard requirement for it to be
> > >> >>>>>>>>>>>>>>>> on an
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > interface.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > One of
> > >> >>>>>>>>>>>>> the best use-cases we
> > > built at my job is
> > >> >>>>>>>>>>>>>>>> using it
> > >> >>>>>>>>>>>>>>>>> for
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > calling
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > PL/SQL.
> > >> >>>>>>>>>>>>> The JDBC bindings do
> > > work, but not pretty.
> > >> >>>>>>>>>>>>>>>> we
> > >> >>>>>>>>>>>>>>>>> were
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > able to
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > create
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > a fairly
> > >> >>>>>>>>>>>>> clean wrapper API,
> > > generic enough for
> > >> >>>>>>>>>>>>>>>> binding
> > >> >>>>>>>>>>>>>>>>>>
> > > in/out
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > parameters.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > JOhn
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > On Tue,
> > >> >>>>>>>>>>>>> Mar 6, 2012 at 12:58
> > > PM, Mark Struberg <
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > struberg@yahoo.de>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> actually I don't
> > > really see a real benefit. I just
> > >> >>>>>>>>>>>>>>>> don't
> > >> >>>>>>>>>>>>>>>>>>
> > > yet
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > grok
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > use
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > case
> > >> >>>>>>>>>>>>> for real world
> > > projects.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Why
> > >> >>>>>>>>>>>>> would one intercept an
> > > Interface and delegate
> > >> >>>>>>>>>>>>>>>> the
> > >> >>>>>>>>>>>>>>>>> calls
> > >>
> > >>>>>>>>>>>>>>>>>>>> to
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > a
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > method
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> handler?
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > This
> > >> >>>>>>>>>>>>> could be neat for
> > > mocking, but there are
> > >> >>>>>>>>>>>>>>>> better
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > frameworks for
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > that.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > thus
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > -0.2
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> LieGrue,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > strub
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > -----
> > >> >>>>>>>>>>>>> Original Message -----
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> From: Gerhard Petracek
> > >> >>>>>>>>>>>>>>>>
> > > <ge...@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> To:
> > > deltaspike-dev@incubator.apache.org
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Cc:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Sent: Tuesday, March
> > > 6, 2012 5:15 PM
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > > [DELTASPIKE-113] Review and
> > >> >>>>>>>>>>>>>>>>>
> > > Discuss
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> ServiceHandler
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> if you have a lot of
> > > shared code, you can extract
> > >> >>>>>>>>>>>>>>>> it
> > >> >>>>>>>>>>>>>>>> in
> > >> >>>>>>>>>>>>>>>>>>
> > > 1-n
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > method/s or
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > an
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> abstract class which
> > > is still easier than a new
> > >> >>>>>>>>>>>>>>>> concept.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> at least i haven't
> > > seen an use-case which really
> > >> >>>>>>>>>>>>>>>> needed
> > >> >>>>>>>>>>>>>>>>>>
> > > it.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > that
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > was
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> reason for a +0 (which
> > > still means that i'm ok
> > >> >>>>>>>>>>>>>>>> with
> > >> >>>>>>>>>>>>>>>>> adding
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > it).
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> 2012/3/6 Pete Muir
> > > <pm...@redhat.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > So, you mean just write a bean with all the
> > >> >>>>>>>>>>>>>>>>
> > > boilerplate
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > code
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > in
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > it?
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > On 6 Mar 2012, at 15:58, Gerhard Petracek
> > >> >>>>>>>>>>>>> wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > hi pete,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > instead of the interface you can just
> > >> >>>>>>>>>>>>> implement
> > >> >>>>>>>>>>>>>>>> a
> > >> >>>>>>>>>>>>>>>> bean
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > > which
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > does
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > same.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/6 Pete Muir
> > >> >>>>>>>>>>>>>
> > > <pm...@redhat.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > What CDI mechanism would you use
> > >> >>>>>>>>>>>>> instead?
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > On 5 Mar 2012, at 08:47, Gerhard
> > >> >>>>>>>>>>>>> Petracek
> > >> >>>>>>>>>>>>>>>> wrote:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > +0
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > no -1 because there are
> > >> >>>>>>>>>>>>> use-cases for it.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > no +1 because i would use std.
> > >> >>>>>>>>>>>>> cdi mechanisms
> > >> >>>>>>>>>>>>>>>>>
> > > instead.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/4 Gerhard Petracek <
> > >> >>>>>>>>>>>>>>>>>
> > > gerhard.petracek@gmail.com
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > hi john,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > the sub-task is perfectly
> > >> >>>>>>>>>>>>> fine.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > gerhard
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > 2012/3/4 John D. Ament
> > >> >>>>>>>>>>>>>>>>
> > > <jo...@gmail.com>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Hi All
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > I wanted to bring up
> > >> >>>>>>>>>>>>> the subject of
> > >> >>>>>>>>>>>>>>>>>
> > > ServiceHandler.
> > >> >>>>>>>>>>>>>>>>>> I
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> added 113 as a
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > child
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > of DELTASPIKE-2, looked
> > >> >>>>>>>>>>>>> appropriate but not
> > >> >>>>>>>>>>>>>>>> 100%
> > >> >>>>>>>>>>>>>>>>>>
> > > sure
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> (so please let
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > me
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > know if you think
> > >> >>>>>>>>>>>>> it's not
> > > appropriate as a
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> child).
> > > ServiceHandler
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > is
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > a
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > feature in Solder that
> > >> >>>>>>>>>>>>> allows you to define
> > >> >>>>>>>>>>>>>>>> an
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> interceptor that
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > manages
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > generic calls against
> > >> >>>>>>>>>>>>> an injected interface.
> > >> >>>>>>>>>>>>>>>> The
> > >> >>>>>>>>>>>>>>>>>>
> > > API
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> is as follows:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > -
> > >> >>>>>>>>>>>>>
> > > @ServiceHandlerType(Class<?> clazz) -
> > >> >>>>>>>>>>>>>>>> placed
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> on an annotation that
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > would
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > be placed on the
> > >> >>>>>>>>>>>>> interface. Indicates
> > > what
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> interceptor would be
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > invoked
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > for calls against this
> > >> >>>>>>>>>>>>> interface.
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > It's then up to the
> > >> >>>>>>>>>>>>> application
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> developer/framework
> > > author to define
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > annotations that go on
> > >> >>>>>>>>>>>>> methods, as well as
> > >> >>>>>>>>>>>>>>>> the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> interceptor itself
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > > that
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > will
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > be invoked. The
> > >> >>>>>>>>>>>>> feature for
> > > ServiceHandler
> > >> >>>>>>>>>>>>>>>> would
> > >> >>>>>>>>>>>>>>>>> be
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> to provide the
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > API of
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > the type and then the
> > >> >>>>>>>>>>>>> infrastructure
> > >> >>>>>>>>>>>>>>>> required
> > > to
> > >> >>>>>>>>>>>>>>>>>>
> > > make
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>> the interceptor
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > be
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > called. Existing
> > >> >>>>>>>>>>>>> documentation of the
> > >> >>>>>>>>>>>>>>>> feature:
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>
> > > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> > >> >>>>>>>>>>>>>>>> ser
> > >> >>>>>>>>>>>>>>>>
> > > vicehandler.html
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Regards,
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > john
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> > >>>>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>> --
> > >> >>>>>>>>>>>>>>> Jason Porter
> > >> >>>>>>>>>>>>>>>
> > > http://lightguard-jp.blogspot.com
> > >> >>>>>>>>>>>>>>>
> > > http://twitter.com/lightguardjp
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>> Software
> > > Engineer
> > >> >>>>>>>>>>>>>>> Open Source
> > > Advocate
> > >> >>>>>>>>>>>>>>>
> > >> >>>>>>>>>>>>>>> PGP key id:
> > > 926CCFF5
> > >> >>>>>>>>>>>>>>> PGP key
> > > available at: keyserver.net, pgp.mit.edu
> > >> >>>>>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Jason Porter
> > >> >> http://lightguard-jp.blogspot.com
> > >> >> http://twitter.com/lightguardjp
> > >> >>
> > >> >> Software Engineer
> > >> >> Open Source Advocate
> > >> >>
> > >> >> PGP key id: 926CCFF5
> > >> >> PGP key available at: keyserver.net, pgp.mit.edu
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Well, this object is used for a specific case. In my opinion, you should be
able to resolve it using
@Inject @QueryHandler
private InvocationHandler queryHandler;
Though why you may want to inject it in a client app is unknown to me; it
does make it easier from an implementation standpoint.
Does the service handler need to have any specific scope? Can it inherit
the scope of what it's handling? I guess not, since it could be a handler
to n things. NormalScope would be appropriate then.
On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <st...@yahoo.de> wrote:
> I guess because it might overlap with other qualifiers added in some cases.
>
> What do we gain for making it a qualifier?
>
> Another important difference to CDI interceptors is that they are always
> @Dependent to the intercepted instance.
> Whereas the ServiceHandler should be of NormalScope, isn't?
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: John D. Ament <jo...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Saturday, December 22, 2012 7:56 PM
> > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> >
> > Pete,
> >
> > Regarding interceptors - I think what I have is pretty close to the
> > interceptor definition, except this should only end up working on a
> > class/interface (I think?)
> >
> > Also, why wouldn't we want the annotation to also be a qualifier?
> >
> > John
> >
> >
> > On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
> >
> >>
> >> On 21 Dec 2012, at 02:21, John D. Ament wrote:
> >>
> >> > Hi all,
> >> >
> >> > So just to summarize the current proposal:
> >> >
> >> > - Create a new annotation @ServiceHandlerBinding (in core/api) which
> > will
> >> > be placed on on the interface that defines points of the
> >> > - Create a new annotation @ServiceHandler (in core/api) (I think
> based
> > on
> >> > below this isn't needed since we have the interface now).
> >> > - Create an extension that can generate object proxies that link
> calls
> > to
> >> > methods on the - org.apache.deltaspike.core.api....
> >> >
> >> > Define the binding type annotation:
> >> >
> >> > @ServiceHandlerBinding
> >> > @Qualifier
> >> > public @interface QueryHandler {
> >> > }
> >>
> >> I don't think we want @Qualifier here.
> >>
> >> >
> >> > which will define the relationship between the interface/abstract
> > class
> >> > that will use the service handler and the class that will serve as
> the
> >> > invocation handler.
> >> >
> >> > For example, we can use @QueryHandler on an interface:
> >> >
> >> > @QueryHandler
> >> > public interface PersonDAO {
> >> > //...
> >> > }
> >> >
> >> > When the container finds this interface it will identify the
> > appropriate
> >> > InvocationHandler, based on the following matches:
> >> >
> >> > - Implements InvocationHandler
> >>
> >> Yes.
> >>
> >> > - Is annotated @QueryHandler
> >>
> >> Ish, this should follow standard CDI resolution rules, you can copy the
> >> way interceptor bindings work here.
> >>
> >> > - Is annotated @ServiceHandler
> >>
> >> Yes
> >>
> >> >
> >> > DeltaSpike will provide a proxied object where all abstract method
> > calls
> >> > are delegated to the InvocationHandler. The InvocationHandler will
> > need
> >> to
> >> > have logic to handle all methods as defined within the class, as long
> > as
> >> > that method is invoked through the InvocationHandler.
> >> >
> >> > @QueryHandler @ServiceHandler
> >> > public QueryHandlerInvoker implements InvocationHandler {
> >> >
> >> > public Object invoke(Object proxy, Method method, Object[] args) {
> >> > if(method.getName().startsWith("find..."){
> >> > //...
> >> > }
> >> > return null;
> >> >
> >> > }
> >> > }
> >> >
> >> > In addition, the ServiceHandlerBinding can be placed on an abstract
> >> class.
> >> > In this case, only abstract methods will be passed to the
> >> > InvocationHandler.
> >> >
> >> > @QueryHandler
> >> > public abstract interface PersonDAO {
> >> > public String doSomethingConcrete() {
> >> > return "concrete";
> >> > }
> >> >
> >> > public abstract Person find(int id);
> >> > }
> >> >
> >> > Only the find method will be wrapped, the method doSomethingConcrete
> > will
> >> > be invoked directly. When interacting with an abstract class, the
> >> > InvocationHandler can call methods on the proxied object.
> >> >
> >> > Finally, the app developer will be able to simply inject their
> >> > interface/abstract class in to their beans to perform work:
> >> >
> >> > @Inject @QueryHandler PersonDAO dao;
> >> >
> >> > Questions:
> >> >
> >> > Should we provide a store (simple key/value map) to keep a history of
> >> found
> >> > object types and how they map?
> >>
> >> You mean like BeanManager.resolveInterceptors() ? I guess this is
> useful.
> >>
> >> > Should we depend on certain libraries for proxying (e.g. javassist, I
> >> think
> >> > both Weld & OWB use this still?)
> >>
> >> If you want to just cover interfaces, it's easy, you can use proxying
> > from
> >> the JDK. Otherwise yes you need to pick a lib.
> >>
> >> Weld doesn't use javassist for proxying, but does for other stuff.
> >>
> >> > Since we now use the interface InvocationHandler should we rename the
> >> > binding to be InvocationHandlerBinding?
> >>
> >> Yes, this makes sense
> >>
> >> > I also think it's not necessary to
> >> > have @ServiceHandler since the marker interface now exists.
> >>
> >> +1
> >>
> >> >
> >> > Comments welcome..
> >> >
> >> > John
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> > <lightguard.jp@gmail.com
> >> >wrote:
> >> >
> >> >> +1 for @ServiceHandler
> >> >>
> >> >>
> >> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> > <john.d.ament@gmail.com
> >> >>> wrote:
> >> >>
> >> >>> If we're still calling the feature
> > "ServiceHandler" then why not
> >> >>> @ServiceHandler?
> >> >>>
> >> >>>
> >> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> >> >>> <rm...@gmail.com>wrote:
> >> >>>
> >> >>>> if we don't need it perfect, if we need it we'll
> > just use another name
> >> >>>> @DSHandler, @Handler...whatever it is ;)
> >> >>>>
> >> >>>> Romain Manni-Bucau
> >> >>>> Twitter: @rmannibucau
> >> >>>> Blog: http://rmannibucau.wordpress.com/
> >> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> >>>> Github: https://github.com/rmannibucau
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> >> >>>>> :-) Yes for sure. I suspect we dont' need
> > @InvocationHandler at all.
> >> >>>>>
> >> >>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> >> >>>>>
> >> >>>>>> The problem I have is that now InvocationHandler
> > is both an
> >> >> interface
> >> >>>> and
> >> >>>>>> an @interface which will make it impossible for
> > imports. I don't
> >> >>> think
> >> >>>>>> they should have the same name.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> > <pm...@redhat.com>
> >> >> wrote:
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> >> >>>>>>>
> >> >>>>>>>> All,
> >> >>>>>>>>
> >> >>>>>>>> So mostly ok from my perspective. One
> > thing to note:
> >> >>>>>>>>
> >> >>>>>>>> @InvocationHandlerBinding
> >> >>>>>>>> public @interface Repository {}
> >> >>>>>>>>
> >> >>>>>>>> @Repository
> >> >>>>>>>> public interface MyRepository {
> >> >>>>>>>> ...
> >> >>>>>>>> }
> >> >>>>>>>>
> >> >>>>>>>> @Repository @InvocationHandler
> >> >>>>>>>> public class MyInvocationHandler
> > implements InvocationHandler {
> >> >>>>>>>> ...
> >> >>>>>>>> }
> >> >>>>>>>>
> >> >>>>>>>> Why do we have a @InvocationHandler here?
> > Is it supposed to be
> >> >>>>>>>> @InvocationHandlerBinding instead? If so,
> > is it really needed
> >> >> here?
> >> >>>>>>>
> >> >>>>>>> No, it should be @InvocationHandler, it's
> > analagous to
> >> >> @Interceptor.
> >> >>>> It's
> >> >>>>>>> not 100% necessary as we already implement the
> > interface, which is
> >> >>>> enough
> >> >>>>>>> of the marker.
> >> >>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> Thinking about the implementation for
> > this, I think this actually
> >> >>>> becomes
> >> >>>>>>>> easier to use and easier to understand
> > over the Solder solution.
> >> >>> The
> >> >>>>>>>> implementation of the InvocationHandler
> > becomes a true CDI bean.
> >> >>>>>>>>
> >> >>>>>>>> Should DS support Interceptors and
> > Decorators on
> >> >>>>>>>> InvocationHandler beans?
> >> >>>>>>>>
> >> >>>>>>>> Do you mean the implementation class or
> > the interface?
> >> >>>>>>>>
> >> >>>>>>>> John
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> > Manni-Bucau
> >> >>>>>>>> <rm...@gmail.com>wrote:
> >> >>>>>>>>
> >> >>>>>>>>> i'd rather say no because the idea
> > is to ease "util" extension
> >> >>>>>>>>> writing. that's clearly not
> > intended to be full business beans
> >> >> IMO
> >> >>>> (at
> >> >>>>>>>>> least for a first step)
> >> >>>>>>>>>
> >> >>>>>>>>> That's why i'd leave it as
> > this for now
> >> >>>>>>>>>
> >> >>>>>>>>> wdyt?
> >> >>>>>>>>>
> >> >>>>>>>>> Romain Manni-Bucau
> >> >>>>>>>>> Twitter: @rmannibucau
> >> >>>>>>>>> Blog:
> > http://rmannibucau.wordpress.com/
> >> >>>>>>>>> LinkedIn:
> > http://fr.linkedin.com/in/rmannibucau
> >> >>>>>>>>> Github: https://github.com/rmannibucau
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> 2012/12/20 Arne Limburg
> > <ar...@openknowledge.de>:
> >> >>>>>>>>>> Mark refers to my call stack.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Out of the box this call stack
> > would exist just in OWB, because
> >> >>> Weld
> >> >>>>>>>>> would
> >> >>>>>>>>>> not apply any Interceptors or
> > Decorators...
> >> >>>>>>>>>>
> >> >>>>>>>>>> The question is: Should DS support
> > Interceptors and Decorators
> >> >> on
> >> >>>>>>>>>> InvocationHandler beans? My answer
> > would be: yes, if our
> >> >>>> implementation
> >> >>>>>>>>>> shall be a preview of CDI-110.
> >> >>>>>>>>>> And that would make things
> > complicated in the implementation...
> >> >>>>>>>>>>
> >> >>>>>>>>>> Am 20.12.12 12:11 schrieb
> > "Romain Manni-Bucau" unter
> >> >>>>>>>>>> <rm...@gmail.com>:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> is it an issue for
> > servicehandler? i don't think so
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> it is often used to get util
> > classes dynamically created, it is
> >> >>>> rarely
> >> >>>>>>>>>>> (i never saw it) decorated
> > directly
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Romain Manni-Bucau
> >> >>>>>>>>>>> Twitter: @rmannibucau
> >> >>>>>>>>>>> Blog:
> > http://rmannibucau.wordpress.com/
> >> >>>>>>>>>>> LinkedIn:
> > http://fr.linkedin.com/in/rmannibucau
> >> >>>>>>>>>>> Github:
> > https://github.com/rmannibucau
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> 2012/12/20 Mark Struberg
> > <st...@yahoo.de>:
> >> >>>>>>>>>>>> we stumbled about this
> > lately. It seems CDI only forces
> >> >> support
> >> >>>> for
> >> >>>>>>>>>>>> interceptors and
> > decorators for CDI-annotated classes, but not
> >> >>> for
> >> >>>>>>>>>>>> Bean<T> which get
> > added via extensions nor even producer
> >> >> methods
> >> >>>> and
> >> >>>>>>>>>>>> fields :/
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Of course OWB does it, but
> > it would be not portable...
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> LieGrue,
> >> >>>>>>>>>>>> strub
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> ----- Original Message
> > -----
> >> >>>>>>>>>>>>> From: Arne Limburg
> > <ar...@openknowledge.de>
> >> >>>>>>>>>>>>> To:
> > "deltaspike-dev@incubator.apache.org"
> >> >>>>>>>>>>>>>
> > <de...@incubator.apache.org>
> >> >>>>>>>>>>>>> Cc:
> >> >>>>>>>>>>>>> Sent: Thursday,
> > December 20, 2012 10:18 AM
> >> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > [DELTASPIKE-113] Review and Discuss
> >> >>>>>>>>>>>>> ServiceHandler
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> T wo things about
> > this: First: I don't like from the solder
> >> >>>>>>> approach,
> >> >>>>>>>>>>>>> because the interface
> > is annotated instead of the
> >> >>> implementation.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Second, if we
> > implement this we should conceptually make
> >> >> clear
> >> >>>> how
> >> >>>>>>> it
> >> >>>>>>>>>>>>> differentiates from
> > Interceptors and Decorators. And
> >> >>> personally I
> >> >>>>>>>>> think
> >> >>>>>>>>>>>>> this would work better
> > with the InvocationHandler approach
> >> >> than
> >> >>>> with
> >> >>>>>>>>> an
> >> >>>>>>>>>>>>> approach that is very
> > similar to interceptors.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> So +1 for an approach
> > like this:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> > @HandlesInvocationsOn(MyInterface.class)
> >> >>>>>>>>>>>>> public class
> > MyInvocationHandler implements
> >> >> InvocationHandler {
> >> >>>>>>>>>>>>> ...
> >> >>>>>>>>>>>>> }
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Technically we would
> > register a custom Bean for every found
> >> >>>>>>>>>>>>> InvocationHandler with
> > that annotation and take over the
> >> >>>>>>>>>>>>> interceptor-bindings
> > from the interfaceŠ
> >> >>>>>>>>>>>>> So the invocation
> > stack would be clear, too:
> >> >>>>>>>>>>>>> First Interceptors,
> >> >>>>>>>>>>>>> Second Decorators,
> >> >>>>>>>>>>>>> Third
> > InvocationHandler
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Wdyt?
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Arne
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Am 20.12.12 01:53
> > schrieb "Romain Manni-Bucau" unter
> >> >>>>>>>>>>>>>
> > <rm...@gmail.com>:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> +1
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> that's a need,
> > DS targets CDI 1.0 for now so just make this
> >> >>>> solder
> >> >>>>>>>>>>>>>> part portable ans
> > it should be fine
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Romain Manni-Bucau
> >> >>>>>>>>>>>>>> Twitter:
> > @rmannibucau
> >> >>>>>>>>>>>>>> Blog:
> > http://rmannibucau.wordpress.com/
> >> >>>>>>>>>>>>>> LinkedIn:
> > http://fr.linkedin.com/in/rmannibucau
> >> >>>>>>>>>>>>>> Github:
> > https://github.com/rmannibucau
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> 2012/12/20 Jason
> > Porter <li...@gmail.com>:
> >> >>>>>>>>>>>>>>> At this point,
> > I'd say just do it as is in solder.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> On Wed, Dec
> > 19, 2012 at 5:25 PM, John D. Ament
> >> >>>>>>>>>>>>>>>
> > <jo...@gmail.com>wrote:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Hi All,
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Regarding
> > the two open questions:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> 1) the
> > approach (including the name/s) we agree on will be
> >> >>>> used
> >> >>>>>>>>>>>>> also
> >> >>>>>>>>>>>>>>>> for
> >> >>>>>>>>>>>>>>>> cdi 1.1
> > (the only difference is the package)
> >> >>>>>>>>>>>>>>>> 2) the eg
> > has a different opinion about it ->
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> It looks
> > like the JSR's answer
> >> >>>>>>>>>>>>>>>>
> > (https://issues.jboss.org/browse/CDI-110 )
> >> >>>>>>>>>>>>>>>> is still
> > unresolved - I'm not sure if we can get any
> >> >> further
> >> >>>>>>>>>>>>> answer at
> >> >>>>>>>>>>>>>>>> this
> >> >>>>>>>>>>>>>>>> time. The
> > last posts on the subject seem to discuss using
> >> >>>>>>>>>>>>> something
> >> >>>>>>>>>>>>>>>> along
> >> >>>>>>>>>>>>>>>> the lines
> > of an invocation handler, which I think would
> >> >> work
> >> >>>>>>> well.
> >> >>>>>>>>>>>>>>>> Since
> >> >>>>>>>>>>>>>>>> we have
> > some features coming up that are interested in
> >> >>> having
> >> >>>>>>>>>>>>> service
> >> >>>>>>>>>>>>>>>> handlers
> > available, do we
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> 1.
> > Implement as is, or similar to, what is currently in
> >> >>>> Solder?
> >> >>>>>>>>>>>>>>>> 2. Push EG
> > on a resolution
> >> >>>>>>>>>>>>>>>> 3. Do it
> > using invocation handlers.
> >> >>>>>>>>>>>>>>>> 4. Do it
> > some other way?
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> John
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> On Wed,
> > Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >> >>>>>>>>>>>>>>>>
> > gerhard.petracek@gmail.com
> >> >>>>>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> hi
> > john,
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> as
> > mentioned before we need the answers to the existing
> >> >>>>>>>>>>>>> questions.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> > regards,
> >> >>>>>>>>>>>>>>>>>
> > gerhard
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> > 2012/4/4 John D. Ament <jo...@gmail.com>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>
> > All,
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> I
> > kind of let this one and the other drop off my radar,
> >> >> I
> >> >>>>>>>>>>>>>>>> apologize.
> >> >>>>>>>>>>>>>>>> it
> >> >>>>>>>>>>>>>>>>>>
> > looks like where we last left off, Gerhard was still
> >> >>>>>>>>>>>>> requesting
> >> >>>>>>>>>>>>>>>>>
> > additional
> >> >>>>>>>>>>>>>>>>>>
> > comments from everyone. Any other feedback?
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>
> > John
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> On
> > Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >> >>>>>>>>>>>>>>>>>>
> > gerhard.petracek@gmail.com> wrote:
> >> >>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>> hi
> > george,
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>> thx
> > for the information. i thought there might be at
> >> >>>>>>>>>>>>> least some
> >> >>>>>>>>>>>>>>>>>>
> > additional
> >>
> >>>>>>>>>>>>>>>>>>>>
> > answers/clarifications, since pete asked for them in
> >> >>>>>>>>>>>>> several
> >> >>>>>>>>>>>>>>>> comments.
> >>
> >>>>>>>>>>>>>>>>>>>>
> > -> imo we should continue with them.
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> > 2012/3/12 George Gastaldi
> >> >>>>>>>>>>>>>
> > <ge...@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > Hello Gerhard,
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > Yeah, it´s the last state. I know it´s quite
> >> >>>>>>>>>>>>> old, but I
> >> >>>>>>>>>>>>>>>> haven´t
> > had
> >> >>>>>>>>>>>>>>>>>>
> > time
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > to work on it after that.
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > Regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > George
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> > 2012/3/12 Gerhard Petracek
> >> >>>>>>>>>>>>>
> > <ge...@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > hi george,
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > thx for the link.
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > i'm not sure if it is the latest state
> >> >>>>>>>>>>>>> of your discussion
> >> >>>>>>>>>>>>>>>> and/or
> >> >>>>>>>>>>>>>>>>> draft
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > (at least it's quite old already).
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/7 George Gastaldi
> >> >>>>>>>>>>>>>
> > <ge...@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > Hi !
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > +1 to #1. I also agree that the term
> >> >>>>>>>>>>>>> "Service
> > Handler" might
> >> >>>>>>>>>>>>>>>> not
> >> >>>>>>>>>>>>>>>> be
> >> >>>>>>>>>>>>>>>>>> so
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > appropriate, so it should be discussed
> >> >>>>>>>>>>>>> as well.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > Here is the latest pull request with
> >> >>>>>>>>>>>>> some comments from
> > Pete
> >> >>>>>>>>>>>>>>>> yet
> >> >>>>>>>>>>>>>>>> to
> >> >>>>>>>>>>>>>>>>>> be
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > reviewed:
> >> >>>>>>>>>>>>>
> > https://github.com/jboss/cdi/pull/28
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/7 Pete Muir
> >> >>>>>>>>>>>>>
> > <pm...@redhat.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > Agreed :-)
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > George is working on it for CDI
> >> >>>>>>>>>>>>> 1.1. George, can you
> > share
> >> >>>>>>>>>>>>>>>> your
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > proposal
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > so far?
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > On 7 Mar 2012, at 17:05, Gerhard
> >> >>>>>>>>>>>>> Petracek wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > hi pete,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > independent of my opinion
> >> >>>>>>>>>>>>> about the feature
> > (which is
> >> >>>>>>>>>>>>>>>> still
> >> >>>>>>>>>>>>>>>>> +0):
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > if it should be part of cdi
> >> >>>>>>>>>>>>> 1.1, we have the
> > following
> >> >>>>>>>>>>>>>>>> options
> >> >>>>>>>>>>>>>>>>>>
> > imo:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 1) the approach (including
> >> >>>>>>>>>>>>> the name/s) we agree
> > on will
> >> >>>>>>>>>>>>>>>> be
> >> >>>>>>>>>>>>>>>> used
> >>
> >>>>>>>>>>>>>>>>>>>>
> > also
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > for
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > cdi 1.1 (the only difference
> >> >>>>>>>>>>>>> is the package)
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 2) the eg has a different
> >> >>>>>>>>>>>>> opinion about it ->
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 2a) the rest of the eg joins
> >> >>>>>>>>>>>>> this discussion
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 2b) we wait for the final
> >> >>>>>>>>>>>>> version and just allow
> > the same
> >> >>>>>>>>>>>>>>>> with
> >> >>>>>>>>>>>>>>>>>>
> > cdi
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > 1.0
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 3) if the eg doesn't
> >> >>>>>>>>>>>>> agree on the idea, it
> > should be
> >> >>>>>>>>>>>>>>>> re-visited
> >> >>>>>>>>>>>>>>>>>>
> > for
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > deltaspike (if we really need
> >> >>>>>>>>>>>>> it)
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 4) we agree on it independent
> >> >>>>>>>>>>>>> of the result in cdi
> > 1.1
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 1-3 is ok for me but -1 for
> >> >>>>>>>>>>>>> #4
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/7 Pete Muir
> >> >>>>>>>>>>>>>
> > <pm...@redhat.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > I'm not sure what you
> >> >>>>>>>>>>>>> mean by a "super
> > interceptor",
> >> >>>>>>>>>>>>>>>> but if
> >> >>>>>>>>>>>>>>>>> you
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > mean it
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > as
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > in "super man"
> >> >>>>>>>>>>>>> (something better than
> > an interceptor),
> >> >>>>>>>>>>>>>>>> then
> >> >>>>>>>>>>>>>>>> I
> >>
> >>>>>>>>>>>>>>>>>>>>
> > would
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > disagree, it's
> >> >>>>>>>>>>>>> actually a specialised
> > form of
> >> >>>>>>>>>>>>>>>>
> > interceptor.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > The best use case I know
> >> >>>>>>>>>>>>> of is the one John
> > mentions -
> >> >>>>>>>>>>>>>>>>>
> > creating
> >>
> >>>>>>>>>>>>>>>>>>>>
> > type
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > safe
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > references to queries:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > @QueryService
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > interface UserQuery {
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > @Query("select u
> >> >>>>>>>>>>>>> from User u")
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > public List<User>
> >> >>>>>>>>>>>>> getAllUsers();
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > @Query("select u
> >> >>>>>>>>>>>>> from User u order by
> > u.name")
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > public List<User>
> >> >>>>>>>>>>>>>
> > getAllUsersSortedByName();
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > }
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > Now, it may be the case
> >> >>>>>>>>>>>>> that there aren't
> > any other use
> >> >>>>>>>>>>>>>>>> cases
> >> >>>>>>>>>>>>>>>>>>
> > for
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > service
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > handlers, in which case
> >> >>>>>>>>>>>>> we should perhaps just
> > offer
> >> >>>>>>>>>>>>>>>> this
> >>
> >>>>>>>>>>>>>>>>>>>>
> > particular
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > service handler -
> >> >>>>>>>>>>>>> references to type
> > safe queries - as I
> >> >>>>>>>>>>>>>>>> think
> >>
> >>>>>>>>>>>>>>>>>>>>
> > this
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > is
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > an
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > extremely powerful idea.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > Note, that at the moment
> >> >>>>>>>>>>>>> service handlers are
> > scheduled
> >> >>>>>>>>>>>>>>>> for
> >> >>>>>>>>>>>>>>>>> CDI
> >>
> >>>>>>>>>>>>>>>>>>>>
> > 1.1.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > On 7 Mar 2012, at 02:35,
> >> >>>>>>>>>>>>> Jason Porter wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Somewhat. I
> >> >>>>>>>>>>>>> wouldn't really
> > think of them as overrides,
> >> >>>>>>>>>>>>>>>> they,
> >> >>>>>>>>>>>>>>>>>> to
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > me,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > seem more like items to
> >> >>>>>>>>>>>>> do in addition to
> > whatever the
> >> >>>>>>>>>>>>>>>>>
> > original
> >>
> >>>>>>>>>>>>>>>>>>>>
> > impl
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > does.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > ServiceHandlers to me
> >> >>>>>>>>>>>>> seem more like super
> >> >>>>>>>>>>>>>>>>
> > interceptors.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Sent from my iPhone
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > On Mar 6, 2012, at
> >> >>>>>>>>>>>>> 19:23, "John D.
> > Ament" <
> >>
> >>>>>>>>>>>>>>>>>>>>
> > john.d.ament@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > @jason
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I think the
> >> >>>>>>>>>>>>> concepts are very
> > dissimilar.
> >> >>>>>>>>>>>>>>>>
> > servicehandlers
> >>
> >>>>>>>>>>>>>>>>>>>>
> > create
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > implementation.
> >> >>>>>>>>>>>>> delegates are more
> > like overrides and
> >> >>>>>>>>>>>>>>>> need
> >> >>>>>>>>>>>>>>>>> to
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > know
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > about
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > the method
> >> >>>>>>>>>>>>> signature.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > On Tue, Mar 6,
> >> >>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> > Porter <
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > lightguard.jp@gmail.com
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I think the
> >> >>>>>>>>>>>>> idea of
> > ServiceHandlers are good, but,
> >> >>>>>>>>>>>>>>>> could
> >> >>>>>>>>>>>>>>>> we
> >> >>>>>>>>>>>>>>>>>>
> > not
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > do
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > this
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > with
> >> >>>>>>>>>>>>> delegates?
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Sent from my
> >> >>>>>>>>>>>>> iPhone
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > On Mar 6,
> >> >>>>>>>>>>>>> 2012, at 19:05,
> > "John D. Ament" <
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > john.d.ament@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > @mark
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I
> >> >>>>>>>>>>>>> don't think
> > it's a hard requirement for it to be
> >> >>>>>>>>>>>>>>>> on an
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > interface.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > One of
> >> >>>>>>>>>>>>> the best use-cases we
> > built at my job is
> >> >>>>>>>>>>>>>>>> using it
> >> >>>>>>>>>>>>>>>>> for
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > calling
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > PL/SQL.
> >> >>>>>>>>>>>>> The JDBC bindings do
> > work, but not pretty.
> >> >>>>>>>>>>>>>>>> we
> >> >>>>>>>>>>>>>>>>> were
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > able to
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > create
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > a fairly
> >> >>>>>>>>>>>>> clean wrapper API,
> > generic enough for
> >> >>>>>>>>>>>>>>>> binding
> >> >>>>>>>>>>>>>>>>>>
> > in/out
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > parameters.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > JOhn
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > On Tue,
> >> >>>>>>>>>>>>> Mar 6, 2012 at 12:58
> > PM, Mark Struberg <
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > struberg@yahoo.de>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> actually I don't
> > really see a real benefit. I just
> >> >>>>>>>>>>>>>>>> don't
> >> >>>>>>>>>>>>>>>>>>
> > yet
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > grok
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > use
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > case
> >> >>>>>>>>>>>>> for real world
> > projects.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Why
> >> >>>>>>>>>>>>> would one intercept an
> > Interface and delegate
> >> >>>>>>>>>>>>>>>> the
> >> >>>>>>>>>>>>>>>>> calls
> >>
> >>>>>>>>>>>>>>>>>>>> to
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > a
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > method
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> handler?
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > This
> >> >>>>>>>>>>>>> could be neat for
> > mocking, but there are
> >> >>>>>>>>>>>>>>>> better
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > frameworks for
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > that.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > thus
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > -0.2
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> LieGrue,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > strub
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > -----
> >> >>>>>>>>>>>>> Original Message -----
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> From: Gerhard Petracek
> >> >>>>>>>>>>>>>>>>
> > <ge...@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> To:
> > deltaspike-dev@incubator.apache.org
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Cc:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Sent: Tuesday, March
> > 6, 2012 5:15 PM
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> > [DELTASPIKE-113] Review and
> >> >>>>>>>>>>>>>>>>>
> > Discuss
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> ServiceHandler
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> if you have a lot of
> > shared code, you can extract
> >> >>>>>>>>>>>>>>>> it
> >> >>>>>>>>>>>>>>>> in
> >> >>>>>>>>>>>>>>>>>>
> > 1-n
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > method/s or
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > an
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> abstract class which
> > is still easier than a new
> >> >>>>>>>>>>>>>>>> concept.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> at least i haven't
> > seen an use-case which really
> >> >>>>>>>>>>>>>>>> needed
> >> >>>>>>>>>>>>>>>>>>
> > it.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > that
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > was
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> reason for a +0 (which
> > still means that i'm ok
> >> >>>>>>>>>>>>>>>> with
> >> >>>>>>>>>>>>>>>>> adding
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > it).
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> 2012/3/6 Pete Muir
> > <pm...@redhat.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > So, you mean just write a bean with all the
> >> >>>>>>>>>>>>>>>>
> > boilerplate
> >>
> >>>>>>>>>>>>>>>>>>>>
> > code
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > in
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > it?
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > On 6 Mar 2012, at 15:58, Gerhard Petracek
> >> >>>>>>>>>>>>> wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > hi pete,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > instead of the interface you can just
> >> >>>>>>>>>>>>> implement
> >> >>>>>>>>>>>>>>>> a
> >> >>>>>>>>>>>>>>>> bean
> >>
> >>>>>>>>>>>>>>>>>>>>
> > which
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > does
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > same.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/6 Pete Muir
> >> >>>>>>>>>>>>>
> > <pm...@redhat.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > What CDI mechanism would you use
> >> >>>>>>>>>>>>> instead?
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > On 5 Mar 2012, at 08:47, Gerhard
> >> >>>>>>>>>>>>> Petracek
> >> >>>>>>>>>>>>>>>> wrote:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > +0
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > no -1 because there are
> >> >>>>>>>>>>>>> use-cases for it.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > no +1 because i would use std.
> >> >>>>>>>>>>>>> cdi mechanisms
> >> >>>>>>>>>>>>>>>>>
> > instead.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/4 Gerhard Petracek <
> >> >>>>>>>>>>>>>>>>>
> > gerhard.petracek@gmail.com
> >>
> >>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > hi john,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > the sub-task is perfectly
> >> >>>>>>>>>>>>> fine.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > gerhard
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > 2012/3/4 John D. Ament
> >> >>>>>>>>>>>>>>>>
> > <jo...@gmail.com>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Hi All
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I wanted to bring up
> >> >>>>>>>>>>>>> the subject of
> >> >>>>>>>>>>>>>>>>>
> > ServiceHandler.
> >> >>>>>>>>>>>>>>>>>> I
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> added 113 as a
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > child
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > of DELTASPIKE-2, looked
> >> >>>>>>>>>>>>> appropriate but not
> >> >>>>>>>>>>>>>>>> 100%
> >> >>>>>>>>>>>>>>>>>>
> > sure
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> (so please let
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > me
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > know if you think
> >> >>>>>>>>>>>>> it's not
> > appropriate as a
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> child).
> > ServiceHandler
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > is
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > a
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > feature in Solder that
> >> >>>>>>>>>>>>> allows you to define
> >> >>>>>>>>>>>>>>>> an
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> interceptor that
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > manages
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > generic calls against
> >> >>>>>>>>>>>>> an injected interface.
> >> >>>>>>>>>>>>>>>> The
> >> >>>>>>>>>>>>>>>>>>
> > API
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> is as follows:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > -
> >> >>>>>>>>>>>>>
> > @ServiceHandlerType(Class<?> clazz) -
> >> >>>>>>>>>>>>>>>> placed
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> on an annotation that
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > would
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > be placed on the
> >> >>>>>>>>>>>>> interface. Indicates
> > what
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> interceptor would be
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > invoked
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > for calls against this
> >> >>>>>>>>>>>>> interface.
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > It's then up to the
> >> >>>>>>>>>>>>> application
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> developer/framework
> > author to define
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > annotations that go on
> >> >>>>>>>>>>>>> methods, as well as
> >> >>>>>>>>>>>>>>>> the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> interceptor itself
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> > that
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > will
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > be invoked. The
> >> >>>>>>>>>>>>> feature for
> > ServiceHandler
> >> >>>>>>>>>>>>>>>> would
> >> >>>>>>>>>>>>>>>>> be
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> to provide the
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > API of
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > the type and then the
> >> >>>>>>>>>>>>> infrastructure
> >> >>>>>>>>>>>>>>>> required
> > to
> >> >>>>>>>>>>>>>>>>>>
> > make
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> the interceptor
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> > be
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > called. Existing
> >> >>>>>>>>>>>>> documentation of the
> >> >>>>>>>>>>>>>>>> feature:
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>
> > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >> >>>>>>>>>>>>>>>> ser
> >> >>>>>>>>>>>>>>>>
> > vicehandler.html
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Regards,
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > john
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>> Jason Porter
> >> >>>>>>>>>>>>>>>
> > http://lightguard-jp.blogspot.com
> >> >>>>>>>>>>>>>>>
> > http://twitter.com/lightguardjp
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Software
> > Engineer
> >> >>>>>>>>>>>>>>> Open Source
> > Advocate
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> PGP key id:
> > 926CCFF5
> >> >>>>>>>>>>>>>>> PGP key
> > available at: keyserver.net, pgp.mit.edu
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Jason Porter
> >> >> http://lightguard-jp.blogspot.com
> >> >> http://twitter.com/lightguardjp
> >> >>
> >> >> Software Engineer
> >> >> Open Source Advocate
> >> >>
> >> >> PGP key id: 926CCFF5
> >> >> PGP key available at: keyserver.net, pgp.mit.edu
> >> >>
> >>
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
I guess because it might overlap with other qualifiers added in some cases.
What do we gain for making it a qualifier?
Another important difference to CDI interceptors is that they are always @Dependent to the intercepted instance.
Whereas the ServiceHandler should be of NormalScope, isn't?
LieGrue,
strub
----- Original Message -----
> From: John D. Ament <jo...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Saturday, December 22, 2012 7:56 PM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>
> Pete,
>
> Regarding interceptors - I think what I have is pretty close to the
> interceptor definition, except this should only end up working on a
> class/interface (I think?)
>
> Also, why wouldn't we want the annotation to also be a qualifier?
>
> John
>
>
> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
>
>>
>> On 21 Dec 2012, at 02:21, John D. Ament wrote:
>>
>> > Hi all,
>> >
>> > So just to summarize the current proposal:
>> >
>> > - Create a new annotation @ServiceHandlerBinding (in core/api) which
> will
>> > be placed on on the interface that defines points of the
>> > - Create a new annotation @ServiceHandler (in core/api) (I think based
> on
>> > below this isn't needed since we have the interface now).
>> > - Create an extension that can generate object proxies that link calls
> to
>> > methods on the - org.apache.deltaspike.core.api....
>> >
>> > Define the binding type annotation:
>> >
>> > @ServiceHandlerBinding
>> > @Qualifier
>> > public @interface QueryHandler {
>> > }
>>
>> I don't think we want @Qualifier here.
>>
>> >
>> > which will define the relationship between the interface/abstract
> class
>> > that will use the service handler and the class that will serve as the
>> > invocation handler.
>> >
>> > For example, we can use @QueryHandler on an interface:
>> >
>> > @QueryHandler
>> > public interface PersonDAO {
>> > //...
>> > }
>> >
>> > When the container finds this interface it will identify the
> appropriate
>> > InvocationHandler, based on the following matches:
>> >
>> > - Implements InvocationHandler
>>
>> Yes.
>>
>> > - Is annotated @QueryHandler
>>
>> Ish, this should follow standard CDI resolution rules, you can copy the
>> way interceptor bindings work here.
>>
>> > - Is annotated @ServiceHandler
>>
>> Yes
>>
>> >
>> > DeltaSpike will provide a proxied object where all abstract method
> calls
>> > are delegated to the InvocationHandler. The InvocationHandler will
> need
>> to
>> > have logic to handle all methods as defined within the class, as long
> as
>> > that method is invoked through the InvocationHandler.
>> >
>> > @QueryHandler @ServiceHandler
>> > public QueryHandlerInvoker implements InvocationHandler {
>> >
>> > public Object invoke(Object proxy, Method method, Object[] args) {
>> > if(method.getName().startsWith("find..."){
>> > //...
>> > }
>> > return null;
>> >
>> > }
>> > }
>> >
>> > In addition, the ServiceHandlerBinding can be placed on an abstract
>> class.
>> > In this case, only abstract methods will be passed to the
>> > InvocationHandler.
>> >
>> > @QueryHandler
>> > public abstract interface PersonDAO {
>> > public String doSomethingConcrete() {
>> > return "concrete";
>> > }
>> >
>> > public abstract Person find(int id);
>> > }
>> >
>> > Only the find method will be wrapped, the method doSomethingConcrete
> will
>> > be invoked directly. When interacting with an abstract class, the
>> > InvocationHandler can call methods on the proxied object.
>> >
>> > Finally, the app developer will be able to simply inject their
>> > interface/abstract class in to their beans to perform work:
>> >
>> > @Inject @QueryHandler PersonDAO dao;
>> >
>> > Questions:
>> >
>> > Should we provide a store (simple key/value map) to keep a history of
>> found
>> > object types and how they map?
>>
>> You mean like BeanManager.resolveInterceptors() ? I guess this is useful.
>>
>> > Should we depend on certain libraries for proxying (e.g. javassist, I
>> think
>> > both Weld & OWB use this still?)
>>
>> If you want to just cover interfaces, it's easy, you can use proxying
> from
>> the JDK. Otherwise yes you need to pick a lib.
>>
>> Weld doesn't use javassist for proxying, but does for other stuff.
>>
>> > Since we now use the interface InvocationHandler should we rename the
>> > binding to be InvocationHandlerBinding?
>>
>> Yes, this makes sense
>>
>> > I also think it's not necessary to
>> > have @ServiceHandler since the marker interface now exists.
>>
>> +1
>>
>> >
>> > Comments welcome..
>> >
>> > John
>> >
>> >
>> >
>> >
>> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter
> <lightguard.jp@gmail.com
>> >wrote:
>> >
>> >> +1 for @ServiceHandler
>> >>
>> >>
>> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
> <john.d.ament@gmail.com
>> >>> wrote:
>> >>
>> >>> If we're still calling the feature
> "ServiceHandler" then why not
>> >>> @ServiceHandler?
>> >>>
>> >>>
>> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
>> >>> <rm...@gmail.com>wrote:
>> >>>
>> >>>> if we don't need it perfect, if we need it we'll
> just use another name
>> >>>> @DSHandler, @Handler...whatever it is ;)
>> >>>>
>> >>>> Romain Manni-Bucau
>> >>>> Twitter: @rmannibucau
>> >>>> Blog: http://rmannibucau.wordpress.com/
>> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>>> Github: https://github.com/rmannibucau
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
>> >>>>> :-) Yes for sure. I suspect we dont' need
> @InvocationHandler at all.
>> >>>>>
>> >>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
>> >>>>>
>> >>>>>> The problem I have is that now InvocationHandler
> is both an
>> >> interface
>> >>>> and
>> >>>>>> an @interface which will make it impossible for
> imports. I don't
>> >>> think
>> >>>>>> they should have the same name.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir
> <pm...@redhat.com>
>> >> wrote:
>> >>>>>>
>> >>>>>>>
>> >>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>> >>>>>>>
>> >>>>>>>> All,
>> >>>>>>>>
>> >>>>>>>> So mostly ok from my perspective. One
> thing to note:
>> >>>>>>>>
>> >>>>>>>> @InvocationHandlerBinding
>> >>>>>>>> public @interface Repository {}
>> >>>>>>>>
>> >>>>>>>> @Repository
>> >>>>>>>> public interface MyRepository {
>> >>>>>>>> ...
>> >>>>>>>> }
>> >>>>>>>>
>> >>>>>>>> @Repository @InvocationHandler
>> >>>>>>>> public class MyInvocationHandler
> implements InvocationHandler {
>> >>>>>>>> ...
>> >>>>>>>> }
>> >>>>>>>>
>> >>>>>>>> Why do we have a @InvocationHandler here?
> Is it supposed to be
>> >>>>>>>> @InvocationHandlerBinding instead? If so,
> is it really needed
>> >> here?
>> >>>>>>>
>> >>>>>>> No, it should be @InvocationHandler, it's
> analagous to
>> >> @Interceptor.
>> >>>> It's
>> >>>>>>> not 100% necessary as we already implement the
> interface, which is
>> >>>> enough
>> >>>>>>> of the marker.
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> Thinking about the implementation for
> this, I think this actually
>> >>>> becomes
>> >>>>>>>> easier to use and easier to understand
> over the Solder solution.
>> >>> The
>> >>>>>>>> implementation of the InvocationHandler
> becomes a true CDI bean.
>> >>>>>>>>
>> >>>>>>>> Should DS support Interceptors and
> Decorators on
>> >>>>>>>> InvocationHandler beans?
>> >>>>>>>>
>> >>>>>>>> Do you mean the implementation class or
> the interface?
>> >>>>>>>>
>> >>>>>>>> John
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain
> Manni-Bucau
>> >>>>>>>> <rm...@gmail.com>wrote:
>> >>>>>>>>
>> >>>>>>>>> i'd rather say no because the idea
> is to ease "util" extension
>> >>>>>>>>> writing. that's clearly not
> intended to be full business beans
>> >> IMO
>> >>>> (at
>> >>>>>>>>> least for a first step)
>> >>>>>>>>>
>> >>>>>>>>> That's why i'd leave it as
> this for now
>> >>>>>>>>>
>> >>>>>>>>> wdyt?
>> >>>>>>>>>
>> >>>>>>>>> Romain Manni-Bucau
>> >>>>>>>>> Twitter: @rmannibucau
>> >>>>>>>>> Blog:
> http://rmannibucau.wordpress.com/
>> >>>>>>>>> LinkedIn:
> http://fr.linkedin.com/in/rmannibucau
>> >>>>>>>>> Github: https://github.com/rmannibucau
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> 2012/12/20 Arne Limburg
> <ar...@openknowledge.de>:
>> >>>>>>>>>> Mark refers to my call stack.
>> >>>>>>>>>>
>> >>>>>>>>>> Out of the box this call stack
> would exist just in OWB, because
>> >>> Weld
>> >>>>>>>>> would
>> >>>>>>>>>> not apply any Interceptors or
> Decorators...
>> >>>>>>>>>>
>> >>>>>>>>>> The question is: Should DS support
> Interceptors and Decorators
>> >> on
>> >>>>>>>>>> InvocationHandler beans? My answer
> would be: yes, if our
>> >>>> implementation
>> >>>>>>>>>> shall be a preview of CDI-110.
>> >>>>>>>>>> And that would make things
> complicated in the implementation...
>> >>>>>>>>>>
>> >>>>>>>>>> Am 20.12.12 12:11 schrieb
> "Romain Manni-Bucau" unter
>> >>>>>>>>>> <rm...@gmail.com>:
>> >>>>>>>>>>
>> >>>>>>>>>>> is it an issue for
> servicehandler? i don't think so
>> >>>>>>>>>>>
>> >>>>>>>>>>> it is often used to get util
> classes dynamically created, it is
>> >>>> rarely
>> >>>>>>>>>>> (i never saw it) decorated
> directly
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Romain Manni-Bucau
>> >>>>>>>>>>> Twitter: @rmannibucau
>> >>>>>>>>>>> Blog:
> http://rmannibucau.wordpress.com/
>> >>>>>>>>>>> LinkedIn:
> http://fr.linkedin.com/in/rmannibucau
>> >>>>>>>>>>> Github:
> https://github.com/rmannibucau
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> 2012/12/20 Mark Struberg
> <st...@yahoo.de>:
>> >>>>>>>>>>>> we stumbled about this
> lately. It seems CDI only forces
>> >> support
>> >>>> for
>> >>>>>>>>>>>> interceptors and
> decorators for CDI-annotated classes, but not
>> >>> for
>> >>>>>>>>>>>> Bean<T> which get
> added via extensions nor even producer
>> >> methods
>> >>>> and
>> >>>>>>>>>>>> fields :/
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Of course OWB does it, but
> it would be not portable...
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> LieGrue,
>> >>>>>>>>>>>> strub
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> ----- Original Message
> -----
>> >>>>>>>>>>>>> From: Arne Limburg
> <ar...@openknowledge.de>
>> >>>>>>>>>>>>> To:
> "deltaspike-dev@incubator.apache.org"
>> >>>>>>>>>>>>>
> <de...@incubator.apache.org>
>> >>>>>>>>>>>>> Cc:
>> >>>>>>>>>>>>> Sent: Thursday,
> December 20, 2012 10:18 AM
>> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> [DELTASPIKE-113] Review and Discuss
>> >>>>>>>>>>>>> ServiceHandler
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> T wo things about
> this: First: I don't like from the solder
>> >>>>>>> approach,
>> >>>>>>>>>>>>> because the interface
> is annotated instead of the
>> >>> implementation.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Second, if we
> implement this we should conceptually make
>> >> clear
>> >>>> how
>> >>>>>>> it
>> >>>>>>>>>>>>> differentiates from
> Interceptors and Decorators. And
>> >>> personally I
>> >>>>>>>>> think
>> >>>>>>>>>>>>> this would work better
> with the InvocationHandler approach
>> >> than
>> >>>> with
>> >>>>>>>>> an
>> >>>>>>>>>>>>> approach that is very
> similar to interceptors.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> So +1 for an approach
> like this:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
> @HandlesInvocationsOn(MyInterface.class)
>> >>>>>>>>>>>>> public class
> MyInvocationHandler implements
>> >> InvocationHandler {
>> >>>>>>>>>>>>> ...
>> >>>>>>>>>>>>> }
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Technically we would
> register a custom Bean for every found
>> >>>>>>>>>>>>> InvocationHandler with
> that annotation and take over the
>> >>>>>>>>>>>>> interceptor-bindings
> from the interfaceŠ
>> >>>>>>>>>>>>> So the invocation
> stack would be clear, too:
>> >>>>>>>>>>>>> First Interceptors,
>> >>>>>>>>>>>>> Second Decorators,
>> >>>>>>>>>>>>> Third
> InvocationHandler
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Wdyt?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Arne
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Am 20.12.12 01:53
> schrieb "Romain Manni-Bucau" unter
>> >>>>>>>>>>>>>
> <rm...@gmail.com>:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> that's a need,
> DS targets CDI 1.0 for now so just make this
>> >>>> solder
>> >>>>>>>>>>>>>> part portable ans
> it should be fine
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Romain Manni-Bucau
>> >>>>>>>>>>>>>> Twitter:
> @rmannibucau
>> >>>>>>>>>>>>>> Blog:
> http://rmannibucau.wordpress.com/
>> >>>>>>>>>>>>>> LinkedIn:
> http://fr.linkedin.com/in/rmannibucau
>> >>>>>>>>>>>>>> Github:
> https://github.com/rmannibucau
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> 2012/12/20 Jason
> Porter <li...@gmail.com>:
>> >>>>>>>>>>>>>>> At this point,
> I'd say just do it as is in solder.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Wed, Dec
> 19, 2012 at 5:25 PM, John D. Ament
>> >>>>>>>>>>>>>>>
> <jo...@gmail.com>wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Hi All,
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Regarding
> the two open questions:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 1) the
> approach (including the name/s) we agree on will be
>> >>>> used
>> >>>>>>>>>>>>> also
>> >>>>>>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>> cdi 1.1
> (the only difference is the package)
>> >>>>>>>>>>>>>>>> 2) the eg
> has a different opinion about it ->
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> It looks
> like the JSR's answer
>> >>>>>>>>>>>>>>>>
> (https://issues.jboss.org/browse/CDI-110 )
>> >>>>>>>>>>>>>>>> is still
> unresolved - I'm not sure if we can get any
>> >> further
>> >>>>>>>>>>>>> answer at
>> >>>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>> time. The
> last posts on the subject seem to discuss using
>> >>>>>>>>>>>>> something
>> >>>>>>>>>>>>>>>> along
>> >>>>>>>>>>>>>>>> the lines
> of an invocation handler, which I think would
>> >> work
>> >>>>>>> well.
>> >>>>>>>>>>>>>>>> Since
>> >>>>>>>>>>>>>>>> we have
> some features coming up that are interested in
>> >>> having
>> >>>>>>>>>>>>> service
>> >>>>>>>>>>>>>>>> handlers
> available, do we
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 1.
> Implement as is, or similar to, what is currently in
>> >>>> Solder?
>> >>>>>>>>>>>>>>>> 2. Push EG
> on a resolution
>> >>>>>>>>>>>>>>>> 3. Do it
> using invocation handlers.
>> >>>>>>>>>>>>>>>> 4. Do it
> some other way?
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> John
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Wed,
> Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>> >>>>>>>>>>>>>>>>
> gerhard.petracek@gmail.com
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> hi
> john,
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> as
> mentioned before we need the answers to the existing
>> >>>>>>>>>>>>> questions.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
> regards,
>> >>>>>>>>>>>>>>>>>
> gerhard
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
> 2012/4/4 John D. Ament <jo...@gmail.com>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
> All,
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> I
> kind of let this one and the other drop off my radar,
>> >> I
>> >>>>>>>>>>>>>>>> apologize.
>> >>>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>>>>
> looks like where we last left off, Gerhard was still
>> >>>>>>>>>>>>> requesting
>> >>>>>>>>>>>>>>>>>
> additional
>> >>>>>>>>>>>>>>>>>>
> comments from everyone. Any other feedback?
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
> John
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On
> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>> >>>>>>>>>>>>>>>>>>
> gerhard.petracek@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>> hi
> george,
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>> thx
> for the information. i thought there might be at
>> >>>>>>>>>>>>> least some
>> >>>>>>>>>>>>>>>>>>
> additional
>>
>>>>>>>>>>>>>>>>>>>>
> answers/clarifications, since pete asked for them in
>> >>>>>>>>>>>>> several
>> >>>>>>>>>>>>>>>> comments.
>>
>>>>>>>>>>>>>>>>>>>>
> -> imo we should continue with them.
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
> 2012/3/12 George Gastaldi
>> >>>>>>>>>>>>>
> <ge...@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
> Hello Gerhard,
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
> Yeah, it´s the last state. I know it´s quite
>> >>>>>>>>>>>>> old, but I
>> >>>>>>>>>>>>>>>> haven´t
> had
>> >>>>>>>>>>>>>>>>>>
> time
>>
>>>>>>>>>>>>>>>>>>>>>
> to work on it after that.
>>
>>>>>>>>>>>>>>>>>>>>>
> Regards,
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
> George
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
> 2012/3/12 Gerhard Petracek
>> >>>>>>>>>>>>>
> <ge...@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
> hi george,
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
> thx for the link.
>>
>>>>>>>>>>>>>>>>>>>>>>
> i'm not sure if it is the latest state
>> >>>>>>>>>>>>> of your discussion
>> >>>>>>>>>>>>>>>> and/or
>> >>>>>>>>>>>>>>>>> draft
>>
>>>>>>>>>>>>>>>>>>>>>>
> (at least it's quite old already).
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/7 George Gastaldi
>> >>>>>>>>>>>>>
> <ge...@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> Hi !
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> +1 to #1. I also agree that the term
>> >>>>>>>>>>>>> "Service
> Handler" might
>> >>>>>>>>>>>>>>>> not
>> >>>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>>> so
>>
>>>>>>>>>>>>>>>>>>>>>>>
> appropriate, so it should be discussed
>> >>>>>>>>>>>>> as well.
>>
>>>>>>>>>>>>>>>>>>>>>>>
> Here is the latest pull request with
>> >>>>>>>>>>>>> some comments from
> Pete
>> >>>>>>>>>>>>>>>> yet
>> >>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>> be
>>
>>>>>>>>>>>>>>>>>>>>>>>
> reviewed:
>> >>>>>>>>>>>>>
> https://github.com/jboss/cdi/pull/28
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/7 Pete Muir
>> >>>>>>>>>>>>>
> <pm...@redhat.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> Agreed :-)
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> George is working on it for CDI
>> >>>>>>>>>>>>> 1.1. George, can you
> share
>> >>>>>>>>>>>>>>>> your
>>
>>>>>>>>>>>>>>>>>>>>>>>
> proposal
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> so far?
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> On 7 Mar 2012, at 17:05, Gerhard
>> >>>>>>>>>>>>> Petracek wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> hi pete,
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> independent of my opinion
>> >>>>>>>>>>>>> about the feature
> (which is
>> >>>>>>>>>>>>>>>> still
>> >>>>>>>>>>>>>>>>> +0):
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> if it should be part of cdi
>> >>>>>>>>>>>>> 1.1, we have the
> following
>> >>>>>>>>>>>>>>>> options
>> >>>>>>>>>>>>>>>>>>
> imo:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 1) the approach (including
>> >>>>>>>>>>>>> the name/s) we agree
> on will
>> >>>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>> used
>>
>>>>>>>>>>>>>>>>>>>>
> also
>>
>>>>>>>>>>>>>>>>>>>>>>>
> for
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> cdi 1.1 (the only difference
>> >>>>>>>>>>>>> is the package)
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 2) the eg has a different
>> >>>>>>>>>>>>> opinion about it ->
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 2a) the rest of the eg joins
>> >>>>>>>>>>>>> this discussion
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 2b) we wait for the final
>> >>>>>>>>>>>>> version and just allow
> the same
>> >>>>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>
> cdi
>>
>>>>>>>>>>>>>>>>>>>>>>>
> 1.0
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 3) if the eg doesn't
>> >>>>>>>>>>>>> agree on the idea, it
> should be
>> >>>>>>>>>>>>>>>> re-visited
>> >>>>>>>>>>>>>>>>>>
> for
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> deltaspike (if we really need
>> >>>>>>>>>>>>> it)
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 4) we agree on it independent
>> >>>>>>>>>>>>> of the result in cdi
> 1.1
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 1-3 is ok for me but -1 for
>> >>>>>>>>>>>>> #4
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/7 Pete Muir
>> >>>>>>>>>>>>>
> <pm...@redhat.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> I'm not sure what you
>> >>>>>>>>>>>>> mean by a "super
> interceptor",
>> >>>>>>>>>>>>>>>> but if
>> >>>>>>>>>>>>>>>>> you
>>
>>>>>>>>>>>>>>>>>>>>>>>
> mean it
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> as
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> in "super man"
>> >>>>>>>>>>>>> (something better than
> an interceptor),
>> >>>>>>>>>>>>>>>> then
>> >>>>>>>>>>>>>>>> I
>>
>>>>>>>>>>>>>>>>>>>>
> would
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> disagree, it's
>> >>>>>>>>>>>>> actually a specialised
> form of
>> >>>>>>>>>>>>>>>>
> interceptor.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> The best use case I know
>> >>>>>>>>>>>>> of is the one John
> mentions -
>> >>>>>>>>>>>>>>>>>
> creating
>>
>>>>>>>>>>>>>>>>>>>>
> type
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> safe
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> references to queries:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> @QueryService
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> interface UserQuery {
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> @Query("select u
>> >>>>>>>>>>>>> from User u")
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> public List<User>
>> >>>>>>>>>>>>> getAllUsers();
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> @Query("select u
>> >>>>>>>>>>>>> from User u order by
> u.name")
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> public List<User>
>> >>>>>>>>>>>>>
> getAllUsersSortedByName();
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> }
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> Now, it may be the case
>> >>>>>>>>>>>>> that there aren't
> any other use
>> >>>>>>>>>>>>>>>> cases
>> >>>>>>>>>>>>>>>>>>
> for
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> service
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> handlers, in which case
>> >>>>>>>>>>>>> we should perhaps just
> offer
>> >>>>>>>>>>>>>>>> this
>>
>>>>>>>>>>>>>>>>>>>>
> particular
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> service handler -
>> >>>>>>>>>>>>> references to type
> safe queries - as I
>> >>>>>>>>>>>>>>>> think
>>
>>>>>>>>>>>>>>>>>>>>
> this
>>
>>>>>>>>>>>>>>>>>>>>>>>
> is
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> an
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> extremely powerful idea.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> Note, that at the moment
>> >>>>>>>>>>>>> service handlers are
> scheduled
>> >>>>>>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>>> CDI
>>
>>>>>>>>>>>>>>>>>>>>
> 1.1.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> On 7 Mar 2012, at 02:35,
>> >>>>>>>>>>>>> Jason Porter wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Somewhat. I
>> >>>>>>>>>>>>> wouldn't really
> think of them as overrides,
>> >>>>>>>>>>>>>>>> they,
>> >>>>>>>>>>>>>>>>>> to
>>
>>>>>>>>>>>>>>>>>>>>>>>
> me,
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> seem more like items to
>> >>>>>>>>>>>>> do in addition to
> whatever the
>> >>>>>>>>>>>>>>>>>
> original
>>
>>>>>>>>>>>>>>>>>>>>
> impl
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> does.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> ServiceHandlers to me
>> >>>>>>>>>>>>> seem more like super
>> >>>>>>>>>>>>>>>>
> interceptors.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Sent from my iPhone
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> On Mar 6, 2012, at
>> >>>>>>>>>>>>> 19:23, "John D.
> Ament" <
>>
>>>>>>>>>>>>>>>>>>>>
> john.d.ament@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> @jason
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I think the
>> >>>>>>>>>>>>> concepts are very
> dissimilar.
>> >>>>>>>>>>>>>>>>
> servicehandlers
>>
>>>>>>>>>>>>>>>>>>>>
> create
>>
>>>>>>>>>>>>>>>>>>>>>>>
> the
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> implementation.
>> >>>>>>>>>>>>> delegates are more
> like overrides and
>> >>>>>>>>>>>>>>>> need
>> >>>>>>>>>>>>>>>>> to
>>
>>>>>>>>>>>>>>>>>>>>>>>
> know
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> about
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> the method
>> >>>>>>>>>>>>> signature.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> On Tue, Mar 6,
>> >>>>>>>>>>>>> 2012 at 9:17 PM, Jason
> Porter <
>>
>>>>>>>>>>>>>>>>>>>>>>>
> lightguard.jp@gmail.com
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I think the
>> >>>>>>>>>>>>> idea of
> ServiceHandlers are good, but,
>> >>>>>>>>>>>>>>>> could
>> >>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>
> not
>>
>>>>>>>>>>>>>>>>>>>>>>>
> do
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> this
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> with
>> >>>>>>>>>>>>> delegates?
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Sent from my
>> >>>>>>>>>>>>> iPhone
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> On Mar 6,
>> >>>>>>>>>>>>> 2012, at 19:05,
> "John D. Ament" <
>>
>>>>>>>>>>>>>>>>>>>>>>>
> john.d.ament@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> @mark
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I
>> >>>>>>>>>>>>> don't think
> it's a hard requirement for it to be
>> >>>>>>>>>>>>>>>> on an
>>
>>>>>>>>>>>>>>>>>>>>>>>
> interface.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> One of
>> >>>>>>>>>>>>> the best use-cases we
> built at my job is
>> >>>>>>>>>>>>>>>> using it
>> >>>>>>>>>>>>>>>>> for
>>
>>>>>>>>>>>>>>>>>>>>>>>
> calling
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> PL/SQL.
>> >>>>>>>>>>>>> The JDBC bindings do
> work, but not pretty.
>> >>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>> were
>>
>>>>>>>>>>>>>>>>>>>>>>>
> able to
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> create
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> a fairly
>> >>>>>>>>>>>>> clean wrapper API,
> generic enough for
>> >>>>>>>>>>>>>>>> binding
>> >>>>>>>>>>>>>>>>>>
> in/out
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> parameters.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> JOhn
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> On Tue,
>> >>>>>>>>>>>>> Mar 6, 2012 at 12:58
> PM, Mark Struberg <
>>
>>>>>>>>>>>>>>>>>>>>>>>
> struberg@yahoo.de>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> actually I don't
> really see a real benefit. I just
>> >>>>>>>>>>>>>>>> don't
>> >>>>>>>>>>>>>>>>>>
> yet
>>
>>>>>>>>>>>>>>>>>>>>>>>
> grok
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> the
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> use
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> case
>> >>>>>>>>>>>>> for real world
> projects.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Why
>> >>>>>>>>>>>>> would one intercept an
> Interface and delegate
>> >>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> calls
>>
>>>>>>>>>>>>>>>>>>>> to
>>
>>>>>>>>>>>>>>>>>>>>>>>
> a
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> method
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> handler?
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> This
>> >>>>>>>>>>>>> could be neat for
> mocking, but there are
>> >>>>>>>>>>>>>>>> better
>>
>>>>>>>>>>>>>>>>>>>>>>>
> frameworks for
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> that.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> thus
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> -0.2
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> LieGrue,
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> strub
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> -----
>> >>>>>>>>>>>>> Original Message -----
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> From: Gerhard Petracek
>> >>>>>>>>>>>>>>>>
> <ge...@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> To:
> deltaspike-dev@incubator.apache.org
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> Cc:
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> Sent: Tuesday, March
> 6, 2012 5:15 PM
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> Subject: Re: [DISCUSS]
> [DELTASPIKE-113] Review and
>> >>>>>>>>>>>>>>>>>
> Discuss
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> ServiceHandler
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> if you have a lot of
> shared code, you can extract
>> >>>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>
> 1-n
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> method/s or
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> an
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> abstract class which
> is still easier than a new
>> >>>>>>>>>>>>>>>> concept.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> at least i haven't
> seen an use-case which really
>> >>>>>>>>>>>>>>>> needed
>> >>>>>>>>>>>>>>>>>>
> it.
>>
>>>>>>>>>>>>>>>>>>>>>>>
> that
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> was
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> the
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> reason for a +0 (which
> still means that i'm ok
>> >>>>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>> adding
>>
>>>>>>>>>>>>>>>>>>>>>>>
> it).
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> 2012/3/6 Pete Muir
> <pm...@redhat.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> So, you mean just write a bean with all the
>> >>>>>>>>>>>>>>>>
> boilerplate
>>
>>>>>>>>>>>>>>>>>>>>
> code
>>
>>>>>>>>>>>>>>>>>>>>>>>
> in
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> it?
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> On 6 Mar 2012, at 15:58, Gerhard Petracek
>> >>>>>>>>>>>>> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> hi pete,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> instead of the interface you can just
>> >>>>>>>>>>>>> implement
>> >>>>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>> bean
>>
>>>>>>>>>>>>>>>>>>>>
> which
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> does
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> the
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> same.
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/6 Pete Muir
>> >>>>>>>>>>>>>
> <pm...@redhat.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> What CDI mechanism would you use
>> >>>>>>>>>>>>> instead?
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> On 5 Mar 2012, at 08:47, Gerhard
>> >>>>>>>>>>>>> Petracek
>> >>>>>>>>>>>>>>>> wrote:
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> +0
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> no -1 because there are
>> >>>>>>>>>>>>> use-cases for it.
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> no +1 because i would use std.
>> >>>>>>>>>>>>> cdi mechanisms
>> >>>>>>>>>>>>>>>>>
> instead.
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/4 Gerhard Petracek <
>> >>>>>>>>>>>>>>>>>
> gerhard.petracek@gmail.com
>>
>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> hi john,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> the sub-task is perfectly
>> >>>>>>>>>>>>> fine.
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> gerhard
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 2012/3/4 John D. Ament
>> >>>>>>>>>>>>>>>>
> <jo...@gmail.com>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Hi All
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I wanted to bring up
>> >>>>>>>>>>>>> the subject of
>> >>>>>>>>>>>>>>>>>
> ServiceHandler.
>> >>>>>>>>>>>>>>>>>> I
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> added 113 as a
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> child
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> of DELTASPIKE-2, looked
>> >>>>>>>>>>>>> appropriate but not
>> >>>>>>>>>>>>>>>> 100%
>> >>>>>>>>>>>>>>>>>>
> sure
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> (so please let
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> me
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> know if you think
>> >>>>>>>>>>>>> it's not
> appropriate as a
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> child).
> ServiceHandler
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> is
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> a
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> feature in Solder that
>> >>>>>>>>>>>>> allows you to define
>> >>>>>>>>>>>>>>>> an
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> interceptor that
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> manages
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> generic calls against
>> >>>>>>>>>>>>> an injected interface.
>> >>>>>>>>>>>>>>>> The
>> >>>>>>>>>>>>>>>>>>
> API
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> is as follows:
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> -
>> >>>>>>>>>>>>>
> @ServiceHandlerType(Class<?> clazz) -
>> >>>>>>>>>>>>>>>> placed
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> on an annotation that
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> would
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> be placed on the
>> >>>>>>>>>>>>> interface. Indicates
> what
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> interceptor would be
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> invoked
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> for calls against this
>> >>>>>>>>>>>>> interface.
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> It's then up to the
>> >>>>>>>>>>>>> application
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> developer/framework
> author to define
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> annotations that go on
>> >>>>>>>>>>>>> methods, as well as
>> >>>>>>>>>>>>>>>> the
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> interceptor itself
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
> that
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> will
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> be invoked. The
>> >>>>>>>>>>>>> feature for
> ServiceHandler
>> >>>>>>>>>>>>>>>> would
>> >>>>>>>>>>>>>>>>> be
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> to provide the
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> API of
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> the type and then the
>> >>>>>>>>>>>>> infrastructure
>> >>>>>>>>>>>>>>>> required
> to
>> >>>>>>>>>>>>>>>>>>
> make
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> the interceptor
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
> be
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> called. Existing
>> >>>>>>>>>>>>> documentation of the
>> >>>>>>>>>>>>>>>> feature:
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>
>> >>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>> >>>>>>>>>>>>>>>> ser
>> >>>>>>>>>>>>>>>>
> vicehandler.html
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Regards,
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> john
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>> Jason Porter
>> >>>>>>>>>>>>>>>
> http://lightguard-jp.blogspot.com
>> >>>>>>>>>>>>>>>
> http://twitter.com/lightguardjp
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Software
> Engineer
>> >>>>>>>>>>>>>>> Open Source
> Advocate
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> PGP key id:
> 926CCFF5
>> >>>>>>>>>>>>>>> PGP key
> available at: keyserver.net, pgp.mit.edu
>> >>>>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Jason Porter
>> >> http://lightguard-jp.blogspot.com
>> >> http://twitter.com/lightguardjp
>> >>
>> >> Software Engineer
>> >> Open Source Advocate
>> >>
>> >> PGP key id: 926CCFF5
>> >> PGP key available at: keyserver.net, pgp.mit.edu
>> >>
>>
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Pete,
Regarding interceptors - I think what I have is pretty close to the
interceptor definition, except this should only end up working on a
class/interface (I think?)
Also, why wouldn't we want the annotation to also be a qualifier?
John
On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <pm...@redhat.com> wrote:
>
> On 21 Dec 2012, at 02:21, John D. Ament wrote:
>
> > Hi all,
> >
> > So just to summarize the current proposal:
> >
> > - Create a new annotation @ServiceHandlerBinding (in core/api) which will
> > be placed on on the interface that defines points of the
> > - Create a new annotation @ServiceHandler (in core/api) (I think based on
> > below this isn't needed since we have the interface now).
> > - Create an extension that can generate object proxies that link calls to
> > methods on the - org.apache.deltaspike.core.api....
> >
> > Define the binding type annotation:
> >
> > @ServiceHandlerBinding
> > @Qualifier
> > public @interface QueryHandler {
> > }
>
> I don't think we want @Qualifier here.
>
> >
> > which will define the relationship between the interface/abstract class
> > that will use the service handler and the class that will serve as the
> > invocation handler.
> >
> > For example, we can use @QueryHandler on an interface:
> >
> > @QueryHandler
> > public interface PersonDAO {
> > //...
> > }
> >
> > When the container finds this interface it will identify the appropriate
> > InvocationHandler, based on the following matches:
> >
> > - Implements InvocationHandler
>
> Yes.
>
> > - Is annotated @QueryHandler
>
> Ish, this should follow standard CDI resolution rules, you can copy the
> way interceptor bindings work here.
>
> > - Is annotated @ServiceHandler
>
> Yes
>
> >
> > DeltaSpike will provide a proxied object where all abstract method calls
> > are delegated to the InvocationHandler. The InvocationHandler will need
> to
> > have logic to handle all methods as defined within the class, as long as
> > that method is invoked through the InvocationHandler.
> >
> > @QueryHandler @ServiceHandler
> > public QueryHandlerInvoker implements InvocationHandler {
> >
> > public Object invoke(Object proxy, Method method, Object[] args) {
> > if(method.getName().startsWith("find..."){
> > //...
> > }
> > return null;
> >
> > }
> > }
> >
> > In addition, the ServiceHandlerBinding can be placed on an abstract
> class.
> > In this case, only abstract methods will be passed to the
> > InvocationHandler.
> >
> > @QueryHandler
> > public abstract interface PersonDAO {
> > public String doSomethingConcrete() {
> > return "concrete";
> > }
> >
> > public abstract Person find(int id);
> > }
> >
> > Only the find method will be wrapped, the method doSomethingConcrete will
> > be invoked directly. When interacting with an abstract class, the
> > InvocationHandler can call methods on the proxied object.
> >
> > Finally, the app developer will be able to simply inject their
> > interface/abstract class in to their beans to perform work:
> >
> > @Inject @QueryHandler PersonDAO dao;
> >
> > Questions:
> >
> > Should we provide a store (simple key/value map) to keep a history of
> found
> > object types and how they map?
>
> You mean like BeanManager.resolveInterceptors() ? I guess this is useful.
>
> > Should we depend on certain libraries for proxying (e.g. javassist, I
> think
> > both Weld & OWB use this still?)
>
> If you want to just cover interfaces, it's easy, you can use proxying from
> the JDK. Otherwise yes you need to pick a lib.
>
> Weld doesn't use javassist for proxying, but does for other stuff.
>
> > Since we now use the interface InvocationHandler should we rename the
> > binding to be InvocationHandlerBinding?
>
> Yes, this makes sense
>
> > I also think it's not necessary to
> > have @ServiceHandler since the marker interface now exists.
>
> +1
>
> >
> > Comments welcome..
> >
> > John
> >
> >
> >
> >
> > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter <lightguard.jp@gmail.com
> >wrote:
> >
> >> +1 for @ServiceHandler
> >>
> >>
> >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <john.d.ament@gmail.com
> >>> wrote:
> >>
> >>> If we're still calling the feature "ServiceHandler" then why not
> >>> @ServiceHandler?
> >>>
> >>>
> >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> >>> <rm...@gmail.com>wrote:
> >>>
> >>>> if we don't need it perfect, if we need it we'll just use another name
> >>>> @DSHandler, @Handler...whatever it is ;)
> >>>>
> >>>> Romain Manni-Bucau
> >>>> Twitter: @rmannibucau
> >>>> Blog: http://rmannibucau.wordpress.com/
> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>> Github: https://github.com/rmannibucau
> >>>>
> >>>>
> >>>>
> >>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
> >>>>> :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
> >>>>>
> >>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
> >>>>>
> >>>>>> The problem I have is that now InvocationHandler is both an
> >> interface
> >>>> and
> >>>>>> an @interface which will make it impossible for imports. I don't
> >>> think
> >>>>>> they should have the same name.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com>
> >> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> >>>>>>>
> >>>>>>>> All,
> >>>>>>>>
> >>>>>>>> So mostly ok from my perspective. One thing to note:
> >>>>>>>>
> >>>>>>>> @InvocationHandlerBinding
> >>>>>>>> public @interface Repository {}
> >>>>>>>>
> >>>>>>>> @Repository
> >>>>>>>> public interface MyRepository {
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> @Repository @InvocationHandler
> >>>>>>>> public class MyInvocationHandler implements InvocationHandler {
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Why do we have a @InvocationHandler here? Is it supposed to be
> >>>>>>>> @InvocationHandlerBinding instead? If so, is it really needed
> >> here?
> >>>>>>>
> >>>>>>> No, it should be @InvocationHandler, it's analagous to
> >> @Interceptor.
> >>>> It's
> >>>>>>> not 100% necessary as we already implement the interface, which is
> >>>> enough
> >>>>>>> of the marker.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Thinking about the implementation for this, I think this actually
> >>>> becomes
> >>>>>>>> easier to use and easier to understand over the Solder solution.
> >>> The
> >>>>>>>> implementation of the InvocationHandler becomes a true CDI bean.
> >>>>>>>>
> >>>>>>>> Should DS support Interceptors and Decorators on
> >>>>>>>> InvocationHandler beans?
> >>>>>>>>
> >>>>>>>> Do you mean the implementation class or the interface?
> >>>>>>>>
> >>>>>>>> John
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> >>>>>>>> <rm...@gmail.com>wrote:
> >>>>>>>>
> >>>>>>>>> i'd rather say no because the idea is to ease "util" extension
> >>>>>>>>> writing. that's clearly not intended to be full business beans
> >> IMO
> >>>> (at
> >>>>>>>>> least for a first step)
> >>>>>>>>>
> >>>>>>>>> That's why i'd leave it as this for now
> >>>>>>>>>
> >>>>>>>>> wdyt?
> >>>>>>>>>
> >>>>>>>>> Romain Manni-Bucau
> >>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> >>>>>>>>>> Mark refers to my call stack.
> >>>>>>>>>>
> >>>>>>>>>> Out of the box this call stack would exist just in OWB, because
> >>> Weld
> >>>>>>>>> would
> >>>>>>>>>> not apply any Interceptors or Decorators...
> >>>>>>>>>>
> >>>>>>>>>> The question is: Should DS support Interceptors and Decorators
> >> on
> >>>>>>>>>> InvocationHandler beans? My answer would be: yes, if our
> >>>> implementation
> >>>>>>>>>> shall be a preview of CDI-110.
> >>>>>>>>>> And that would make things complicated in the implementation...
> >>>>>>>>>>
> >>>>>>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> >>>>>>>>>> <rm...@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>>> is it an issue for servicehandler? i don't think so
> >>>>>>>>>>>
> >>>>>>>>>>> it is often used to get util classes dynamically created, it is
> >>>> rarely
> >>>>>>>>>>> (i never saw it) decorated directly
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
> >>>>>>>>>>>> we stumbled about this lately. It seems CDI only forces
> >> support
> >>>> for
> >>>>>>>>>>>> interceptors and decorators for CDI-annotated classes, but not
> >>> for
> >>>>>>>>>>>> Bean<T> which get added via extensions nor even producer
> >> methods
> >>>> and
> >>>>>>>>>>>> fields :/
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Of course OWB does it, but it would be not portable...
> >>>>>>>>>>>>
> >>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>> strub
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
> >>>>>>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
> >>>>>>>>>>>>> <de...@incubator.apache.org>
> >>>>>>>>>>>>> Cc:
> >>>>>>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
> >>>>>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>>>>>>>>>> ServiceHandler
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> T wo things about this: First: I don't like from the solder
> >>>>>>> approach,
> >>>>>>>>>>>>> because the interface is annotated instead of the
> >>> implementation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Second, if we implement this we should conceptually make
> >> clear
> >>>> how
> >>>>>>> it
> >>>>>>>>>>>>> differentiates from Interceptors and Decorators. And
> >>> personally I
> >>>>>>>>> think
> >>>>>>>>>>>>> this would work better with the InvocationHandler approach
> >> than
> >>>> with
> >>>>>>>>> an
> >>>>>>>>>>>>> approach that is very similar to interceptors.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So +1 for an approach like this:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
> >>>>>>>>>>>>> public class MyInvocationHandler implements
> >> InvocationHandler {
> >>>>>>>>>>>>> ...
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Technically we would register a custom Bean for every found
> >>>>>>>>>>>>> InvocationHandler with that annotation and take over the
> >>>>>>>>>>>>> interceptor-bindings from the interfaceŠ
> >>>>>>>>>>>>> So the invocation stack would be clear, too:
> >>>>>>>>>>>>> First Interceptors,
> >>>>>>>>>>>>> Second Decorators,
> >>>>>>>>>>>>> Third InvocationHandler
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Wdyt?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Arne
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> >>>>>>>>>>>>> <rm...@gmail.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this
> >>>> solder
> >>>>>>>>>>>>>> part portable ans it should be fine
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> >>>>>>>>>>>>>>> At this point, I'd say just do it as is in solder.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> >>>>>>>>>>>>>>> <jo...@gmail.com>wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Regarding the two open questions:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be
> >>>> used
> >>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> cdi 1.1 (the only difference is the package)
> >>>>>>>>>>>>>>>> 2) the eg has a different opinion about it ->
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It looks like the JSR's answer
> >>>>>>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>>>>>>>>>>> is still unresolved - I'm not sure if we can get any
> >> further
> >>>>>>>>>>>>> answer at
> >>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>> time. The last posts on the subject seem to discuss using
> >>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>> along
> >>>>>>>>>>>>>>>> the lines of an invocation handler, which I think would
> >> work
> >>>>>>> well.
> >>>>>>>>>>>>>>>> Since
> >>>>>>>>>>>>>>>> we have some features coming up that are interested in
> >>> having
> >>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>> handlers available, do we
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in
> >>>> Solder?
> >>>>>>>>>>>>>>>> 2. Push EG on a resolution
> >>>>>>>>>>>>>>>> 3. Do it using invocation handlers.
> >>>>>>>>>>>>>>>> 4. Do it some other way?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> John
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>>>>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> as mentioned before we need the answers to the existing
> >>>>>>>>>>>>> questions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I kind of let this one and the other drop off my radar,
> >> I
> >>>>>>>>>>>>>>>> apologize.
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
> >>>>>>>>>>>>> requesting
> >>>>>>>>>>>>>>>>> additional
> >>>>>>>>>>>>>>>>>> comments from everyone. Any other feedback?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> John
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi george,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> thx for the information. i thought there might be at
> >>>>>>>>>>>>> least some
> >>>>>>>>>>>>>>>>>> additional
> >>>>>>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
> >>>>>>>>>>>>> several
> >>>>>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>>>>>> -> imo we should continue with them.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
> >>>>>>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hello Gerhard,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
> >>>>>>>>>>>>> old, but I
> >>>>>>>>>>>>>>>> haven´t had
> >>>>>>>>>>>>>>>>>> time
> >>>>>>>>>>>>>>>>>>>> to work on it after that.
> >>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> George
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
> >>>>>>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> hi george,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> thx for the link.
> >>>>>>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
> >>>>>>>>>>>>> of your discussion
> >>>>>>>>>>>>>>>> and/or
> >>>>>>>>>>>>>>>>> draft
> >>>>>>>>>>>>>>>>>>>>> (at least it's quite old already).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
> >>>>>>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hi !
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
> >>>>>>>>>>>>> "Service Handler" might
> >>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
> >>>>>>>>>>>>> as well.
> >>>>>>>>>>>>>>>>>>>>>> Here is the latest pull request with
> >>>>>>>>>>>>> some comments from Pete
> >>>>>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>> reviewed:
> >>>>>>>>>>>>> https://github.com/jboss/cdi/pull/28
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Agreed :-)
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> George is working on it for CDI
> >>>>>>>>>>>>> 1.1. George, can you share
> >>>>>>>>>>>>>>>> your
> >>>>>>>>>>>>>>>>>>>>>> proposal
> >>>>>>>>>>>>>>>>>>>>>>> so far?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
> >>>>>>>>>>>>> Petracek wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> independent of my opinion
> >>>>>>>>>>>>> about the feature (which is
> >>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>> +0):
> >>>>>>>>>>>>>>>>>>>>>>>> if it should be part of cdi
> >>>>>>>>>>>>> 1.1, we have the following
> >>>>>>>>>>>>>>>> options
> >>>>>>>>>>>>>>>>>> imo:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 1) the approach (including
> >>>>>>>>>>>>> the name/s) we agree on will
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
> >>>>>>>>>>>>> is the package)
> >>>>>>>>>>>>>>>>>>>>>>>> 2) the eg has a different
> >>>>>>>>>>>>> opinion about it ->
> >>>>>>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
> >>>>>>>>>>>>> this discussion
> >>>>>>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
> >>>>>>>>>>>>> version and just allow the same
> >>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> cdi
> >>>>>>>>>>>>>>>>>>>>>> 1.0
> >>>>>>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
> >>>>>>>>>>>>> agree on the idea, it should be
> >>>>>>>>>>>>>>>> re-visited
> >>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
> >>>>>>>>>>>>> it)
> >>>>>>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
> >>>>>>>>>>>>> of the result in cdi 1.1
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
> >>>>>>>>>>>>> #4
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I'm not sure what you
> >>>>>>>>>>>>> mean by a "super interceptor",
> >>>>>>>>>>>>>>>> but if
> >>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>> mean it
> >>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>> in "super man"
> >>>>>>>>>>>>> (something better than an interceptor),
> >>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>> disagree, it's
> >>>>>>>>>>>>> actually a specialised form of
> >>>>>>>>>>>>>>>> interceptor.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The best use case I know
> >>>>>>>>>>>>> of is the one John mentions -
> >>>>>>>>>>>>>>>>> creating
> >>>>>>>>>>>>>>>>>>> type
> >>>>>>>>>>>>>>>>>>>>>>> safe
> >>>>>>>>>>>>>>>>>>>>>>>>> references to queries:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> @QueryService
> >>>>>>>>>>>>>>>>>>>>>>>>> interface UserQuery {
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>>>>>>>>> from User u")
> >>>>>>>>>>>>>>>>>>>>>>>>> public List<User>
> >>>>>>>>>>>>> getAllUsers();
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>>>>>>>>> from User u order by u.name")
> >>>>>>>>>>>>>>>>>>>>>>>>> public List<User>
> >>>>>>>>>>>>> getAllUsersSortedByName();
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Now, it may be the case
> >>>>>>>>>>>>> that there aren't any other use
> >>>>>>>>>>>>>>>> cases
> >>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>>>>>>>>>>> handlers, in which case
> >>>>>>>>>>>>> we should perhaps just offer
> >>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>> particular
> >>>>>>>>>>>>>>>>>>>>>>>>> service handler -
> >>>>>>>>>>>>> references to type safe queries - as I
> >>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Note, that at the moment
> >>>>>>>>>>>>> service handlers are scheduled
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> CDI
> >>>>>>>>>>>>>>>>>>> 1.1.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
> >>>>>>>>>>>>> Jason Porter wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Somewhat. I
> >>>>>>>>>>>>> wouldn't really think of them as overrides,
> >>>>>>>>>>>>>>>> they,
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> me,
> >>>>>>>>>>>>>>>>>>>>>>>>> seem more like items to
> >>>>>>>>>>>>> do in addition to whatever the
> >>>>>>>>>>>>>>>>> original
> >>>>>>>>>>>>>>>>>>> impl
> >>>>>>>>>>>>>>>>>>>>>>> does.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
> >>>>>>>>>>>>> seem more like super
> >>>>>>>>>>>>>>>> interceptors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
> >>>>>>>>>>>>> 19:23, "John D. Ament" <
> >>>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> @jason
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I think the
> >>>>>>>>>>>>> concepts are very dissimilar.
> >>>>>>>>>>>>>>>> servicehandlers
> >>>>>>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>> delegates are more like overrides and
> >>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the method
> >>>>>>>>>>>>> signature.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
> >>>>>>>>>>>>> 2012 at 9:17 PM, Jason Porter <
> >>>>>>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the
> >>>>>>>>>>>>> idea of ServiceHandlers are good, but,
> >>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>> delegates?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent from my
> >>>>>>>>>>>>> iPhone
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
> >>>>>>>>>>>>> 2012, at 19:05, "John D. Ament" <
> >>>>>>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> @mark
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>> don't think it's a hard requirement for it to be
> >>>>>>>>>>>>>>>> on an
> >>>>>>>>>>>>>>>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> One of
> >>>>>>>>>>>>> the best use-cases we built at my job is
> >>>>>>>>>>>>>>>> using it
> >>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
> >>>>>>>>>>>>> The JDBC bindings do work, but not pretty.
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> were
> >>>>>>>>>>>>>>>>>>>>>> able to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a fairly
> >>>>>>>>>>>>> clean wrapper API, generic enough for
> >>>>>>>>>>>>>>>> binding
> >>>>>>>>>>>>>>>>>> in/out
> >>>>>>>>>>>>>>>>>>>>>>>>> parameters.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> JOhn
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
> >>>>>>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>>>>>>>>>>>>>>>>>>>>> struberg@yahoo.de>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> actually I don't really see a real benefit. I just
> >>>>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>>>>>>> grok
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case
> >>>>>>>>>>>>> for real world projects.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why
> >>>>>>>>>>>>> would one intercept an Interface and delegate
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> calls
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> handler?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This
> >>>>>>>>>>>>> could be neat for mocking, but there are
> >>>>>>>>>>>>>>>> better
> >>>>>>>>>>>>>>>>>>>>>> frameworks for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>> Original Message -----
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> From: Gerhard Petracek
> >>>>>>>>>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> Cc:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> >>>>>>>>>>>>>>>>> Discuss
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> ServiceHandler
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> if you have a lot of shared code, you can extract
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> 1-n
> >>>>>>>>>>>>>>>>>>>>>>>>> method/s or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> abstract class which is still easier than a new
> >>>>>>>>>>>>>>>> concept.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> at least i haven't seen an use-case which really
> >>>>>>>>>>>>>>>> needed
> >>>>>>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> reason for a +0 (which still means that i'm ok
> >>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>>>>>> it).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
> >>>>>>>>>>>>>>>> boilerplate
> >>>>>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>> it?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> instead of the interface you can just
> >>>>>>>>>>>>> implement
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> bean
> >>>>>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>>> does
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> same.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>>>>>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
> >>>>>>>>>>>>> instead?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> >>>>>>>>>>>>> Petracek
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> +0
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> no -1 because there are
> >>>>>>>>>>>>> use-cases for it.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
> >>>>>>>>>>>>> cdi mechanisms
> >>>>>>>>>>>>>>>>> instead.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> >>>>>>>>>>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> >>>>>>>>>>>>> fine.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> >>>>>>>>>>>>>>>> <jo...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi All
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
> >>>>>>>>>>>>> the subject of
> >>>>>>>>>>>>>>>>> ServiceHandler.
> >>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> added 113 as a
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> child
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> >>>>>>>>>>>>> appropriate but not
> >>>>>>>>>>>>>>>> 100%
> >>>>>>>>>>>>>>>>>> sure
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> (so please let
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> me
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> know if you think
> >>>>>>>>>>>>> it's not appropriate as a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> child). ServiceHandler
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
> >>>>>>>>>>>>> allows you to define
> >>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> interceptor that
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> manages
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> generic calls against
> >>>>>>>>>>>>> an injected interface.
> >>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> is as follows:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>>>>>>>>>>> placed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> on an annotation that
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> be placed on the
> >>>>>>>>>>>>> interface. Indicates what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> interceptor would be
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> invoked
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> for calls against this
> >>>>>>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It's then up to the
> >>>>>>>>>>>>> application
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> developer/framework author to define
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> annotations that go on
> >>>>>>>>>>>>> methods, as well as
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> interceptor itself
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> be invoked. The
> >>>>>>>>>>>>> feature for ServiceHandler
> >>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> to provide the
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> API of
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the type and then the
> >>>>>>>>>>>>> infrastructure
> >>>>>>>>>>>>>>>> required to
> >>>>>>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> the interceptor
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> called. Existing
> >>>>>>>>>>>>> documentation of the
> >>>>>>>>>>>>>>>> feature:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>
> >>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>>>>>>>>>> ser
> >>>>>>>>>>>>>>>> vicehandler.html
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> john
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Jason Porter
> >>>>>>>>>>>>>>> http://lightguard-jp.blogspot.com
> >>>>>>>>>>>>>>> http://twitter.com/lightguardjp
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Software Engineer
> >>>>>>>>>>>>>>> Open Source Advocate
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> PGP key id: 926CCFF5
> >>>>>>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jason Porter
> >> http://lightguard-jp.blogspot.com
> >> http://twitter.com/lightguardjp
> >>
> >> Software Engineer
> >> Open Source Advocate
> >>
> >> PGP key id: 926CCFF5
> >> PGP key available at: keyserver.net, pgp.mit.edu
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
On 21 Dec 2012, at 02:21, John D. Ament wrote:
> Hi all,
>
> So just to summarize the current proposal:
>
> - Create a new annotation @ServiceHandlerBinding (in core/api) which will
> be placed on on the interface that defines points of the
> - Create a new annotation @ServiceHandler (in core/api) (I think based on
> below this isn't needed since we have the interface now).
> - Create an extension that can generate object proxies that link calls to
> methods on the - org.apache.deltaspike.core.api....
>
> Define the binding type annotation:
>
> @ServiceHandlerBinding
> @Qualifier
> public @interface QueryHandler {
> }
I don't think we want @Qualifier here.
>
> which will define the relationship between the interface/abstract class
> that will use the service handler and the class that will serve as the
> invocation handler.
>
> For example, we can use @QueryHandler on an interface:
>
> @QueryHandler
> public interface PersonDAO {
> //...
> }
>
> When the container finds this interface it will identify the appropriate
> InvocationHandler, based on the following matches:
>
> - Implements InvocationHandler
Yes.
> - Is annotated @QueryHandler
Ish, this should follow standard CDI resolution rules, you can copy the way interceptor bindings work here.
> - Is annotated @ServiceHandler
Yes
>
> DeltaSpike will provide a proxied object where all abstract method calls
> are delegated to the InvocationHandler. The InvocationHandler will need to
> have logic to handle all methods as defined within the class, as long as
> that method is invoked through the InvocationHandler.
>
> @QueryHandler @ServiceHandler
> public QueryHandlerInvoker implements InvocationHandler {
>
> public Object invoke(Object proxy, Method method, Object[] args) {
> if(method.getName().startsWith("find..."){
> //...
> }
> return null;
>
> }
> }
>
> In addition, the ServiceHandlerBinding can be placed on an abstract class.
> In this case, only abstract methods will be passed to the
> InvocationHandler.
>
> @QueryHandler
> public abstract interface PersonDAO {
> public String doSomethingConcrete() {
> return "concrete";
> }
>
> public abstract Person find(int id);
> }
>
> Only the find method will be wrapped, the method doSomethingConcrete will
> be invoked directly. When interacting with an abstract class, the
> InvocationHandler can call methods on the proxied object.
>
> Finally, the app developer will be able to simply inject their
> interface/abstract class in to their beans to perform work:
>
> @Inject @QueryHandler PersonDAO dao;
>
> Questions:
>
> Should we provide a store (simple key/value map) to keep a history of found
> object types and how they map?
You mean like BeanManager.resolveInterceptors() ? I guess this is useful.
> Should we depend on certain libraries for proxying (e.g. javassist, I think
> both Weld & OWB use this still?)
If you want to just cover interfaces, it's easy, you can use proxying from the JDK. Otherwise yes you need to pick a lib.
Weld doesn't use javassist for proxying, but does for other stuff.
> Since we now use the interface InvocationHandler should we rename the
> binding to be InvocationHandlerBinding?
Yes, this makes sense
> I also think it's not necessary to
> have @ServiceHandler since the marker interface now exists.
+1
>
> Comments welcome..
>
> John
>
>
>
>
> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter <li...@gmail.com>wrote:
>
>> +1 for @ServiceHandler
>>
>>
>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <john.d.ament@gmail.com
>>> wrote:
>>
>>> If we're still calling the feature "ServiceHandler" then why not
>>> @ServiceHandler?
>>>
>>>
>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
>>> <rm...@gmail.com>wrote:
>>>
>>>> if we don't need it perfect, if we need it we'll just use another name
>>>> @DSHandler, @Handler...whatever it is ;)
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Pete Muir <pm...@redhat.com>:
>>>>> :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
>>>>>
>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote:
>>>>>
>>>>>> The problem I have is that now InvocationHandler is both an
>> interface
>>>> and
>>>>>> an @interface which will make it impossible for imports. I don't
>>> think
>>>>>> they should have the same name.
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com>
>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> So mostly ok from my perspective. One thing to note:
>>>>>>>>
>>>>>>>> @InvocationHandlerBinding
>>>>>>>> public @interface Repository {}
>>>>>>>>
>>>>>>>> @Repository
>>>>>>>> public interface MyRepository {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> @Repository @InvocationHandler
>>>>>>>> public class MyInvocationHandler implements InvocationHandler {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> Why do we have a @InvocationHandler here? Is it supposed to be
>>>>>>>> @InvocationHandlerBinding instead? If so, is it really needed
>> here?
>>>>>>>
>>>>>>> No, it should be @InvocationHandler, it's analagous to
>> @Interceptor.
>>>> It's
>>>>>>> not 100% necessary as we already implement the interface, which is
>>>> enough
>>>>>>> of the marker.
>>>>>>>
>>>>>>>>
>>>>>>>> Thinking about the implementation for this, I think this actually
>>>> becomes
>>>>>>>> easier to use and easier to understand over the Solder solution.
>>> The
>>>>>>>> implementation of the InvocationHandler becomes a true CDI bean.
>>>>>>>>
>>>>>>>> Should DS support Interceptors and Decorators on
>>>>>>>> InvocationHandler beans?
>>>>>>>>
>>>>>>>> Do you mean the implementation class or the interface?
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> i'd rather say no because the idea is to ease "util" extension
>>>>>>>>> writing. that's clearly not intended to be full business beans
>> IMO
>>>> (at
>>>>>>>>> least for a first step)
>>>>>>>>>
>>>>>>>>> That's why i'd leave it as this for now
>>>>>>>>>
>>>>>>>>> wdyt?
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>>>>>>>>> Mark refers to my call stack.
>>>>>>>>>>
>>>>>>>>>> Out of the box this call stack would exist just in OWB, because
>>> Weld
>>>>>>>>> would
>>>>>>>>>> not apply any Interceptors or Decorators...
>>>>>>>>>>
>>>>>>>>>> The question is: Should DS support Interceptors and Decorators
>> on
>>>>>>>>>> InvocationHandler beans? My answer would be: yes, if our
>>>> implementation
>>>>>>>>>> shall be a preview of CDI-110.
>>>>>>>>>> And that would make things complicated in the implementation...
>>>>>>>>>>
>>>>>>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
>>>>>>>>>> <rm...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> is it an issue for servicehandler? i don't think so
>>>>>>>>>>>
>>>>>>>>>>> it is often used to get util classes dynamically created, it is
>>>> rarely
>>>>>>>>>>> (i never saw it) decorated directly
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
>>>>>>>>>>>> we stumbled about this lately. It seems CDI only forces
>> support
>>>> for
>>>>>>>>>>>> interceptors and decorators for CDI-annotated classes, but not
>>> for
>>>>>>>>>>>> Bean<T> which get added via extensions nor even producer
>> methods
>>>> and
>>>>>>>>>>>> fields :/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Of course OWB does it, but it would be not portable...
>>>>>>>>>>>>
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
>>>>>>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>>>>>>>>> <de...@incubator.apache.org>
>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>>>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>>>>>>>>>> ServiceHandler
>>>>>>>>>>>>>
>>>>>>>>>>>>> T wo things about this: First: I don't like from the solder
>>>>>>> approach,
>>>>>>>>>>>>> because the interface is annotated instead of the
>>> implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Second, if we implement this we should conceptually make
>> clear
>>>> how
>>>>>>> it
>>>>>>>>>>>>> differentiates from Interceptors and Decorators. And
>>> personally I
>>>>>>>>> think
>>>>>>>>>>>>> this would work better with the InvocationHandler approach
>> than
>>>> with
>>>>>>>>> an
>>>>>>>>>>>>> approach that is very similar to interceptors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So +1 for an approach like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>>>>>>>>> public class MyInvocationHandler implements
>> InvocationHandler {
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technically we would register a custom Bean for every found
>>>>>>>>>>>>> InvocationHandler with that annotation and take over the
>>>>>>>>>>>>> interceptor-bindings from the interfaceŠ
>>>>>>>>>>>>> So the invocation stack would be clear, too:
>>>>>>>>>>>>> First Interceptors,
>>>>>>>>>>>>> Second Decorators,
>>>>>>>>>>>>> Third InvocationHandler
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wdyt?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Arne
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>>>>>>>>>>> <rm...@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this
>>>> solder
>>>>>>>>>>>>>> part portable ans it should be fine
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>>>>>>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>>>>>>>>> <jo...@gmail.com>wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding the two open questions:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be
>>>> used
>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It looks like the JSR's answer
>>>>>>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>>>>>>>>> is still unresolved - I'm not sure if we can get any
>> further
>>>>>>>>>>>>> answer at
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> time. The last posts on the subject seem to discuss using
>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>> along
>>>>>>>>>>>>>>>> the lines of an invocation handler, which I think would
>> work
>>>>>>> well.
>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>> we have some features coming up that are interested in
>>> having
>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>> handlers available, do we
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in
>>>> Solder?
>>>>>>>>>>>>>>>> 2. Push EG on a resolution
>>>>>>>>>>>>>>>> 3. Do it using invocation handlers.
>>>>>>>>>>>>>>>> 4. Do it some other way?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> as mentioned before we need the answers to the existing
>>>>>>>>>>>>> questions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I kind of let this one and the other drop off my radar,
>> I
>>>>>>>>>>>>>>>> apologize.
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
>>>>>>>>>>>>> requesting
>>>>>>>>>>>>>>>>> additional
>>>>>>>>>>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thx for the information. i thought there might be at
>>>>>>>>>>>>> least some
>>>>>>>>>>>>>>>>>> additional
>>>>>>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
>>>>>>>>>>>>> several
>>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
>>>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>>>>>>>>>>>> old, but I
>>>>>>>>>>>>>>>> haven´t had
>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>> to work on it after that.
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
>>>>>>>>>>>>> of your discussion
>>>>>>>>>>>>>>>> and/or
>>>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
>>>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
>>>>>>>>>>>>> "Service Handler" might
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
>>>>>>>>>>>>> as well.
>>>>>>>>>>>>>>>>>>>>>> Here is the latest pull request with
>>>>>>>>>>>>> some comments from Pete
>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> reviewed:
>>>>>>>>>>>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> George is working on it for CDI
>>>>>>>>>>>>> 1.1. George, can you share
>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>>>>>>>>> Petracek wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> independent of my opinion
>>>>>>>>>>>>> about the feature (which is
>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>> +0):
>>>>>>>>>>>>>>>>>>>>>>>> if it should be part of cdi
>>>>>>>>>>>>> 1.1, we have the following
>>>>>>>>>>>>>>>> options
>>>>>>>>>>>>>>>>>> imo:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 1) the approach (including
>>>>>>>>>>>>> the name/s) we agree on will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>>>>>>>>>>>> is the package)
>>>>>>>>>>>>>>>>>>>>>>>> 2) the eg has a different
>>>>>>>>>>>>> opinion about it ->
>>>>>>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>>>>>>>>>>>> this discussion
>>>>>>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
>>>>>>>>>>>>> version and just allow the same
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> cdi
>>>>>>>>>>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
>>>>>>>>>>>>> agree on the idea, it should be
>>>>>>>>>>>>>>>> re-visited
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
>>>>>>>>>>>>> it)
>>>>>>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
>>>>>>>>>>>>> of the result in cdi 1.1
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>>>>>>>>>>>> #4
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I'm not sure what you
>>>>>>>>>>>>> mean by a "super interceptor",
>>>>>>>>>>>>>>>> but if
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>>>>> in "super man"
>>>>>>>>>>>>> (something better than an interceptor),
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>>> disagree, it's
>>>>>>>>>>>>> actually a specialised form of
>>>>>>>>>>>>>>>> interceptor.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The best use case I know
>>>>>>>>>>>>> of is the one John mentions -
>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>> type
>>>>>>>>>>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>>>>>>> from User u")
>>>>>>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>>>>>>> getAllUsers();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>>>>>>> from User u order by u.name")
>>>>>>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>>>>>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Now, it may be the case
>>>>>>>>>>>>> that there aren't any other use
>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>>>>>>> handlers, in which case
>>>>>>>>>>>>> we should perhaps just offer
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>>>>>>>>> service handler -
>>>>>>>>>>>>> references to type safe queries - as I
>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note, that at the moment
>>>>>>>>>>>>> service handlers are scheduled
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> CDI
>>>>>>>>>>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>>>>>>>>>>>> Jason Porter wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Somewhat. I
>>>>>>>>>>>>> wouldn't really think of them as overrides,
>>>>>>>>>>>>>>>> they,
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>>>>>>>>> seem more like items to
>>>>>>>>>>>>> do in addition to whatever the
>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>> impl
>>>>>>>>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
>>>>>>>>>>>>> seem more like super
>>>>>>>>>>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>>>>>>>>>>>> 19:23, "John D. Ament" <
>>>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>>>>>>> concepts are very dissimilar.
>>>>>>>>>>>>>>>> servicehandlers
>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>> delegates are more like overrides and
>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>>>>> the method
>>>>>>>>>>>>> signature.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>>>>>>>>>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>>>>>>> idea of ServiceHandlers are good, but,
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>> delegates?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent from my
>>>>>>>>>>>>> iPhone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
>>>>>>>>>>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>> don't think it's a hard requirement for it to be
>>>>>>>>>>>>>>>> on an
>>>>>>>>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One of
>>>>>>>>>>>>> the best use-cases we built at my job is
>>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
>>>>>>>>>>>>> The JDBC bindings do work, but not pretty.
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a fairly
>>>>>>>>>>>>> clean wrapper API, generic enough for
>>>>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>>>>> in/out
>>>>>>>>>>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
>>>>>>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> actually I don't really see a real benefit. I just
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>>>>> grok
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why
>>>>>>>>>>>>> would one intercept an Interface and delegate
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> calls
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>> could be neat for mocking, but there are
>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Gerhard Petracek
>>>>>>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>>>>>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> if you have a lot of shared code, you can extract
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> 1-n
>>>>>>>>>>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> abstract class which is still easier than a new
>>>>>>>>>>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> at least i haven't seen an use-case which really
>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> adding
>>>>>>>>>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>>>>>>>>>>> boilerplate
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>>>>>>>>> implement
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> bean
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>>>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>>>>>>>>>>> instead?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>>>>>>>>> Petracek
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> no -1 because there are
>>>>>>>>>>>>> use-cases for it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>>>>>>>>>>> cdi mechanisms
>>>>>>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>>>>>>>>> fine.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>>>>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>>>>>>>>>>> the subject of
>>>>>>>>>>>>>>>>> ServiceHandler.
>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> added 113 as a
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>>>>>>>>>>> appropriate but not
>>>>>>>>>>>>>>>> 100%
>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> (so please let
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> know if you think
>>>>>>>>>>>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
>>>>>>>>>>>>> allows you to define
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> interceptor that
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> generic calls against
>>>>>>>>>>>>> an injected interface.
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> is as follows:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>>>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> on an annotation that
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> be placed on the
>>>>>>>>>>>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> interceptor would be
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> for calls against this
>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It's then up to the
>>>>>>>>>>>>> application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> annotations that go on
>>>>>>>>>>>>> methods, as well as
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> interceptor itself
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> be invoked. The
>>>>>>>>>>>>> feature for ServiceHandler
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> to provide the
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> the type and then the
>>>>>>>>>>>>> infrastructure
>>>>>>>>>>>>>>>> required to
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> the interceptor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> called. Existing
>>>>>>>>>>>>> documentation of the
>>>>>>>>>>>>>>>> feature:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>>>>>>>>> ser
>>>>>>>>>>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Jason Porter
>>>>>>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>>>>>> http://twitter.com/lightguardjp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>>>> Open Source Advocate
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Hi all,
So just to summarize the current proposal:
- Create a new annotation @ServiceHandlerBinding (in core/api) which will
be placed on on the interface that defines points of the
- Create a new annotation @ServiceHandler (in core/api) (I think based on
below this isn't needed since we have the interface now).
- Create an extension that can generate object proxies that link calls to
methods on the - org.apache.deltaspike.core.api....
Define the binding type annotation:
@ServiceHandlerBinding
@Qualifier
public @interface QueryHandler {
}
which will define the relationship between the interface/abstract class
that will use the service handler and the class that will serve as the
invocation handler.
For example, we can use @QueryHandler on an interface:
@QueryHandler
public interface PersonDAO {
//...
}
When the container finds this interface it will identify the appropriate
InvocationHandler, based on the following matches:
- Implements InvocationHandler
- Is annotated @QueryHandler
- Is annotated @ServiceHandler
DeltaSpike will provide a proxied object where all abstract method calls
are delegated to the InvocationHandler. The InvocationHandler will need to
have logic to handle all methods as defined within the class, as long as
that method is invoked through the InvocationHandler.
@QueryHandler @ServiceHandler
public QueryHandlerInvoker implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) {
if(method.getName().startsWith("find..."){
//...
}
return null;
}
}
In addition, the ServiceHandlerBinding can be placed on an abstract class.
In this case, only abstract methods will be passed to the
InvocationHandler.
@QueryHandler
public abstract interface PersonDAO {
public String doSomethingConcrete() {
return "concrete";
}
public abstract Person find(int id);
}
Only the find method will be wrapped, the method doSomethingConcrete will
be invoked directly. When interacting with an abstract class, the
InvocationHandler can call methods on the proxied object.
Finally, the app developer will be able to simply inject their
interface/abstract class in to their beans to perform work:
@Inject @QueryHandler PersonDAO dao;
Questions:
Should we provide a store (simple key/value map) to keep a history of found
object types and how they map?
Should we depend on certain libraries for proxying (e.g. javassist, I think
both Weld & OWB use this still?)
Since we now use the interface InvocationHandler should we rename the
binding to be InvocationHandlerBinding? I also think it's not necessary to
have @ServiceHandler since the marker interface now exists.
Comments welcome..
John
On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter <li...@gmail.com>wrote:
> +1 for @ServiceHandler
>
>
> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <john.d.ament@gmail.com
> >wrote:
>
> > If we're still calling the feature "ServiceHandler" then why not
> > @ServiceHandler?
> >
> >
> > On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> > > if we don't need it perfect, if we need it we'll just use another name
> > > @DSHandler, @Handler...whatever it is ;)
> > >
> > > Romain Manni-Bucau
> > > Twitter: @rmannibucau
> > > Blog: http://rmannibucau.wordpress.com/
> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > Github: https://github.com/rmannibucau
> > >
> > >
> > >
> > > 2012/12/20 Pete Muir <pm...@redhat.com>:
> > > > :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
> > > >
> > > > On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > > >
> > > >> The problem I have is that now InvocationHandler is both an
> interface
> > > and
> > > >> an @interface which will make it impossible for imports. I don't
> > think
> > > >> they should have the same name.
> > > >>
> > > >>
> > > >> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com>
> wrote:
> > > >>
> > > >>>
> > > >>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> > > >>>
> > > >>>> All,
> > > >>>>
> > > >>>> So mostly ok from my perspective. One thing to note:
> > > >>>>
> > > >>>> @InvocationHandlerBinding
> > > >>>> public @interface Repository {}
> > > >>>>
> > > >>>> @Repository
> > > >>>> public interface MyRepository {
> > > >>>> ...
> > > >>>> }
> > > >>>>
> > > >>>> @Repository @InvocationHandler
> > > >>>> public class MyInvocationHandler implements InvocationHandler {
> > > >>>> ...
> > > >>>> }
> > > >>>>
> > > >>>> Why do we have a @InvocationHandler here? Is it supposed to be
> > > >>>> @InvocationHandlerBinding instead? If so, is it really needed
> here?
> > > >>>
> > > >>> No, it should be @InvocationHandler, it's analagous to
> @Interceptor.
> > > It's
> > > >>> not 100% necessary as we already implement the interface, which is
> > > enough
> > > >>> of the marker.
> > > >>>
> > > >>>>
> > > >>>> Thinking about the implementation for this, I think this actually
> > > becomes
> > > >>>> easier to use and easier to understand over the Solder solution.
> > The
> > > >>>> implementation of the InvocationHandler becomes a true CDI bean.
> > > >>>>
> > > >>>> Should DS support Interceptors and Decorators on
> > > >>>> InvocationHandler beans?
> > > >>>>
> > > >>>> Do you mean the implementation class or the interface?
> > > >>>>
> > > >>>> John
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> > > >>>> <rm...@gmail.com>wrote:
> > > >>>>
> > > >>>>> i'd rather say no because the idea is to ease "util" extension
> > > >>>>> writing. that's clearly not intended to be full business beans
> IMO
> > > (at
> > > >>>>> least for a first step)
> > > >>>>>
> > > >>>>> That's why i'd leave it as this for now
> > > >>>>>
> > > >>>>> wdyt?
> > > >>>>>
> > > >>>>> Romain Manni-Bucau
> > > >>>>> Twitter: @rmannibucau
> > > >>>>> Blog: http://rmannibucau.wordpress.com/
> > > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >>>>> Github: https://github.com/rmannibucau
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> > > >>>>>> Mark refers to my call stack.
> > > >>>>>>
> > > >>>>>> Out of the box this call stack would exist just in OWB, because
> > Weld
> > > >>>>> would
> > > >>>>>> not apply any Interceptors or Decorators...
> > > >>>>>>
> > > >>>>>> The question is: Should DS support Interceptors and Decorators
> on
> > > >>>>>> InvocationHandler beans? My answer would be: yes, if our
> > > implementation
> > > >>>>>> shall be a preview of CDI-110.
> > > >>>>>> And that would make things complicated in the implementation...
> > > >>>>>>
> > > >>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> > > >>>>>> <rm...@gmail.com>:
> > > >>>>>>
> > > >>>>>>> is it an issue for servicehandler? i don't think so
> > > >>>>>>>
> > > >>>>>>> it is often used to get util classes dynamically created, it is
> > > rarely
> > > >>>>>>> (i never saw it) decorated directly
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> Romain Manni-Bucau
> > > >>>>>>> Twitter: @rmannibucau
> > > >>>>>>> Blog: http://rmannibucau.wordpress.com/
> > > >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>> Github: https://github.com/rmannibucau
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
> > > >>>>>>>> we stumbled about this lately. It seems CDI only forces
> support
> > > for
> > > >>>>>>>> interceptors and decorators for CDI-annotated classes, but not
> > for
> > > >>>>>>>> Bean<T> which get added via extensions nor even producer
> methods
> > > and
> > > >>>>>>>> fields :/
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Of course OWB does it, but it would be not portable...
> > > >>>>>>>>
> > > >>>>>>>> LieGrue,
> > > >>>>>>>> strub
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> ----- Original Message -----
> > > >>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
> > > >>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
> > > >>>>>>>>> <de...@incubator.apache.org>
> > > >>>>>>>>> Cc:
> > > >>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
> > > >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > > >>>>>>>>> ServiceHandler
> > > >>>>>>>>>
> > > >>>>>>>>> T wo things about this: First: I don't like from the solder
> > > >>> approach,
> > > >>>>>>>>> because the interface is annotated instead of the
> > implementation.
> > > >>>>>>>>>
> > > >>>>>>>>> Second, if we implement this we should conceptually make
> clear
> > > how
> > > >>> it
> > > >>>>>>>>> differentiates from Interceptors and Decorators. And
> > personally I
> > > >>>>> think
> > > >>>>>>>>> this would work better with the InvocationHandler approach
> than
> > > with
> > > >>>>> an
> > > >>>>>>>>> approach that is very similar to interceptors.
> > > >>>>>>>>>
> > > >>>>>>>>> So +1 for an approach like this:
> > > >>>>>>>>>
> > > >>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
> > > >>>>>>>>> public class MyInvocationHandler implements
> InvocationHandler {
> > > >>>>>>>>> ...
> > > >>>>>>>>> }
> > > >>>>>>>>>
> > > >>>>>>>>> Technically we would register a custom Bean for every found
> > > >>>>>>>>> InvocationHandler with that annotation and take over the
> > > >>>>>>>>> interceptor-bindings from the interfaceŠ
> > > >>>>>>>>> So the invocation stack would be clear, too:
> > > >>>>>>>>> First Interceptors,
> > > >>>>>>>>> Second Decorators,
> > > >>>>>>>>> Third InvocationHandler
> > > >>>>>>>>>
> > > >>>>>>>>> Wdyt?
> > > >>>>>>>>>
> > > >>>>>>>>> Arne
> > > >>>>>>>>>
> > > >>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> > > >>>>>>>>> <rm...@gmail.com>:
> > > >>>>>>>>>
> > > >>>>>>>>>> +1
> > > >>>>>>>>>>
> > > >>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this
> > > solder
> > > >>>>>>>>>> part portable ans it should be fine
> > > >>>>>>>>>>
> > > >>>>>>>>>> Romain Manni-Bucau
> > > >>>>>>>>>> Twitter: @rmannibucau
> > > >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> > > >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >>>>>>>>>> Github: https://github.com/rmannibucau
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> > > >>>>>>>>>>> At this point, I'd say just do it as is in solder.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> > > >>>>>>>>>>> <jo...@gmail.com>wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Hi All,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Regarding the two open questions:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be
> > > used
> > > >>>>>>>>> also
> > > >>>>>>>>>>>> for
> > > >>>>>>>>>>>> cdi 1.1 (the only difference is the package)
> > > >>>>>>>>>>>> 2) the eg has a different opinion about it ->
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> It looks like the JSR's answer
> > > >>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> > > >>>>>>>>>>>> is still unresolved - I'm not sure if we can get any
> further
> > > >>>>>>>>> answer at
> > > >>>>>>>>>>>> this
> > > >>>>>>>>>>>> time. The last posts on the subject seem to discuss using
> > > >>>>>>>>> something
> > > >>>>>>>>>>>> along
> > > >>>>>>>>>>>> the lines of an invocation handler, which I think would
> work
> > > >>> well.
> > > >>>>>>>>>>>> Since
> > > >>>>>>>>>>>> we have some features coming up that are interested in
> > having
> > > >>>>>>>>> service
> > > >>>>>>>>>>>> handlers available, do we
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in
> > > Solder?
> > > >>>>>>>>>>>> 2. Push EG on a resolution
> > > >>>>>>>>>>>> 3. Do it using invocation handlers.
> > > >>>>>>>>>>>> 4. Do it some other way?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> John
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> > > >>>>>>>>>>>> gerhard.petracek@gmail.com
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> hi john,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> as mentioned before we need the answers to the existing
> > > >>>>>>>>> questions.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> All,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I kind of let this one and the other drop off my radar,
> I
> > > >>>>>>>>>>>> apologize.
> > > >>>>>>>>>>>> it
> > > >>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
> > > >>>>>>>>> requesting
> > > >>>>>>>>>>>>> additional
> > > >>>>>>>>>>>>>> comments from everyone. Any other feedback?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> John
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > > >>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> hi george,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> thx for the information. i thought there might be at
> > > >>>>>>>>> least some
> > > >>>>>>>>>>>>>> additional
> > > >>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
> > > >>>>>>>>> several
> > > >>>>>>>>>>>> comments.
> > > >>>>>>>>>>>>>>> -> imo we should continue with them.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
> > > >>>>>>>>> <ge...@gmail.com>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Hello Gerhard,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
> > > >>>>>>>>> old, but I
> > > >>>>>>>>>>>> haven´t had
> > > >>>>>>>>>>>>>> time
> > > >>>>>>>>>>>>>>>> to work on it after that.
> > > >>>>>>>>>>>>>>>> Regards,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> George
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
> > > >>>>>>>>> <ge...@gmail.com>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> hi george,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> thx for the link.
> > > >>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
> > > >>>>>>>>> of your discussion
> > > >>>>>>>>>>>> and/or
> > > >>>>>>>>>>>>> draft
> > > >>>>>>>>>>>>>>>>> (at least it's quite old already).
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
> > > >>>>>>>>> <ge...@gmail.com>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Hi !
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
> > > >>>>>>>>> "Service Handler" might
> > > >>>>>>>>>>>> not
> > > >>>>>>>>>>>> be
> > > >>>>>>>>>>>>>> so
> > > >>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
> > > >>>>>>>>> as well.
> > > >>>>>>>>>>>>>>>>>> Here is the latest pull request with
> > > >>>>>>>>> some comments from Pete
> > > >>>>>>>>>>>> yet
> > > >>>>>>>>>>>> to
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>> reviewed:
> > > >>>>>>>>> https://github.com/jboss/cdi/pull/28
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> > > >>>>>>>>> <pm...@redhat.com>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Agreed :-)
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> George is working on it for CDI
> > > >>>>>>>>> 1.1. George, can you share
> > > >>>>>>>>>>>> your
> > > >>>>>>>>>>>>>>>>>> proposal
> > > >>>>>>>>>>>>>>>>>>> so far?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
> > > >>>>>>>>> Petracek wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> hi pete,
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> independent of my opinion
> > > >>>>>>>>> about the feature (which is
> > > >>>>>>>>>>>> still
> > > >>>>>>>>>>>>> +0):
> > > >>>>>>>>>>>>>>>>>>>> if it should be part of cdi
> > > >>>>>>>>> 1.1, we have the following
> > > >>>>>>>>>>>> options
> > > >>>>>>>>>>>>>> imo:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 1) the approach (including
> > > >>>>>>>>> the name/s) we agree on will
> > > >>>>>>>>>>>> be
> > > >>>>>>>>>>>> used
> > > >>>>>>>>>>>>>>> also
> > > >>>>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
> > > >>>>>>>>> is the package)
> > > >>>>>>>>>>>>>>>>>>>> 2) the eg has a different
> > > >>>>>>>>> opinion about it ->
> > > >>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
> > > >>>>>>>>> this discussion
> > > >>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
> > > >>>>>>>>> version and just allow the same
> > > >>>>>>>>>>>> with
> > > >>>>>>>>>>>>>> cdi
> > > >>>>>>>>>>>>>>>>>> 1.0
> > > >>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
> > > >>>>>>>>> agree on the idea, it should be
> > > >>>>>>>>>>>> re-visited
> > > >>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
> > > >>>>>>>>> it)
> > > >>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
> > > >>>>>>>>> of the result in cdi 1.1
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
> > > >>>>>>>>> #4
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> > > >>>>>>>>> <pm...@redhat.com>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> I'm not sure what you
> > > >>>>>>>>> mean by a "super interceptor",
> > > >>>>>>>>>>>> but if
> > > >>>>>>>>>>>>> you
> > > >>>>>>>>>>>>>>>>>> mean it
> > > >>>>>>>>>>>>>>>>>>> as
> > > >>>>>>>>>>>>>>>>>>>>> in "super man"
> > > >>>>>>>>> (something better than an interceptor),
> > > >>>>>>>>>>>> then
> > > >>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>>>>>>>> disagree, it's
> > > >>>>>>>>> actually a specialised form of
> > > >>>>>>>>>>>> interceptor.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> The best use case I know
> > > >>>>>>>>> of is the one John mentions -
> > > >>>>>>>>>>>>> creating
> > > >>>>>>>>>>>>>>> type
> > > >>>>>>>>>>>>>>>>>>> safe
> > > >>>>>>>>>>>>>>>>>>>>> references to queries:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> @QueryService
> > > >>>>>>>>>>>>>>>>>>>>> interface UserQuery {
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> @Query("select u
> > > >>>>>>>>> from User u")
> > > >>>>>>>>>>>>>>>>>>>>> public List<User>
> > > >>>>>>>>> getAllUsers();
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> @Query("select u
> > > >>>>>>>>> from User u order by u.name")
> > > >>>>>>>>>>>>>>>>>>>>> public List<User>
> > > >>>>>>>>> getAllUsersSortedByName();
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Now, it may be the case
> > > >>>>>>>>> that there aren't any other use
> > > >>>>>>>>>>>> cases
> > > >>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>> service
> > > >>>>>>>>>>>>>>>>>>>>> handlers, in which case
> > > >>>>>>>>> we should perhaps just offer
> > > >>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>> particular
> > > >>>>>>>>>>>>>>>>>>>>> service handler -
> > > >>>>>>>>> references to type safe queries - as I
> > > >>>>>>>>>>>> think
> > > >>>>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>> an
> > > >>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Note, that at the moment
> > > >>>>>>>>> service handlers are scheduled
> > > >>>>>>>>>>>> for
> > > >>>>>>>>>>>>> CDI
> > > >>>>>>>>>>>>>>> 1.1.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
> > > >>>>>>>>> Jason Porter wrote:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Somewhat. I
> > > >>>>>>>>> wouldn't really think of them as overrides,
> > > >>>>>>>>>>>> they,
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> me,
> > > >>>>>>>>>>>>>>>>>>>>> seem more like items to
> > > >>>>>>>>> do in addition to whatever the
> > > >>>>>>>>>>>>> original
> > > >>>>>>>>>>>>>>> impl
> > > >>>>>>>>>>>>>>>>>>> does.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
> > > >>>>>>>>> seem more like super
> > > >>>>>>>>>>>> interceptors.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
> > > >>>>>>>>> 19:23, "John D. Ament" <
> > > >>>>>>>>>>>>>>> john.d.ament@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> @jason
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I think the
> > > >>>>>>>>> concepts are very dissimilar.
> > > >>>>>>>>>>>> servicehandlers
> > > >>>>>>>>>>>>>>> create
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>> implementation.
> > > >>>>>>>>> delegates are more like overrides and
> > > >>>>>>>>>>>> need
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> know
> > > >>>>>>>>>>>>>>>>>>>>> about
> > > >>>>>>>>>>>>>>>>>>>>>>> the method
> > > >>>>>>>>> signature.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
> > > >>>>>>>>> 2012 at 9:17 PM, Jason Porter <
> > > >>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I think the
> > > >>>>>>>>> idea of ServiceHandlers are good, but,
> > > >>>>>>>>>>>> could
> > > >>>>>>>>>>>> we
> > > >>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>> do
> > > >>>>>>>>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>>>>>>>>>> with
> > > >>>>>>>>> delegates?
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Sent from my
> > > >>>>>>>>> iPhone
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
> > > >>>>>>>>> 2012, at 19:05, "John D. Ament" <
> > > >>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> @mark
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>> don't think it's a hard requirement for it to be
> > > >>>>>>>>>>>> on an
> > > >>>>>>>>>>>>>>>>>> interface.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> One of
> > > >>>>>>>>> the best use-cases we built at my job is
> > > >>>>>>>>>>>> using it
> > > >>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>> calling
> > > >>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
> > > >>>>>>>>> The JDBC bindings do work, but not pretty.
> > > >>>>>>>>>>>> we
> > > >>>>>>>>>>>>> were
> > > >>>>>>>>>>>>>>>>>> able to
> > > >>>>>>>>>>>>>>>>>>>>>>>> create
> > > >>>>>>>>>>>>>>>>>>>>>>>>> a fairly
> > > >>>>>>>>> clean wrapper API, generic enough for
> > > >>>>>>>>>>>> binding
> > > >>>>>>>>>>>>>> in/out
> > > >>>>>>>>>>>>>>>>>>>>> parameters.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> JOhn
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
> > > >>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> > > >>>>>>>>>>>>>>>>>> struberg@yahoo.de>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> actually I don't really see a real benefit. I just
> > > >>>>>>>>>>>> don't
> > > >>>>>>>>>>>>>> yet
> > > >>>>>>>>>>>>>>>>>> grok
> > > >>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>> use
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> case
> > > >>>>>>>>> for real world projects.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Why
> > > >>>>>>>>> would one intercept an Interface and delegate
> > > >>>>>>>>>>>> the
> > > >>>>>>>>>>>>> calls
> > > >>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>> method
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> handler?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> This
> > > >>>>>>>>> could be neat for mocking, but there are
> > > >>>>>>>>>>>> better
> > > >>>>>>>>>>>>>>>>>> frameworks for
> > > >>>>>>>>>>>>>>>>>>>>>>>> that.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> thus
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> LieGrue,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> strub
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> -----
> > > >>>>>>>>> Original Message -----
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> From: Gerhard Petracek
> > > >>>>>>>>>>>> <ge...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> To: deltaspike-dev@incubator.apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> Cc:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> > > >>>>>>>>>>>>> Discuss
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> ServiceHandler
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> if you have a lot of shared code, you can extract
> > > >>>>>>>>>>>> it
> > > >>>>>>>>>>>> in
> > > >>>>>>>>>>>>>> 1-n
> > > >>>>>>>>>>>>>>>>>>>>> method/s or
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> abstract class which is still easier than a new
> > > >>>>>>>>>>>> concept.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> at least i haven't seen an use-case which really
> > > >>>>>>>>>>>> needed
> > > >>>>>>>>>>>>>> it.
> > > >>>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>> was
> > > >>>>>>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> reason for a +0 (which still means that i'm ok
> > > >>>>>>>>>>>> with
> > > >>>>>>>>>>>>> adding
> > > >>>>>>>>>>>>>>>>>> it).
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
> > > >>>>>>>>>>>> boilerplate
> > > >>>>>>>>>>>>>>> code
> > > >>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>> it?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> hi pete,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> instead of the interface you can just
> > > >>>>>>>>> implement
> > > >>>>>>>>>>>> a
> > > >>>>>>>>>>>> bean
> > > >>>>>>>>>>>>>>> which
> > > >>>>>>>>>>>>>>>>>>> does
> > > >>>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> same.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> > > >>>>>>>>> <pm...@redhat.com>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
> > > >>>>>>>>> instead?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> > > >>>>>>>>> Petracek
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> +0
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> no -1 because there are
> > > >>>>>>>>> use-cases for it.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
> > > >>>>>>>>> cdi mechanisms
> > > >>>>>>>>>>>>> instead.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> > > >>>>>>>>>>>>> gerhard.petracek@gmail.com
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> hi john,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> > > >>>>>>>>> fine.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> > > >>>>>>>>>>>> <jo...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Hi All
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
> > > >>>>>>>>> the subject of
> > > >>>>>>>>>>>>> ServiceHandler.
> > > >>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> added 113 as a
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> child
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> > > >>>>>>>>> appropriate but not
> > > >>>>>>>>>>>> 100%
> > > >>>>>>>>>>>>>> sure
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> (so please let
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> me
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> know if you think
> > > >>>>>>>>> it's not appropriate as a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> child). ServiceHandler
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
> > > >>>>>>>>> allows you to define
> > > >>>>>>>>>>>> an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> interceptor that
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> manages
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> generic calls against
> > > >>>>>>>>> an injected interface.
> > > >>>>>>>>>>>> The
> > > >>>>>>>>>>>>>> API
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> is as follows:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> -
> > > >>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
> > > >>>>>>>>>>>> placed
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> on an annotation that
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> be placed on the
> > > >>>>>>>>> interface. Indicates what
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> interceptor would be
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> invoked
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> for calls against this
> > > >>>>>>>>> interface.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> It's then up to the
> > > >>>>>>>>> application
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> developer/framework author to define
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> annotations that go on
> > > >>>>>>>>> methods, as well as
> > > >>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> interceptor itself
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> will
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> be invoked. The
> > > >>>>>>>>> feature for ServiceHandler
> > > >>>>>>>>>>>> would
> > > >>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> to provide the
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> API of
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> the type and then the
> > > >>>>>>>>> infrastructure
> > > >>>>>>>>>>>> required to
> > > >>>>>>>>>>>>>> make
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> the interceptor
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> called. Existing
> > > >>>>>>>>> documentation of the
> > > >>>>>>>>>>>> feature:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>
> > > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> > > >>>>>>>>>>>> ser
> > > >>>>>>>>>>>> vicehandler.html
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Regards,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> john
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --
> > > >>>>>>>>>>> Jason Porter
> > > >>>>>>>>>>> http://lightguard-jp.blogspot.com
> > > >>>>>>>>>>> http://twitter.com/lightguardjp
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Software Engineer
> > > >>>>>>>>>>> Open Source Advocate
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> PGP key id: 926CCFF5
> > > >>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> > > >>>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >
> > >
> >
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Jason Porter <li...@gmail.com>.
+1 for @ServiceHandler
On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <jo...@gmail.com>wrote:
> If we're still calling the feature "ServiceHandler" then why not
> @ServiceHandler?
>
>
> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > if we don't need it perfect, if we need it we'll just use another name
> > @DSHandler, @Handler...whatever it is ;)
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2012/12/20 Pete Muir <pm...@redhat.com>:
> > > :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
> > >
> > > On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > >
> > >> The problem I have is that now InvocationHandler is both an interface
> > and
> > >> an @interface which will make it impossible for imports. I don't
> think
> > >> they should have the same name.
> > >>
> > >>
> > >> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com> wrote:
> > >>
> > >>>
> > >>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> > >>>
> > >>>> All,
> > >>>>
> > >>>> So mostly ok from my perspective. One thing to note:
> > >>>>
> > >>>> @InvocationHandlerBinding
> > >>>> public @interface Repository {}
> > >>>>
> > >>>> @Repository
> > >>>> public interface MyRepository {
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>> @Repository @InvocationHandler
> > >>>> public class MyInvocationHandler implements InvocationHandler {
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>> Why do we have a @InvocationHandler here? Is it supposed to be
> > >>>> @InvocationHandlerBinding instead? If so, is it really needed here?
> > >>>
> > >>> No, it should be @InvocationHandler, it's analagous to @Interceptor.
> > It's
> > >>> not 100% necessary as we already implement the interface, which is
> > enough
> > >>> of the marker.
> > >>>
> > >>>>
> > >>>> Thinking about the implementation for this, I think this actually
> > becomes
> > >>>> easier to use and easier to understand over the Solder solution.
> The
> > >>>> implementation of the InvocationHandler becomes a true CDI bean.
> > >>>>
> > >>>> Should DS support Interceptors and Decorators on
> > >>>> InvocationHandler beans?
> > >>>>
> > >>>> Do you mean the implementation class or the interface?
> > >>>>
> > >>>> John
> > >>>>
> > >>>>
> > >>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> > >>>> <rm...@gmail.com>wrote:
> > >>>>
> > >>>>> i'd rather say no because the idea is to ease "util" extension
> > >>>>> writing. that's clearly not intended to be full business beans IMO
> > (at
> > >>>>> least for a first step)
> > >>>>>
> > >>>>> That's why i'd leave it as this for now
> > >>>>>
> > >>>>> wdyt?
> > >>>>>
> > >>>>> Romain Manni-Bucau
> > >>>>> Twitter: @rmannibucau
> > >>>>> Blog: http://rmannibucau.wordpress.com/
> > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>>> Github: https://github.com/rmannibucau
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> > >>>>>> Mark refers to my call stack.
> > >>>>>>
> > >>>>>> Out of the box this call stack would exist just in OWB, because
> Weld
> > >>>>> would
> > >>>>>> not apply any Interceptors or Decorators...
> > >>>>>>
> > >>>>>> The question is: Should DS support Interceptors and Decorators on
> > >>>>>> InvocationHandler beans? My answer would be: yes, if our
> > implementation
> > >>>>>> shall be a preview of CDI-110.
> > >>>>>> And that would make things complicated in the implementation...
> > >>>>>>
> > >>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> > >>>>>> <rm...@gmail.com>:
> > >>>>>>
> > >>>>>>> is it an issue for servicehandler? i don't think so
> > >>>>>>>
> > >>>>>>> it is often used to get util classes dynamically created, it is
> > rarely
> > >>>>>>> (i never saw it) decorated directly
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Romain Manni-Bucau
> > >>>>>>> Twitter: @rmannibucau
> > >>>>>>> Blog: http://rmannibucau.wordpress.com/
> > >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>>>>> Github: https://github.com/rmannibucau
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
> > >>>>>>>> we stumbled about this lately. It seems CDI only forces support
> > for
> > >>>>>>>> interceptors and decorators for CDI-annotated classes, but not
> for
> > >>>>>>>> Bean<T> which get added via extensions nor even producer methods
> > and
> > >>>>>>>> fields :/
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Of course OWB does it, but it would be not portable...
> > >>>>>>>>
> > >>>>>>>> LieGrue,
> > >>>>>>>> strub
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
> > >>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
> > >>>>>>>>> <de...@incubator.apache.org>
> > >>>>>>>>> Cc:
> > >>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
> > >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > >>>>>>>>> ServiceHandler
> > >>>>>>>>>
> > >>>>>>>>> T wo things about this: First: I don't like from the solder
> > >>> approach,
> > >>>>>>>>> because the interface is annotated instead of the
> implementation.
> > >>>>>>>>>
> > >>>>>>>>> Second, if we implement this we should conceptually make clear
> > how
> > >>> it
> > >>>>>>>>> differentiates from Interceptors and Decorators. And
> personally I
> > >>>>> think
> > >>>>>>>>> this would work better with the InvocationHandler approach than
> > with
> > >>>>> an
> > >>>>>>>>> approach that is very similar to interceptors.
> > >>>>>>>>>
> > >>>>>>>>> So +1 for an approach like this:
> > >>>>>>>>>
> > >>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
> > >>>>>>>>> public class MyInvocationHandler implements InvocationHandler {
> > >>>>>>>>> ...
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>>> Technically we would register a custom Bean for every found
> > >>>>>>>>> InvocationHandler with that annotation and take over the
> > >>>>>>>>> interceptor-bindings from the interfaceŠ
> > >>>>>>>>> So the invocation stack would be clear, too:
> > >>>>>>>>> First Interceptors,
> > >>>>>>>>> Second Decorators,
> > >>>>>>>>> Third InvocationHandler
> > >>>>>>>>>
> > >>>>>>>>> Wdyt?
> > >>>>>>>>>
> > >>>>>>>>> Arne
> > >>>>>>>>>
> > >>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> > >>>>>>>>> <rm...@gmail.com>:
> > >>>>>>>>>
> > >>>>>>>>>> +1
> > >>>>>>>>>>
> > >>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this
> > solder
> > >>>>>>>>>> part portable ans it should be fine
> > >>>>>>>>>>
> > >>>>>>>>>> Romain Manni-Bucau
> > >>>>>>>>>> Twitter: @rmannibucau
> > >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> > >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>>>>>>>> Github: https://github.com/rmannibucau
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> > >>>>>>>>>>> At this point, I'd say just do it as is in solder.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> > >>>>>>>>>>> <jo...@gmail.com>wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi All,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Regarding the two open questions:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be
> > used
> > >>>>>>>>> also
> > >>>>>>>>>>>> for
> > >>>>>>>>>>>> cdi 1.1 (the only difference is the package)
> > >>>>>>>>>>>> 2) the eg has a different opinion about it ->
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> It looks like the JSR's answer
> > >>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> > >>>>>>>>>>>> is still unresolved - I'm not sure if we can get any further
> > >>>>>>>>> answer at
> > >>>>>>>>>>>> this
> > >>>>>>>>>>>> time. The last posts on the subject seem to discuss using
> > >>>>>>>>> something
> > >>>>>>>>>>>> along
> > >>>>>>>>>>>> the lines of an invocation handler, which I think would work
> > >>> well.
> > >>>>>>>>>>>> Since
> > >>>>>>>>>>>> we have some features coming up that are interested in
> having
> > >>>>>>>>> service
> > >>>>>>>>>>>> handlers available, do we
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in
> > Solder?
> > >>>>>>>>>>>> 2. Push EG on a resolution
> > >>>>>>>>>>>> 3. Do it using invocation handlers.
> > >>>>>>>>>>>> 4. Do it some other way?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> John
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> > >>>>>>>>>>>> gerhard.petracek@gmail.com
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> hi john,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> as mentioned before we need the answers to the existing
> > >>>>>>>>> questions.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> All,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
> > >>>>>>>>>>>> apologize.
> > >>>>>>>>>>>> it
> > >>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
> > >>>>>>>>> requesting
> > >>>>>>>>>>>>> additional
> > >>>>>>>>>>>>>> comments from everyone. Any other feedback?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> John
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > >>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> hi george,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> thx for the information. i thought there might be at
> > >>>>>>>>> least some
> > >>>>>>>>>>>>>> additional
> > >>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
> > >>>>>>>>> several
> > >>>>>>>>>>>> comments.
> > >>>>>>>>>>>>>>> -> imo we should continue with them.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
> > >>>>>>>>> <ge...@gmail.com>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Hello Gerhard,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
> > >>>>>>>>> old, but I
> > >>>>>>>>>>>> haven´t had
> > >>>>>>>>>>>>>> time
> > >>>>>>>>>>>>>>>> to work on it after that.
> > >>>>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> George
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
> > >>>>>>>>> <ge...@gmail.com>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> hi george,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> thx for the link.
> > >>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
> > >>>>>>>>> of your discussion
> > >>>>>>>>>>>> and/or
> > >>>>>>>>>>>>> draft
> > >>>>>>>>>>>>>>>>> (at least it's quite old already).
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
> > >>>>>>>>> <ge...@gmail.com>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Hi !
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
> > >>>>>>>>> "Service Handler" might
> > >>>>>>>>>>>> not
> > >>>>>>>>>>>> be
> > >>>>>>>>>>>>>> so
> > >>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
> > >>>>>>>>> as well.
> > >>>>>>>>>>>>>>>>>> Here is the latest pull request with
> > >>>>>>>>> some comments from Pete
> > >>>>>>>>>>>> yet
> > >>>>>>>>>>>> to
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>> reviewed:
> > >>>>>>>>> https://github.com/jboss/cdi/pull/28
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> > >>>>>>>>> <pm...@redhat.com>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Agreed :-)
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> George is working on it for CDI
> > >>>>>>>>> 1.1. George, can you share
> > >>>>>>>>>>>> your
> > >>>>>>>>>>>>>>>>>> proposal
> > >>>>>>>>>>>>>>>>>>> so far?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
> > >>>>>>>>> Petracek wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> hi pete,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> independent of my opinion
> > >>>>>>>>> about the feature (which is
> > >>>>>>>>>>>> still
> > >>>>>>>>>>>>> +0):
> > >>>>>>>>>>>>>>>>>>>> if it should be part of cdi
> > >>>>>>>>> 1.1, we have the following
> > >>>>>>>>>>>> options
> > >>>>>>>>>>>>>> imo:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1) the approach (including
> > >>>>>>>>> the name/s) we agree on will
> > >>>>>>>>>>>> be
> > >>>>>>>>>>>> used
> > >>>>>>>>>>>>>>> also
> > >>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
> > >>>>>>>>> is the package)
> > >>>>>>>>>>>>>>>>>>>> 2) the eg has a different
> > >>>>>>>>> opinion about it ->
> > >>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
> > >>>>>>>>> this discussion
> > >>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
> > >>>>>>>>> version and just allow the same
> > >>>>>>>>>>>> with
> > >>>>>>>>>>>>>> cdi
> > >>>>>>>>>>>>>>>>>> 1.0
> > >>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
> > >>>>>>>>> agree on the idea, it should be
> > >>>>>>>>>>>> re-visited
> > >>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
> > >>>>>>>>> it)
> > >>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
> > >>>>>>>>> of the result in cdi 1.1
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
> > >>>>>>>>> #4
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> > >>>>>>>>> <pm...@redhat.com>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I'm not sure what you
> > >>>>>>>>> mean by a "super interceptor",
> > >>>>>>>>>>>> but if
> > >>>>>>>>>>>>> you
> > >>>>>>>>>>>>>>>>>> mean it
> > >>>>>>>>>>>>>>>>>>> as
> > >>>>>>>>>>>>>>>>>>>>> in "super man"
> > >>>>>>>>> (something better than an interceptor),
> > >>>>>>>>>>>> then
> > >>>>>>>>>>>> I
> > >>>>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>>>>>>> disagree, it's
> > >>>>>>>>> actually a specialised form of
> > >>>>>>>>>>>> interceptor.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> The best use case I know
> > >>>>>>>>> of is the one John mentions -
> > >>>>>>>>>>>>> creating
> > >>>>>>>>>>>>>>> type
> > >>>>>>>>>>>>>>>>>>> safe
> > >>>>>>>>>>>>>>>>>>>>> references to queries:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> @QueryService
> > >>>>>>>>>>>>>>>>>>>>> interface UserQuery {
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> @Query("select u
> > >>>>>>>>> from User u")
> > >>>>>>>>>>>>>>>>>>>>> public List<User>
> > >>>>>>>>> getAllUsers();
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> @Query("select u
> > >>>>>>>>> from User u order by u.name")
> > >>>>>>>>>>>>>>>>>>>>> public List<User>
> > >>>>>>>>> getAllUsersSortedByName();
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Now, it may be the case
> > >>>>>>>>> that there aren't any other use
> > >>>>>>>>>>>> cases
> > >>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>> service
> > >>>>>>>>>>>>>>>>>>>>> handlers, in which case
> > >>>>>>>>> we should perhaps just offer
> > >>>>>>>>>>>> this
> > >>>>>>>>>>>>>>> particular
> > >>>>>>>>>>>>>>>>>>>>> service handler -
> > >>>>>>>>> references to type safe queries - as I
> > >>>>>>>>>>>> think
> > >>>>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Note, that at the moment
> > >>>>>>>>> service handlers are scheduled
> > >>>>>>>>>>>> for
> > >>>>>>>>>>>>> CDI
> > >>>>>>>>>>>>>>> 1.1.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
> > >>>>>>>>> Jason Porter wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Somewhat. I
> > >>>>>>>>> wouldn't really think of them as overrides,
> > >>>>>>>>>>>> they,
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> me,
> > >>>>>>>>>>>>>>>>>>>>> seem more like items to
> > >>>>>>>>> do in addition to whatever the
> > >>>>>>>>>>>>> original
> > >>>>>>>>>>>>>>> impl
> > >>>>>>>>>>>>>>>>>>> does.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
> > >>>>>>>>> seem more like super
> > >>>>>>>>>>>> interceptors.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
> > >>>>>>>>> 19:23, "John D. Ament" <
> > >>>>>>>>>>>>>>> john.d.ament@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> @jason
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I think the
> > >>>>>>>>> concepts are very dissimilar.
> > >>>>>>>>>>>> servicehandlers
> > >>>>>>>>>>>>>>> create
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>> implementation.
> > >>>>>>>>> delegates are more like overrides and
> > >>>>>>>>>>>> need
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> know
> > >>>>>>>>>>>>>>>>>>>>> about
> > >>>>>>>>>>>>>>>>>>>>>>> the method
> > >>>>>>>>> signature.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
> > >>>>>>>>> 2012 at 9:17 PM, Jason Porter <
> > >>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I think the
> > >>>>>>>>> idea of ServiceHandlers are good, but,
> > >>>>>>>>>>>> could
> > >>>>>>>>>>>> we
> > >>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>> do
> > >>>>>>>>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>>>>>>>>> with
> > >>>>>>>>> delegates?
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Sent from my
> > >>>>>>>>> iPhone
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
> > >>>>>>>>> 2012, at 19:05, "John D. Ament" <
> > >>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> @mark
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> I
> > >>>>>>>>> don't think it's a hard requirement for it to be
> > >>>>>>>>>>>> on an
> > >>>>>>>>>>>>>>>>>> interface.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> One of
> > >>>>>>>>> the best use-cases we built at my job is
> > >>>>>>>>>>>> using it
> > >>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>> calling
> > >>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
> > >>>>>>>>> The JDBC bindings do work, but not pretty.
> > >>>>>>>>>>>> we
> > >>>>>>>>>>>>> were
> > >>>>>>>>>>>>>>>>>> able to
> > >>>>>>>>>>>>>>>>>>>>>>>> create
> > >>>>>>>>>>>>>>>>>>>>>>>>> a fairly
> > >>>>>>>>> clean wrapper API, generic enough for
> > >>>>>>>>>>>> binding
> > >>>>>>>>>>>>>> in/out
> > >>>>>>>>>>>>>>>>>>>>> parameters.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> JOhn
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
> > >>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> > >>>>>>>>>>>>>>>>>> struberg@yahoo.de>
> > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> actually I don't really see a real benefit. I just
> > >>>>>>>>>>>> don't
> > >>>>>>>>>>>>>> yet
> > >>>>>>>>>>>>>>>>>> grok
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>>>>>>>>>> case
> > >>>>>>>>> for real world projects.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Why
> > >>>>>>>>> would one intercept an Interface and delegate
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>> calls
> > >>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>> method
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> handler?
> > >>>>>>>>>>>>>>>>>>>>>>>>>> This
> > >>>>>>>>> could be neat for mocking, but there are
> > >>>>>>>>>>>> better
> > >>>>>>>>>>>>>>>>>> frameworks for
> > >>>>>>>>>>>>>>>>>>>>>>>> that.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> thus
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> LieGrue,
> > >>>>>>>>>>>>>>>>>>>>>>>>>> strub
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> -----
> > >>>>>>>>> Original Message -----
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> From: Gerhard Petracek
> > >>>>>>>>>>>> <ge...@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> To: deltaspike-dev@incubator.apache.org
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> Cc:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> > >>>>>>>>>>>>> Discuss
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> ServiceHandler
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> if you have a lot of shared code, you can extract
> > >>>>>>>>>>>> it
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>>>> 1-n
> > >>>>>>>>>>>>>>>>>>>>> method/s or
> > >>>>>>>>>>>>>>>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> abstract class which is still easier than a new
> > >>>>>>>>>>>> concept.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> at least i haven't seen an use-case which really
> > >>>>>>>>>>>> needed
> > >>>>>>>>>>>>>> it.
> > >>>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> was
> > >>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> reason for a +0 (which still means that i'm ok
> > >>>>>>>>>>>> with
> > >>>>>>>>>>>>> adding
> > >>>>>>>>>>>>>>>>>> it).
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
> > >>>>>>>>>>>> boilerplate
> > >>>>>>>>>>>>>>> code
> > >>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>> it?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> hi pete,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> instead of the interface you can just
> > >>>>>>>>> implement
> > >>>>>>>>>>>> a
> > >>>>>>>>>>>> bean
> > >>>>>>>>>>>>>>> which
> > >>>>>>>>>>>>>>>>>>> does
> > >>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> same.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> > >>>>>>>>> <pm...@redhat.com>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
> > >>>>>>>>> instead?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> > >>>>>>>>> Petracek
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> +0
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> no -1 because there are
> > >>>>>>>>> use-cases for it.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
> > >>>>>>>>> cdi mechanisms
> > >>>>>>>>>>>>> instead.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> > >>>>>>>>>>>>> gerhard.petracek@gmail.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> hi john,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> > >>>>>>>>> fine.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> > >>>>>>>>>>>> <jo...@gmail.com>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Hi All
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
> > >>>>>>>>> the subject of
> > >>>>>>>>>>>>> ServiceHandler.
> > >>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> added 113 as a
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> child
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> > >>>>>>>>> appropriate but not
> > >>>>>>>>>>>> 100%
> > >>>>>>>>>>>>>> sure
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> (so please let
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> me
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> know if you think
> > >>>>>>>>> it's not appropriate as a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> child). ServiceHandler
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
> > >>>>>>>>> allows you to define
> > >>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> interceptor that
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> manages
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> generic calls against
> > >>>>>>>>> an injected interface.
> > >>>>>>>>>>>> The
> > >>>>>>>>>>>>>> API
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> is as follows:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> -
> > >>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
> > >>>>>>>>>>>> placed
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> on an annotation that
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> be placed on the
> > >>>>>>>>> interface. Indicates what
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> interceptor would be
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> invoked
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> for calls against this
> > >>>>>>>>> interface.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> It's then up to the
> > >>>>>>>>> application
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> developer/framework author to define
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> annotations that go on
> > >>>>>>>>> methods, as well as
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> interceptor itself
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> be invoked. The
> > >>>>>>>>> feature for ServiceHandler
> > >>>>>>>>>>>> would
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> to provide the
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> API of
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> the type and then the
> > >>>>>>>>> infrastructure
> > >>>>>>>>>>>> required to
> > >>>>>>>>>>>>>> make
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> the interceptor
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> called. Existing
> > >>>>>>>>> documentation of the
> > >>>>>>>>>>>> feature:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>
> > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> > >>>>>>>>>>>> ser
> > >>>>>>>>>>>> vicehandler.html
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> john
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Jason Porter
> > >>>>>>>>>>> http://lightguard-jp.blogspot.com
> > >>>>>>>>>>> http://twitter.com/lightguardjp
> > >>>>>>>>>>>
> > >>>>>>>>>>> Software Engineer
> > >>>>>>>>>>> Open Source Advocate
> > >>>>>>>>>>>
> > >>>>>>>>>>> PGP key id: 926CCFF5
> > >>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> > >>>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>>
> > >
> >
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
If we're still calling the feature "ServiceHandler" then why not
@ServiceHandler?
On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> if we don't need it perfect, if we need it we'll just use another name
> @DSHandler, @Handler...whatever it is ;)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/20 Pete Muir <pm...@redhat.com>:
> > :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
> >
> > On 20 Dec 2012, at 16:30, John D. Ament wrote:
> >
> >> The problem I have is that now InvocationHandler is both an interface
> and
> >> an @interface which will make it impossible for imports. I don't think
> >> they should have the same name.
> >>
> >>
> >> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com> wrote:
> >>
> >>>
> >>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
> >>>
> >>>> All,
> >>>>
> >>>> So mostly ok from my perspective. One thing to note:
> >>>>
> >>>> @InvocationHandlerBinding
> >>>> public @interface Repository {}
> >>>>
> >>>> @Repository
> >>>> public interface MyRepository {
> >>>> ...
> >>>> }
> >>>>
> >>>> @Repository @InvocationHandler
> >>>> public class MyInvocationHandler implements InvocationHandler {
> >>>> ...
> >>>> }
> >>>>
> >>>> Why do we have a @InvocationHandler here? Is it supposed to be
> >>>> @InvocationHandlerBinding instead? If so, is it really needed here?
> >>>
> >>> No, it should be @InvocationHandler, it's analagous to @Interceptor.
> It's
> >>> not 100% necessary as we already implement the interface, which is
> enough
> >>> of the marker.
> >>>
> >>>>
> >>>> Thinking about the implementation for this, I think this actually
> becomes
> >>>> easier to use and easier to understand over the Solder solution. The
> >>>> implementation of the InvocationHandler becomes a true CDI bean.
> >>>>
> >>>> Should DS support Interceptors and Decorators on
> >>>> InvocationHandler beans?
> >>>>
> >>>> Do you mean the implementation class or the interface?
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> >>>> <rm...@gmail.com>wrote:
> >>>>
> >>>>> i'd rather say no because the idea is to ease "util" extension
> >>>>> writing. that's clearly not intended to be full business beans IMO
> (at
> >>>>> least for a first step)
> >>>>>
> >>>>> That's why i'd leave it as this for now
> >>>>>
> >>>>> wdyt?
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> Twitter: @rmannibucau
> >>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>> Github: https://github.com/rmannibucau
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> >>>>>> Mark refers to my call stack.
> >>>>>>
> >>>>>> Out of the box this call stack would exist just in OWB, because Weld
> >>>>> would
> >>>>>> not apply any Interceptors or Decorators...
> >>>>>>
> >>>>>> The question is: Should DS support Interceptors and Decorators on
> >>>>>> InvocationHandler beans? My answer would be: yes, if our
> implementation
> >>>>>> shall be a preview of CDI-110.
> >>>>>> And that would make things complicated in the implementation...
> >>>>>>
> >>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> >>>>>> <rm...@gmail.com>:
> >>>>>>
> >>>>>>> is it an issue for servicehandler? i don't think so
> >>>>>>>
> >>>>>>> it is often used to get util classes dynamically created, it is
> rarely
> >>>>>>> (i never saw it) decorated directly
> >>>>>>>
> >>>>>>>
> >>>>>>> Romain Manni-Bucau
> >>>>>>> Twitter: @rmannibucau
> >>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
> >>>>>>>> we stumbled about this lately. It seems CDI only forces support
> for
> >>>>>>>> interceptors and decorators for CDI-annotated classes, but not for
> >>>>>>>> Bean<T> which get added via extensions nor even producer methods
> and
> >>>>>>>> fields :/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Of course OWB does it, but it would be not portable...
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
> >>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
> >>>>>>>>> <de...@incubator.apache.org>
> >>>>>>>>> Cc:
> >>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
> >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>>>>>> ServiceHandler
> >>>>>>>>>
> >>>>>>>>> T wo things about this: First: I don't like from the solder
> >>> approach,
> >>>>>>>>> because the interface is annotated instead of the implementation.
> >>>>>>>>>
> >>>>>>>>> Second, if we implement this we should conceptually make clear
> how
> >>> it
> >>>>>>>>> differentiates from Interceptors and Decorators. And personally I
> >>>>> think
> >>>>>>>>> this would work better with the InvocationHandler approach than
> with
> >>>>> an
> >>>>>>>>> approach that is very similar to interceptors.
> >>>>>>>>>
> >>>>>>>>> So +1 for an approach like this:
> >>>>>>>>>
> >>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
> >>>>>>>>> public class MyInvocationHandler implements InvocationHandler {
> >>>>>>>>> ...
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> Technically we would register a custom Bean for every found
> >>>>>>>>> InvocationHandler with that annotation and take over the
> >>>>>>>>> interceptor-bindings from the interfaceŠ
> >>>>>>>>> So the invocation stack would be clear, too:
> >>>>>>>>> First Interceptors,
> >>>>>>>>> Second Decorators,
> >>>>>>>>> Third InvocationHandler
> >>>>>>>>>
> >>>>>>>>> Wdyt?
> >>>>>>>>>
> >>>>>>>>> Arne
> >>>>>>>>>
> >>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> >>>>>>>>> <rm...@gmail.com>:
> >>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this
> solder
> >>>>>>>>>> part portable ans it should be fine
> >>>>>>>>>>
> >>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> >>>>>>>>>>> At this point, I'd say just do it as is in solder.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> >>>>>>>>>>> <jo...@gmail.com>wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regarding the two open questions:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be
> used
> >>>>>>>>> also
> >>>>>>>>>>>> for
> >>>>>>>>>>>> cdi 1.1 (the only difference is the package)
> >>>>>>>>>>>> 2) the eg has a different opinion about it ->
> >>>>>>>>>>>>
> >>>>>>>>>>>> It looks like the JSR's answer
> >>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>>>>>>> is still unresolved - I'm not sure if we can get any further
> >>>>>>>>> answer at
> >>>>>>>>>>>> this
> >>>>>>>>>>>> time. The last posts on the subject seem to discuss using
> >>>>>>>>> something
> >>>>>>>>>>>> along
> >>>>>>>>>>>> the lines of an invocation handler, which I think would work
> >>> well.
> >>>>>>>>>>>> Since
> >>>>>>>>>>>> we have some features coming up that are interested in having
> >>>>>>>>> service
> >>>>>>>>>>>> handlers available, do we
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in
> Solder?
> >>>>>>>>>>>> 2. Push EG on a resolution
> >>>>>>>>>>>> 3. Do it using invocation handlers.
> >>>>>>>>>>>> 4. Do it some other way?
> >>>>>>>>>>>>
> >>>>>>>>>>>> John
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> as mentioned before we need the answers to the existing
> >>>>>>>>> questions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> regards,
> >>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> All,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
> >>>>>>>>>>>> apologize.
> >>>>>>>>>>>> it
> >>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
> >>>>>>>>> requesting
> >>>>>>>>>>>>> additional
> >>>>>>>>>>>>>> comments from everyone. Any other feedback?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> John
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> hi george,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> thx for the information. i thought there might be at
> >>>>>>>>> least some
> >>>>>>>>>>>>>> additional
> >>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
> >>>>>>>>> several
> >>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>> -> imo we should continue with them.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
> >>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hello Gerhard,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
> >>>>>>>>> old, but I
> >>>>>>>>>>>> haven´t had
> >>>>>>>>>>>>>> time
> >>>>>>>>>>>>>>>> to work on it after that.
> >>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> George
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
> >>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> hi george,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> thx for the link.
> >>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
> >>>>>>>>> of your discussion
> >>>>>>>>>>>> and/or
> >>>>>>>>>>>>> draft
> >>>>>>>>>>>>>>>>> (at least it's quite old already).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
> >>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi !
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
> >>>>>>>>> "Service Handler" might
> >>>>>>>>>>>> not
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
> >>>>>>>>> as well.
> >>>>>>>>>>>>>>>>>> Here is the latest pull request with
> >>>>>>>>> some comments from Pete
> >>>>>>>>>>>> yet
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> reviewed:
> >>>>>>>>> https://github.com/jboss/cdi/pull/28
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Agreed :-)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> George is working on it for CDI
> >>>>>>>>> 1.1. George, can you share
> >>>>>>>>>>>> your
> >>>>>>>>>>>>>>>>>> proposal
> >>>>>>>>>>>>>>>>>>> so far?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
> >>>>>>>>> Petracek wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> independent of my opinion
> >>>>>>>>> about the feature (which is
> >>>>>>>>>>>> still
> >>>>>>>>>>>>> +0):
> >>>>>>>>>>>>>>>>>>>> if it should be part of cdi
> >>>>>>>>> 1.1, we have the following
> >>>>>>>>>>>> options
> >>>>>>>>>>>>>> imo:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1) the approach (including
> >>>>>>>>> the name/s) we agree on will
> >>>>>>>>>>>> be
> >>>>>>>>>>>> used
> >>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
> >>>>>>>>> is the package)
> >>>>>>>>>>>>>>>>>>>> 2) the eg has a different
> >>>>>>>>> opinion about it ->
> >>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
> >>>>>>>>> this discussion
> >>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
> >>>>>>>>> version and just allow the same
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>> cdi
> >>>>>>>>>>>>>>>>>> 1.0
> >>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
> >>>>>>>>> agree on the idea, it should be
> >>>>>>>>>>>> re-visited
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
> >>>>>>>>> it)
> >>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
> >>>>>>>>> of the result in cdi 1.1
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
> >>>>>>>>> #4
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I'm not sure what you
> >>>>>>>>> mean by a "super interceptor",
> >>>>>>>>>>>> but if
> >>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>> mean it
> >>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>> in "super man"
> >>>>>>>>> (something better than an interceptor),
> >>>>>>>>>>>> then
> >>>>>>>>>>>> I
> >>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>> disagree, it's
> >>>>>>>>> actually a specialised form of
> >>>>>>>>>>>> interceptor.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The best use case I know
> >>>>>>>>> of is the one John mentions -
> >>>>>>>>>>>>> creating
> >>>>>>>>>>>>>>> type
> >>>>>>>>>>>>>>>>>>> safe
> >>>>>>>>>>>>>>>>>>>>> references to queries:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> @QueryService
> >>>>>>>>>>>>>>>>>>>>> interface UserQuery {
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>>>>> from User u")
> >>>>>>>>>>>>>>>>>>>>> public List<User>
> >>>>>>>>> getAllUsers();
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>>>>> from User u order by u.name")
> >>>>>>>>>>>>>>>>>>>>> public List<User>
> >>>>>>>>> getAllUsersSortedByName();
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Now, it may be the case
> >>>>>>>>> that there aren't any other use
> >>>>>>>>>>>> cases
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>>>>>>> handlers, in which case
> >>>>>>>>> we should perhaps just offer
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>> particular
> >>>>>>>>>>>>>>>>>>>>> service handler -
> >>>>>>>>> references to type safe queries - as I
> >>>>>>>>>>>> think
> >>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Note, that at the moment
> >>>>>>>>> service handlers are scheduled
> >>>>>>>>>>>> for
> >>>>>>>>>>>>> CDI
> >>>>>>>>>>>>>>> 1.1.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
> >>>>>>>>> Jason Porter wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Somewhat. I
> >>>>>>>>> wouldn't really think of them as overrides,
> >>>>>>>>>>>> they,
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> me,
> >>>>>>>>>>>>>>>>>>>>> seem more like items to
> >>>>>>>>> do in addition to whatever the
> >>>>>>>>>>>>> original
> >>>>>>>>>>>>>>> impl
> >>>>>>>>>>>>>>>>>>> does.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
> >>>>>>>>> seem more like super
> >>>>>>>>>>>> interceptors.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
> >>>>>>>>> 19:23, "John D. Ament" <
> >>>>>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> @jason
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I think the
> >>>>>>>>> concepts are very dissimilar.
> >>>>>>>>>>>> servicehandlers
> >>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> implementation.
> >>>>>>>>> delegates are more like overrides and
> >>>>>>>>>>>> need
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>> the method
> >>>>>>>>> signature.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
> >>>>>>>>> 2012 at 9:17 PM, Jason Porter <
> >>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I think the
> >>>>>>>>> idea of ServiceHandlers are good, but,
> >>>>>>>>>>>> could
> >>>>>>>>>>>> we
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>> delegates?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Sent from my
> >>>>>>>>> iPhone
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
> >>>>>>>>> 2012, at 19:05, "John D. Ament" <
> >>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> @mark
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>> don't think it's a hard requirement for it to be
> >>>>>>>>>>>> on an
> >>>>>>>>>>>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> One of
> >>>>>>>>> the best use-cases we built at my job is
> >>>>>>>>>>>> using it
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
> >>>>>>>>> The JDBC bindings do work, but not pretty.
> >>>>>>>>>>>> we
> >>>>>>>>>>>>> were
> >>>>>>>>>>>>>>>>>> able to
> >>>>>>>>>>>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>>>>>>>>> a fairly
> >>>>>>>>> clean wrapper API, generic enough for
> >>>>>>>>>>>> binding
> >>>>>>>>>>>>>> in/out
> >>>>>>>>>>>>>>>>>>>>> parameters.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> JOhn
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
> >>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>>>>>>>>>>>>>>>>> struberg@yahoo.de>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> actually I don't really see a real benefit. I just
> >>>>>>>>>>>> don't
> >>>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>>>> grok
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>>>>>>> case
> >>>>>>>>> for real world projects.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why
> >>>>>>>>> would one intercept an Interface and delegate
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> calls
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> handler?
> >>>>>>>>>>>>>>>>>>>>>>>>>> This
> >>>>>>>>> could be neat for mocking, but there are
> >>>>>>>>>>>> better
> >>>>>>>>>>>>>>>>>> frameworks for
> >>>>>>>>>>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>>>>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>>>>> Original Message -----
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> From: Gerhard Petracek
> >>>>>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> Cc:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> >>>>>>>>>>>>> Discuss
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> ServiceHandler
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> if you have a lot of shared code, you can extract
> >>>>>>>>>>>> it
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>> 1-n
> >>>>>>>>>>>>>>>>>>>>> method/s or
> >>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> abstract class which is still easier than a new
> >>>>>>>>>>>> concept.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> at least i haven't seen an use-case which really
> >>>>>>>>>>>> needed
> >>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> reason for a +0 (which still means that i'm ok
> >>>>>>>>>>>> with
> >>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>> it).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
> >>>>>>>>>>>> boilerplate
> >>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> it?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> instead of the interface you can just
> >>>>>>>>> implement
> >>>>>>>>>>>> a
> >>>>>>>>>>>> bean
> >>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>> does
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> same.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>>>>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
> >>>>>>>>> instead?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> >>>>>>>>> Petracek
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> +0
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> no -1 because there are
> >>>>>>>>> use-cases for it.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
> >>>>>>>>> cdi mechanisms
> >>>>>>>>>>>>> instead.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> >>>>>>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> >>>>>>>>> fine.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> >>>>>>>>>>>> <jo...@gmail.com>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hi All
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
> >>>>>>>>> the subject of
> >>>>>>>>>>>>> ServiceHandler.
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> added 113 as a
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> child
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> >>>>>>>>> appropriate but not
> >>>>>>>>>>>> 100%
> >>>>>>>>>>>>>> sure
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> (so please let
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> me
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> know if you think
> >>>>>>>>> it's not appropriate as a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> child). ServiceHandler
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
> >>>>>>>>> allows you to define
> >>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> interceptor that
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> manages
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> generic calls against
> >>>>>>>>> an injected interface.
> >>>>>>>>>>>> The
> >>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> is as follows:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>>>>>>> placed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> on an annotation that
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> be placed on the
> >>>>>>>>> interface. Indicates what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> interceptor would be
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> invoked
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> for calls against this
> >>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> It's then up to the
> >>>>>>>>> application
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> developer/framework author to define
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> annotations that go on
> >>>>>>>>> methods, as well as
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> interceptor itself
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> be invoked. The
> >>>>>>>>> feature for ServiceHandler
> >>>>>>>>>>>> would
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> to provide the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> API of
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> the type and then the
> >>>>>>>>> infrastructure
> >>>>>>>>>>>> required to
> >>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> the interceptor
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> called. Existing
> >>>>>>>>> documentation of the
> >>>>>>>>>>>> feature:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>>>>>> ser
> >>>>>>>>>>>> vicehandler.html
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> john
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Jason Porter
> >>>>>>>>>>> http://lightguard-jp.blogspot.com
> >>>>>>>>>>> http://twitter.com/lightguardjp
> >>>>>>>>>>>
> >>>>>>>>>>> Software Engineer
> >>>>>>>>>>> Open Source Advocate
> >>>>>>>>>>>
> >>>>>>>>>>> PGP key id: 926CCFF5
> >>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if we don't need it perfect, if we need it we'll just use another name
@DSHandler, @Handler...whatever it is ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Pete Muir <pm...@redhat.com>:
> :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
>
> On 20 Dec 2012, at 16:30, John D. Ament wrote:
>
>> The problem I have is that now InvocationHandler is both an interface and
>> an @interface which will make it impossible for imports. I don't think
>> they should have the same name.
>>
>>
>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com> wrote:
>>
>>>
>>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>>>
>>>> All,
>>>>
>>>> So mostly ok from my perspective. One thing to note:
>>>>
>>>> @InvocationHandlerBinding
>>>> public @interface Repository {}
>>>>
>>>> @Repository
>>>> public interface MyRepository {
>>>> ...
>>>> }
>>>>
>>>> @Repository @InvocationHandler
>>>> public class MyInvocationHandler implements InvocationHandler {
>>>> ...
>>>> }
>>>>
>>>> Why do we have a @InvocationHandler here? Is it supposed to be
>>>> @InvocationHandlerBinding instead? If so, is it really needed here?
>>>
>>> No, it should be @InvocationHandler, it's analagous to @Interceptor. It's
>>> not 100% necessary as we already implement the interface, which is enough
>>> of the marker.
>>>
>>>>
>>>> Thinking about the implementation for this, I think this actually becomes
>>>> easier to use and easier to understand over the Solder solution. The
>>>> implementation of the InvocationHandler becomes a true CDI bean.
>>>>
>>>> Should DS support Interceptors and Decorators on
>>>> InvocationHandler beans?
>>>>
>>>> Do you mean the implementation class or the interface?
>>>>
>>>> John
>>>>
>>>>
>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
>>>> <rm...@gmail.com>wrote:
>>>>
>>>>> i'd rather say no because the idea is to ease "util" extension
>>>>> writing. that's clearly not intended to be full business beans IMO (at
>>>>> least for a first step)
>>>>>
>>>>> That's why i'd leave it as this for now
>>>>>
>>>>> wdyt?
>>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>>>>> Mark refers to my call stack.
>>>>>>
>>>>>> Out of the box this call stack would exist just in OWB, because Weld
>>>>> would
>>>>>> not apply any Interceptors or Decorators...
>>>>>>
>>>>>> The question is: Should DS support Interceptors and Decorators on
>>>>>> InvocationHandler beans? My answer would be: yes, if our implementation
>>>>>> shall be a preview of CDI-110.
>>>>>> And that would make things complicated in the implementation...
>>>>>>
>>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
>>>>>> <rm...@gmail.com>:
>>>>>>
>>>>>>> is it an issue for servicehandler? i don't think so
>>>>>>>
>>>>>>> it is often used to get util classes dynamically created, it is rarely
>>>>>>> (i never saw it) decorated directly
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
>>>>>>>> we stumbled about this lately. It seems CDI only forces support for
>>>>>>>> interceptors and decorators for CDI-annotated classes, but not for
>>>>>>>> Bean<T> which get added via extensions nor even producer methods and
>>>>>>>> fields :/
>>>>>>>>
>>>>>>>>
>>>>>>>> Of course OWB does it, but it would be not portable...
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
>>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>>>>> <de...@incubator.apache.org>
>>>>>>>>> Cc:
>>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>>>>>> ServiceHandler
>>>>>>>>>
>>>>>>>>> T wo things about this: First: I don't like from the solder
>>> approach,
>>>>>>>>> because the interface is annotated instead of the implementation.
>>>>>>>>>
>>>>>>>>> Second, if we implement this we should conceptually make clear how
>>> it
>>>>>>>>> differentiates from Interceptors and Decorators. And personally I
>>>>> think
>>>>>>>>> this would work better with the InvocationHandler approach than with
>>>>> an
>>>>>>>>> approach that is very similar to interceptors.
>>>>>>>>>
>>>>>>>>> So +1 for an approach like this:
>>>>>>>>>
>>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>>>>> public class MyInvocationHandler implements InvocationHandler {
>>>>>>>>> ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Technically we would register a custom Bean for every found
>>>>>>>>> InvocationHandler with that annotation and take over the
>>>>>>>>> interceptor-bindings from the interfaceŠ
>>>>>>>>> So the invocation stack would be clear, too:
>>>>>>>>> First Interceptors,
>>>>>>>>> Second Decorators,
>>>>>>>>> Third InvocationHandler
>>>>>>>>>
>>>>>>>>> Wdyt?
>>>>>>>>>
>>>>>>>>> Arne
>>>>>>>>>
>>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>>>>>>> <rm...@gmail.com>:
>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>>>>>>> part portable ans it should be fine
>>>>>>>>>>
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>>>>> <jo...@gmail.com>wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding the two open questions:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be used
>>>>>>>>> also
>>>>>>>>>>>> for
>>>>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>>>>
>>>>>>>>>>>> It looks like the JSR's answer
>>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>>>>> is still unresolved - I'm not sure if we can get any further
>>>>>>>>> answer at
>>>>>>>>>>>> this
>>>>>>>>>>>> time. The last posts on the subject seem to discuss using
>>>>>>>>> something
>>>>>>>>>>>> along
>>>>>>>>>>>> the lines of an invocation handler, which I think would work
>>> well.
>>>>>>>>>>>> Since
>>>>>>>>>>>> we have some features coming up that are interested in having
>>>>>>>>> service
>>>>>>>>>>>> handlers available, do we
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>>>>>>> 2. Push EG on a resolution
>>>>>>>>>>>> 3. Do it using invocation handlers.
>>>>>>>>>>>> 4. Do it some other way?
>>>>>>>>>>>>
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>
>>>>>>>>>>>>> as mentioned before we need the answers to the existing
>>>>>>>>> questions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>>>>>>>> apologize.
>>>>>>>>>>>> it
>>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
>>>>>>>>> requesting
>>>>>>>>>>>>> additional
>>>>>>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thx for the information. i thought there might be at
>>>>>>>>> least some
>>>>>>>>>>>>>> additional
>>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
>>>>>>>>> several
>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>>>>>>>> old, but I
>>>>>>>>>>>> haven´t had
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>> to work on it after that.
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
>>>>>>>>> of your discussion
>>>>>>>>>>>> and/or
>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
>>>>>>>>> "Service Handler" might
>>>>>>>>>>>> not
>>>>>>>>>>>> be
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
>>>>>>>>> as well.
>>>>>>>>>>>>>>>>>> Here is the latest pull request with
>>>>>>>>> some comments from Pete
>>>>>>>>>>>> yet
>>>>>>>>>>>> to
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> reviewed:
>>>>>>>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> George is working on it for CDI
>>>>>>>>> 1.1. George, can you share
>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>>>>> Petracek wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> independent of my opinion
>>>>>>>>> about the feature (which is
>>>>>>>>>>>> still
>>>>>>>>>>>>> +0):
>>>>>>>>>>>>>>>>>>>> if it should be part of cdi
>>>>>>>>> 1.1, we have the following
>>>>>>>>>>>> options
>>>>>>>>>>>>>> imo:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1) the approach (including
>>>>>>>>> the name/s) we agree on will
>>>>>>>>>>>> be
>>>>>>>>>>>> used
>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>>>>>>>> is the package)
>>>>>>>>>>>>>>>>>>>> 2) the eg has a different
>>>>>>>>> opinion about it ->
>>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>>>>>>>> this discussion
>>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
>>>>>>>>> version and just allow the same
>>>>>>>>>>>> with
>>>>>>>>>>>>>> cdi
>>>>>>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
>>>>>>>>> agree on the idea, it should be
>>>>>>>>>>>> re-visited
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
>>>>>>>>> it)
>>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
>>>>>>>>> of the result in cdi 1.1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>>>>>>>> #4
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'm not sure what you
>>>>>>>>> mean by a "super interceptor",
>>>>>>>>>>>> but if
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> in "super man"
>>>>>>>>> (something better than an interceptor),
>>>>>>>>>>>> then
>>>>>>>>>>>> I
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> disagree, it's
>>>>>>>>> actually a specialised form of
>>>>>>>>>>>> interceptor.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The best use case I know
>>>>>>>>> of is the one John mentions -
>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>> type
>>>>>>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>>> from User u")
>>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>>> getAllUsers();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>>> from User u order by u.name")
>>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Now, it may be the case
>>>>>>>>> that there aren't any other use
>>>>>>>>>>>> cases
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>>> handlers, in which case
>>>>>>>>> we should perhaps just offer
>>>>>>>>>>>> this
>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>>>>> service handler -
>>>>>>>>> references to type safe queries - as I
>>>>>>>>>>>> think
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note, that at the moment
>>>>>>>>> service handlers are scheduled
>>>>>>>>>>>> for
>>>>>>>>>>>>> CDI
>>>>>>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>>>>>>>> Jason Porter wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Somewhat. I
>>>>>>>>> wouldn't really think of them as overrides,
>>>>>>>>>>>> they,
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>>>>> seem more like items to
>>>>>>>>> do in addition to whatever the
>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> impl
>>>>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
>>>>>>>>> seem more like super
>>>>>>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>>>>>>>> 19:23, "John D. Ament" <
>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>>> concepts are very dissimilar.
>>>>>>>>>>>> servicehandlers
>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>> delegates are more like overrides and
>>>>>>>>>>>> need
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>> the method
>>>>>>>>> signature.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>>>>>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>>> idea of ServiceHandlers are good, but,
>>>>>>>>>>>> could
>>>>>>>>>>>> we
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>> delegates?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sent from my
>>>>>>>>> iPhone
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
>>>>>>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>> don't think it's a hard requirement for it to be
>>>>>>>>>>>> on an
>>>>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> One of
>>>>>>>>> the best use-cases we built at my job is
>>>>>>>>>>>> using it
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
>>>>>>>>> The JDBC bindings do work, but not pretty.
>>>>>>>>>>>> we
>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>>>>> a fairly
>>>>>>>>> clean wrapper API, generic enough for
>>>>>>>>>>>> binding
>>>>>>>>>>>>>> in/out
>>>>>>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
>>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> actually I don't really see a real benefit. I just
>>>>>>>>>>>> don't
>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>> grok
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Why
>>>>>>>>> would one intercept an Interface and delegate
>>>>>>>>>>>> the
>>>>>>>>>>>>> calls
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>> could be neat for mocking, but there are
>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> From: Gerhard Petracek
>>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> if you have a lot of shared code, you can extract
>>>>>>>>>>>> it
>>>>>>>>>>>> in
>>>>>>>>>>>>>> 1-n
>>>>>>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> abstract class which is still easier than a new
>>>>>>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> at least i haven't seen an use-case which really
>>>>>>>>>>>> needed
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>>>>>>> with
>>>>>>>>>>>>> adding
>>>>>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>>>>>>> boilerplate
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>>>>> implement
>>>>>>>>>>>> a
>>>>>>>>>>>> bean
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>>>>>>> instead?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>>>>> Petracek
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> no -1 because there are
>>>>>>>>> use-cases for it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>>>>>>> cdi mechanisms
>>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>>>>> fine.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>>>>>>> the subject of
>>>>>>>>>>>>> ServiceHandler.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> added 113 as a
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>>>>>>> appropriate but not
>>>>>>>>>>>> 100%
>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> (so please let
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> know if you think
>>>>>>>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
>>>>>>>>> allows you to define
>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> interceptor that
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> generic calls against
>>>>>>>>> an injected interface.
>>>>>>>>>>>> The
>>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> is as follows:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> on an annotation that
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> be placed on the
>>>>>>>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> interceptor would be
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> for calls against this
>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It's then up to the
>>>>>>>>> application
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> annotations that go on
>>>>>>>>> methods, as well as
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> interceptor itself
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> be invoked. The
>>>>>>>>> feature for ServiceHandler
>>>>>>>>>>>> would
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> to provide the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> the type and then the
>>>>>>>>> infrastructure
>>>>>>>>>>>> required to
>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> the interceptor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> called. Existing
>>>>>>>>> documentation of the
>>>>>>>>>>>> feature:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>>>>> ser
>>>>>>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jason Porter
>>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>> http://twitter.com/lightguardjp
>>>>>>>>>>>
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> Open Source Advocate
>>>>>>>>>>>
>>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
:-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
On 20 Dec 2012, at 16:30, John D. Ament wrote:
> The problem I have is that now InvocationHandler is both an interface and
> an @interface which will make it impossible for imports. I don't think
> they should have the same name.
>
>
> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com> wrote:
>
>>
>> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>>
>>> All,
>>>
>>> So mostly ok from my perspective. One thing to note:
>>>
>>> @InvocationHandlerBinding
>>> public @interface Repository {}
>>>
>>> @Repository
>>> public interface MyRepository {
>>> ...
>>> }
>>>
>>> @Repository @InvocationHandler
>>> public class MyInvocationHandler implements InvocationHandler {
>>> ...
>>> }
>>>
>>> Why do we have a @InvocationHandler here? Is it supposed to be
>>> @InvocationHandlerBinding instead? If so, is it really needed here?
>>
>> No, it should be @InvocationHandler, it's analagous to @Interceptor. It's
>> not 100% necessary as we already implement the interface, which is enough
>> of the marker.
>>
>>>
>>> Thinking about the implementation for this, I think this actually becomes
>>> easier to use and easier to understand over the Solder solution. The
>>> implementation of the InvocationHandler becomes a true CDI bean.
>>>
>>> Should DS support Interceptors and Decorators on
>>> InvocationHandler beans?
>>>
>>> Do you mean the implementation class or the interface?
>>>
>>> John
>>>
>>>
>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
>>> <rm...@gmail.com>wrote:
>>>
>>>> i'd rather say no because the idea is to ease "util" extension
>>>> writing. that's clearly not intended to be full business beans IMO (at
>>>> least for a first step)
>>>>
>>>> That's why i'd leave it as this for now
>>>>
>>>> wdyt?
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>>>> Mark refers to my call stack.
>>>>>
>>>>> Out of the box this call stack would exist just in OWB, because Weld
>>>> would
>>>>> not apply any Interceptors or Decorators...
>>>>>
>>>>> The question is: Should DS support Interceptors and Decorators on
>>>>> InvocationHandler beans? My answer would be: yes, if our implementation
>>>>> shall be a preview of CDI-110.
>>>>> And that would make things complicated in the implementation...
>>>>>
>>>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
>>>>> <rm...@gmail.com>:
>>>>>
>>>>>> is it an issue for servicehandler? i don't think so
>>>>>>
>>>>>> it is often used to get util classes dynamically created, it is rarely
>>>>>> (i never saw it) decorated directly
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
>>>>>>> we stumbled about this lately. It seems CDI only forces support for
>>>>>>> interceptors and decorators for CDI-annotated classes, but not for
>>>>>>> Bean<T> which get added via extensions nor even producer methods and
>>>>>>> fields :/
>>>>>>>
>>>>>>>
>>>>>>> Of course OWB does it, but it would be not portable...
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: Arne Limburg <ar...@openknowledge.de>
>>>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>>>> <de...@incubator.apache.org>
>>>>>>>> Cc:
>>>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>>>>> ServiceHandler
>>>>>>>>
>>>>>>>> T wo things about this: First: I don't like from the solder
>> approach,
>>>>>>>> because the interface is annotated instead of the implementation.
>>>>>>>>
>>>>>>>> Second, if we implement this we should conceptually make clear how
>> it
>>>>>>>> differentiates from Interceptors and Decorators. And personally I
>>>> think
>>>>>>>> this would work better with the InvocationHandler approach than with
>>>> an
>>>>>>>> approach that is very similar to interceptors.
>>>>>>>>
>>>>>>>> So +1 for an approach like this:
>>>>>>>>
>>>>>>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>>>> public class MyInvocationHandler implements InvocationHandler {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> Technically we would register a custom Bean for every found
>>>>>>>> InvocationHandler with that annotation and take over the
>>>>>>>> interceptor-bindings from the interfaceŠ
>>>>>>>> So the invocation stack would be clear, too:
>>>>>>>> First Interceptors,
>>>>>>>> Second Decorators,
>>>>>>>> Third InvocationHandler
>>>>>>>>
>>>>>>>> Wdyt?
>>>>>>>>
>>>>>>>> Arne
>>>>>>>>
>>>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>>>>>> <rm...@gmail.com>:
>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>>>>>> part portable ans it should be fine
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>>>> <jo...@gmail.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Regarding the two open questions:
>>>>>>>>>>>
>>>>>>>>>>> 1) the approach (including the name/s) we agree on will be used
>>>>>>>> also
>>>>>>>>>>> for
>>>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>>>
>>>>>>>>>>> It looks like the JSR's answer
>>>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>>>> is still unresolved - I'm not sure if we can get any further
>>>>>>>> answer at
>>>>>>>>>>> this
>>>>>>>>>>> time. The last posts on the subject seem to discuss using
>>>>>>>> something
>>>>>>>>>>> along
>>>>>>>>>>> the lines of an invocation handler, which I think would work
>> well.
>>>>>>>>>>> Since
>>>>>>>>>>> we have some features coming up that are interested in having
>>>>>>>> service
>>>>>>>>>>> handlers available, do we
>>>>>>>>>>>
>>>>>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>>>>>> 2. Push EG on a resolution
>>>>>>>>>>> 3. Do it using invocation handlers.
>>>>>>>>>>> 4. Do it some other way?
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> hi john,
>>>>>>>>>>>>
>>>>>>>>>>>> as mentioned before we need the answers to the existing
>>>>>>>> questions.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>>>>>>> apologize.
>>>>>>>>>>> it
>>>>>>>>>>>>> looks like where we last left off, Gerhard was still
>>>>>>>> requesting
>>>>>>>>>>>> additional
>>>>>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>>>>>
>>>>>>>>>>>>> John
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thx for the information. i thought there might be at
>>>>>>>> least some
>>>>>>>>>>>>> additional
>>>>>>>>>>>>>> answers/clarifications, since pete asked for them in
>>>>>>>> several
>>>>>>>>>>> comments.
>>>>>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/3/12 George Gastaldi
>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>>>>>>> old, but I
>>>>>>>>>>> haven´t had
>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> to work on it after that.
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>>>>>> i'm not sure if it is the latest state
>>>>>>>> of your discussion
>>>>>>>>>>> and/or
>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
>>>>>>>> "Service Handler" might
>>>>>>>>>>> not
>>>>>>>>>>> be
>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>> appropriate, so it should be discussed
>>>>>>>> as well.
>>>>>>>>>>>>>>>>> Here is the latest pull request with
>>>>>>>> some comments from Pete
>>>>>>>>>>> yet
>>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> reviewed:
>>>>>>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> George is working on it for CDI
>>>>>>>> 1.1. George, can you share
>>>>>>>>>>> your
>>>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>>>> Petracek wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> independent of my opinion
>>>>>>>> about the feature (which is
>>>>>>>>>>> still
>>>>>>>>>>>> +0):
>>>>>>>>>>>>>>>>>>> if it should be part of cdi
>>>>>>>> 1.1, we have the following
>>>>>>>>>>> options
>>>>>>>>>>>>> imo:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) the approach (including
>>>>>>>> the name/s) we agree on will
>>>>>>>>>>> be
>>>>>>>>>>> used
>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>>>>>>> is the package)
>>>>>>>>>>>>>>>>>>> 2) the eg has a different
>>>>>>>> opinion about it ->
>>>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>>>>>>> this discussion
>>>>>>>>>>>>>>>>>>> 2b) we wait for the final
>>>>>>>> version and just allow the same
>>>>>>>>>>> with
>>>>>>>>>>>>> cdi
>>>>>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>>>>>> 3) if the eg doesn't
>>>>>>>> agree on the idea, it should be
>>>>>>>>>>> re-visited
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> deltaspike (if we really need
>>>>>>>> it)
>>>>>>>>>>>>>>>>>>> 4) we agree on it independent
>>>>>>>> of the result in cdi 1.1
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>>>>>>> #4
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm not sure what you
>>>>>>>> mean by a "super interceptor",
>>>>>>>>>>> but if
>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> in "super man"
>>>>>>>> (something better than an interceptor),
>>>>>>>>>>> then
>>>>>>>>>>> I
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>> disagree, it's
>>>>>>>> actually a specialised form of
>>>>>>>>>>> interceptor.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The best use case I know
>>>>>>>> of is the one John mentions -
>>>>>>>>>>>> creating
>>>>>>>>>>>>>> type
>>>>>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>> from User u")
>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>> getAllUsers();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>>>> from User u order by u.name")
>>>>>>>>>>>>>>>>>>>> public List<User>
>>>>>>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Now, it may be the case
>>>>>>>> that there aren't any other use
>>>>>>>>>>> cases
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>> handlers, in which case
>>>>>>>> we should perhaps just offer
>>>>>>>>>>> this
>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>>>> service handler -
>>>>>>>> references to type safe queries - as I
>>>>>>>>>>> think
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note, that at the moment
>>>>>>>> service handlers are scheduled
>>>>>>>>>>> for
>>>>>>>>>>>> CDI
>>>>>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>>>>>>> Jason Porter wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Somewhat. I
>>>>>>>> wouldn't really think of them as overrides,
>>>>>>>>>>> they,
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>>>> seem more like items to
>>>>>>>> do in addition to whatever the
>>>>>>>>>>>> original
>>>>>>>>>>>>>> impl
>>>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
>>>>>>>> seem more like super
>>>>>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>>>>>>> 19:23, "John D. Ament" <
>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>> concepts are very dissimilar.
>>>>>>>>>>> servicehandlers
>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>> delegates are more like overrides and
>>>>>>>>>>> need
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>> the method
>>>>>>>> signature.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>>>>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>>>> idea of ServiceHandlers are good, but,
>>>>>>>>>>> could
>>>>>>>>>>> we
>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>> delegates?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sent from my
>>>>>>>> iPhone
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mar 6,
>>>>>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>> don't think it's a hard requirement for it to be
>>>>>>>>>>> on an
>>>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> One of
>>>>>>>> the best use-cases we built at my job is
>>>>>>>>>>> using it
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
>>>>>>>> The JDBC bindings do work, but not pretty.
>>>>>>>>>>> we
>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>>>> a fairly
>>>>>>>> clean wrapper API, generic enough for
>>>>>>>>>>> binding
>>>>>>>>>>>>> in/out
>>>>>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Tue,
>>>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> actually I don't really see a real benefit. I just
>>>>>>>>>>> don't
>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>> grok
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Why
>>>>>>>> would one intercept an Interface and delegate
>>>>>>>>>>> the
>>>>>>>>>>>> calls
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>> could be neat for mocking, but there are
>>>>>>>>>>> better
>>>>>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> From: Gerhard Petracek
>>>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> if you have a lot of shared code, you can extract
>>>>>>>>>>> it
>>>>>>>>>>> in
>>>>>>>>>>>>> 1-n
>>>>>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> abstract class which is still easier than a new
>>>>>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> at least i haven't seen an use-case which really
>>>>>>>>>>> needed
>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>>>>>> with
>>>>>>>>>>>> adding
>>>>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>>>>>> boilerplate
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>>>> implement
>>>>>>>>>>> a
>>>>>>>>>>> bean
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>>>>>> instead?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>>>> Petracek
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> no -1 because there are
>>>>>>>> use-cases for it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>>>>>> cdi mechanisms
>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>>>> fine.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>>>>>> the subject of
>>>>>>>>>>>> ServiceHandler.
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> added 113 as a
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>>>>>> appropriate but not
>>>>>>>>>>> 100%
>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> (so please let
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> know if you think
>>>>>>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> feature in Solder that
>>>>>>>> allows you to define
>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> interceptor that
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> generic calls against
>>>>>>>> an injected interface.
>>>>>>>>>>> The
>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> is as follows:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> on an annotation that
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> be placed on the
>>>>>>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> interceptor would be
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> for calls against this
>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It's then up to the
>>>>>>>> application
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> annotations that go on
>>>>>>>> methods, as well as
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> interceptor itself
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> be invoked. The
>>>>>>>> feature for ServiceHandler
>>>>>>>>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> to provide the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> the type and then the
>>>>>>>> infrastructure
>>>>>>>>>>> required to
>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> the interceptor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> called. Existing
>>>>>>>> documentation of the
>>>>>>>>>>> feature:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>>>> ser
>>>>>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jason Porter
>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>> http://twitter.com/lightguardjp
>>>>>>>>>>
>>>>>>>>>> Software Engineer
>>>>>>>>>> Open Source Advocate
>>>>>>>>>>
>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
The problem I have is that now InvocationHandler is both an interface and
an @interface which will make it impossible for imports. I don't think
they should have the same name.
On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <pm...@redhat.com> wrote:
>
> On 20 Dec 2012, at 12:32, John D. Ament wrote:
>
> > All,
> >
> > So mostly ok from my perspective. One thing to note:
> >
> > @InvocationHandlerBinding
> > public @interface Repository {}
> >
> > @Repository
> > public interface MyRepository {
> > ...
> > }
> >
> > @Repository @InvocationHandler
> > public class MyInvocationHandler implements InvocationHandler {
> > ...
> > }
> >
> > Why do we have a @InvocationHandler here? Is it supposed to be
> > @InvocationHandlerBinding instead? If so, is it really needed here?
>
> No, it should be @InvocationHandler, it's analagous to @Interceptor. It's
> not 100% necessary as we already implement the interface, which is enough
> of the marker.
>
> >
> > Thinking about the implementation for this, I think this actually becomes
> > easier to use and easier to understand over the Solder solution. The
> > implementation of the InvocationHandler becomes a true CDI bean.
> >
> > Should DS support Interceptors and Decorators on
> > InvocationHandler beans?
> >
> > Do you mean the implementation class or the interface?
> >
> > John
> >
> >
> > On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> i'd rather say no because the idea is to ease "util" extension
> >> writing. that's clearly not intended to be full business beans IMO (at
> >> least for a first step)
> >>
> >> That's why i'd leave it as this for now
> >>
> >> wdyt?
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> >>> Mark refers to my call stack.
> >>>
> >>> Out of the box this call stack would exist just in OWB, because Weld
> >> would
> >>> not apply any Interceptors or Decorators...
> >>>
> >>> The question is: Should DS support Interceptors and Decorators on
> >>> InvocationHandler beans? My answer would be: yes, if our implementation
> >>> shall be a preview of CDI-110.
> >>> And that would make things complicated in the implementation...
> >>>
> >>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> >>> <rm...@gmail.com>:
> >>>
> >>>> is it an issue for servicehandler? i don't think so
> >>>>
> >>>> it is often used to get util classes dynamically created, it is rarely
> >>>> (i never saw it) decorated directly
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> Twitter: @rmannibucau
> >>>> Blog: http://rmannibucau.wordpress.com/
> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>> Github: https://github.com/rmannibucau
> >>>>
> >>>>
> >>>>
> >>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
> >>>>> we stumbled about this lately. It seems CDI only forces support for
> >>>>> interceptors and decorators for CDI-annotated classes, but not for
> >>>>> Bean<T> which get added via extensions nor even producer methods and
> >>>>> fields :/
> >>>>>
> >>>>>
> >>>>> Of course OWB does it, but it would be not portable...
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: Arne Limburg <ar...@openknowledge.de>
> >>>>>> To: "deltaspike-dev@incubator.apache.org"
> >>>>>> <de...@incubator.apache.org>
> >>>>>> Cc:
> >>>>>> Sent: Thursday, December 20, 2012 10:18 AM
> >>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>>> ServiceHandler
> >>>>>>
> >>>>>> T wo things about this: First: I don't like from the solder
> approach,
> >>>>>> because the interface is annotated instead of the implementation.
> >>>>>>
> >>>>>> Second, if we implement this we should conceptually make clear how
> it
> >>>>>> differentiates from Interceptors and Decorators. And personally I
> >> think
> >>>>>> this would work better with the InvocationHandler approach than with
> >> an
> >>>>>> approach that is very similar to interceptors.
> >>>>>>
> >>>>>> So +1 for an approach like this:
> >>>>>>
> >>>>>> @HandlesInvocationsOn(MyInterface.class)
> >>>>>> public class MyInvocationHandler implements InvocationHandler {
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>> Technically we would register a custom Bean for every found
> >>>>>> InvocationHandler with that annotation and take over the
> >>>>>> interceptor-bindings from the interfaceŠ
> >>>>>> So the invocation stack would be clear, too:
> >>>>>> First Interceptors,
> >>>>>> Second Decorators,
> >>>>>> Third InvocationHandler
> >>>>>>
> >>>>>> Wdyt?
> >>>>>>
> >>>>>> Arne
> >>>>>>
> >>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> >>>>>> <rm...@gmail.com>:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
> >>>>>>> part portable ans it should be fine
> >>>>>>>
> >>>>>>> Romain Manni-Bucau
> >>>>>>> Twitter: @rmannibucau
> >>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> >>>>>>>> At this point, I'd say just do it as is in solder.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> >>>>>>>> <jo...@gmail.com>wrote:
> >>>>>>>>
> >>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>>> Regarding the two open questions:
> >>>>>>>>>
> >>>>>>>>> 1) the approach (including the name/s) we agree on will be used
> >>>>>> also
> >>>>>>>>> for
> >>>>>>>>> cdi 1.1 (the only difference is the package)
> >>>>>>>>> 2) the eg has a different opinion about it ->
> >>>>>>>>>
> >>>>>>>>> It looks like the JSR's answer
> >>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>>>> is still unresolved - I'm not sure if we can get any further
> >>>>>> answer at
> >>>>>>>>> this
> >>>>>>>>> time. The last posts on the subject seem to discuss using
> >>>>>> something
> >>>>>>>>> along
> >>>>>>>>> the lines of an invocation handler, which I think would work
> well.
> >>>>>>>>> Since
> >>>>>>>>> we have some features coming up that are interested in having
> >>>>>> service
> >>>>>>>>> handlers available, do we
> >>>>>>>>>
> >>>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
> >>>>>>>>> 2. Push EG on a resolution
> >>>>>>>>> 3. Do it using invocation handlers.
> >>>>>>>>> 4. Do it some other way?
> >>>>>>>>>
> >>>>>>>>> John
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> hi john,
> >>>>>>>>>>
> >>>>>>>>>> as mentioned before we need the answers to the existing
> >>>>>> questions.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>> gerhard
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>>> All,
> >>>>>>>>>>>
> >>>>>>>>>>> I kind of let this one and the other drop off my radar, I
> >>>>>>>>> apologize.
> >>>>>>>>> it
> >>>>>>>>>>> looks like where we last left off, Gerhard was still
> >>>>>> requesting
> >>>>>>>>>> additional
> >>>>>>>>>>> comments from everyone. Any other feedback?
> >>>>>>>>>>>
> >>>>>>>>>>> John
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> hi george,
> >>>>>>>>>>>>
> >>>>>>>>>>>> thx for the information. i thought there might be at
> >>>>>> least some
> >>>>>>>>>>> additional
> >>>>>>>>>>>> answers/clarifications, since pete asked for them in
> >>>>>> several
> >>>>>>>>> comments.
> >>>>>>>>>>>> -> imo we should continue with them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> regards,
> >>>>>>>>>>>> gerhard
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2012/3/12 George Gastaldi
> >>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hello Gerhard,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
> >>>>>> old, but I
> >>>>>>>>> haven´t had
> >>>>>>>>>>> time
> >>>>>>>>>>>>> to work on it after that.
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> George
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
> >>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> hi george,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> thx for the link.
> >>>>>>>>>>>>>> i'm not sure if it is the latest state
> >>>>>> of your discussion
> >>>>>>>>> and/or
> >>>>>>>>>> draft
> >>>>>>>>>>>>>> (at least it's quite old already).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2012/3/7 George Gastaldi
> >>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi !
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +1 to #1. I also agree that the term
> >>>>>> "Service Handler" might
> >>>>>>>>> not
> >>>>>>>>> be
> >>>>>>>>>>> so
> >>>>>>>>>>>>>>> appropriate, so it should be discussed
> >>>>>> as well.
> >>>>>>>>>>>>>>> Here is the latest pull request with
> >>>>>> some comments from Pete
> >>>>>>>>> yet
> >>>>>>>>> to
> >>>>>>>>>>> be
> >>>>>>>>>>>>>>> reviewed:
> >>>>>> https://github.com/jboss/cdi/pull/28
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Agreed :-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> George is working on it for CDI
> >>>>>> 1.1. George, can you share
> >>>>>>>>> your
> >>>>>>>>>>>>>>> proposal
> >>>>>>>>>>>>>>>> so far?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
> >>>>>> Petracek wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> independent of my opinion
> >>>>>> about the feature (which is
> >>>>>>>>> still
> >>>>>>>>>> +0):
> >>>>>>>>>>>>>>>>> if it should be part of cdi
> >>>>>> 1.1, we have the following
> >>>>>>>>> options
> >>>>>>>>>>> imo:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1) the approach (including
> >>>>>> the name/s) we agree on will
> >>>>>>>>> be
> >>>>>>>>> used
> >>>>>>>>>>>> also
> >>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
> >>>>>> is the package)
> >>>>>>>>>>>>>>>>> 2) the eg has a different
> >>>>>> opinion about it ->
> >>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
> >>>>>> this discussion
> >>>>>>>>>>>>>>>>> 2b) we wait for the final
> >>>>>> version and just allow the same
> >>>>>>>>> with
> >>>>>>>>>>> cdi
> >>>>>>>>>>>>>>> 1.0
> >>>>>>>>>>>>>>>>> 3) if the eg doesn't
> >>>>>> agree on the idea, it should be
> >>>>>>>>> re-visited
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> deltaspike (if we really need
> >>>>>> it)
> >>>>>>>>>>>>>>>>> 4) we agree on it independent
> >>>>>> of the result in cdi 1.1
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
> >>>>>> #4
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
> >>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I'm not sure what you
> >>>>>> mean by a "super interceptor",
> >>>>>>>>> but if
> >>>>>>>>>> you
> >>>>>>>>>>>>>>> mean it
> >>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>> in "super man"
> >>>>>> (something better than an interceptor),
> >>>>>>>>> then
> >>>>>>>>> I
> >>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>> disagree, it's
> >>>>>> actually a specialised form of
> >>>>>>>>> interceptor.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The best use case I know
> >>>>>> of is the one John mentions -
> >>>>>>>>>> creating
> >>>>>>>>>>>> type
> >>>>>>>>>>>>>>>> safe
> >>>>>>>>>>>>>>>>>> references to queries:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @QueryService
> >>>>>>>>>>>>>>>>>> interface UserQuery {
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>> from User u")
> >>>>>>>>>>>>>>>>>> public List<User>
> >>>>>> getAllUsers();
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @Query("select u
> >>>>>> from User u order by u.name")
> >>>>>>>>>>>>>>>>>> public List<User>
> >>>>>> getAllUsersSortedByName();
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Now, it may be the case
> >>>>>> that there aren't any other use
> >>>>>>>>> cases
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>>> service
> >>>>>>>>>>>>>>>>>> handlers, in which case
> >>>>>> we should perhaps just offer
> >>>>>>>>> this
> >>>>>>>>>>>> particular
> >>>>>>>>>>>>>>>>>> service handler -
> >>>>>> references to type safe queries - as I
> >>>>>>>>> think
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>> extremely powerful idea.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Note, that at the moment
> >>>>>> service handlers are scheduled
> >>>>>>>>> for
> >>>>>>>>>> CDI
> >>>>>>>>>>>> 1.1.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
> >>>>>> Jason Porter wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Somewhat. I
> >>>>>> wouldn't really think of them as overrides,
> >>>>>>>>> they,
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>> me,
> >>>>>>>>>>>>>>>>>> seem more like items to
> >>>>>> do in addition to whatever the
> >>>>>>>>>> original
> >>>>>>>>>>>> impl
> >>>>>>>>>>>>>>>> does.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ServiceHandlers to me
> >>>>>> seem more like super
> >>>>>>>>> interceptors.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Sent from my iPhone
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
> >>>>>> 19:23, "John D. Ament" <
> >>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> @jason
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think the
> >>>>>> concepts are very dissimilar.
> >>>>>>>>> servicehandlers
> >>>>>>>>>>>> create
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> implementation.
> >>>>>> delegates are more like overrides and
> >>>>>>>>> need
> >>>>>>>>>> to
> >>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>> the method
> >>>>>> signature.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
> >>>>>> 2012 at 9:17 PM, Jason Porter <
> >>>>>>>>>>>>>>> lightguard.jp@gmail.com
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I think the
> >>>>>> idea of ServiceHandlers are good, but,
> >>>>>>>>> could
> >>>>>>>>> we
> >>>>>>>>>>> not
> >>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>> with
> >>>>>> delegates?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Sent from my
> >>>>>> iPhone
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Mar 6,
> >>>>>> 2012, at 19:05, "John D. Ament" <
> >>>>>>>>>>>>>>> john.d.ament@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> @mark
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I
> >>>>>> don't think it's a hard requirement for it to be
> >>>>>>>>> on an
> >>>>>>>>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> One of
> >>>>>> the best use-cases we built at my job is
> >>>>>>>>> using it
> >>>>>>>>>> for
> >>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>>>>> PL/SQL.
> >>>>>> The JDBC bindings do work, but not pretty.
> >>>>>>>>> we
> >>>>>>>>>> were
> >>>>>>>>>>>>>>> able to
> >>>>>>>>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>>>>>> a fairly
> >>>>>> clean wrapper API, generic enough for
> >>>>>>>>> binding
> >>>>>>>>>>> in/out
> >>>>>>>>>>>>>>>>>> parameters.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> JOhn
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Tue,
> >>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>>>>>>>>>>>>>> struberg@yahoo.de>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> actually I don't really see a real benefit. I just
> >>>>>>>>> don't
> >>>>>>>>>>> yet
> >>>>>>>>>>>>>>> grok
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>>>> case
> >>>>>> for real world projects.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why
> >>>>>> would one intercept an Interface and delegate
> >>>>>>>>> the
> >>>>>>>>>> calls
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> handler?
> >>>>>>>>>>>>>>>>>>>>>>> This
> >>>>>> could be neat for mocking, but there are
> >>>>>>>>> better
> >>>>>>>>>>>>>>> frameworks for
> >>>>>>>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> thus
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -0.2
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> LieGrue,
> >>>>>>>>>>>>>>>>>>>>>>> strub
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>> Original Message -----
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> From: Gerhard Petracek
> >>>>>>>>> <ge...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> Cc:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> >>>>>>>>>> Discuss
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>> ServiceHandler
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> if you have a lot of shared code, you can extract
> >>>>>>>>> it
> >>>>>>>>> in
> >>>>>>>>>>> 1-n
> >>>>>>>>>>>>>>>>>> method/s or
> >>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> abstract class which is still easier than a new
> >>>>>>>>> concept.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> at least i haven't seen an use-case which really
> >>>>>>>>> needed
> >>>>>>>>>>> it.
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> reason for a +0 (which still means that i'm ok
> >>>>>>>>> with
> >>>>>>>>>> adding
> >>>>>>>>>>>>>>> it).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> regards,
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> gerhard
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So, you mean just write a bean with all the
> >>>>>>>>> boilerplate
> >>>>>>>>>>>> code
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> it?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> hi pete,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> instead of the interface you can just
> >>>>>> implement
> >>>>>>>>> a
> >>>>>>>>> bean
> >>>>>>>>>>>> which
> >>>>>>>>>>>>>>>> does
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> same.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>>>>> <pm...@redhat.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What CDI mechanism would you use
> >>>>>> instead?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> >>>>>> Petracek
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> no -1 because there are
> >>>>>> use-cases for it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> no +1 because i would use std.
> >>>>>> cdi mechanisms
> >>>>>>>>>> instead.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> >>>>>>>>>> gerhard.petracek@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> >>>>>> fine.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> >>>>>>>>> <jo...@gmail.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi All
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I wanted to bring up
> >>>>>> the subject of
> >>>>>>>>>> ServiceHandler.
> >>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> added 113 as a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> child
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> >>>>>> appropriate but not
> >>>>>>>>> 100%
> >>>>>>>>>>> sure
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> (so please let
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> me
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> know if you think
> >>>>>> it's not appropriate as a
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> child). ServiceHandler
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> feature in Solder that
> >>>>>> allows you to define
> >>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> interceptor that
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> manages
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> generic calls against
> >>>>>> an injected interface.
> >>>>>>>>> The
> >>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> is as follows:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>>>> placed
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> on an annotation that
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> be placed on the
> >>>>>> interface. Indicates what
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> interceptor would be
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> invoked
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> for calls against this
> >>>>>> interface.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It's then up to the
> >>>>>> application
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> developer/framework author to define
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> annotations that go on
> >>>>>> methods, as well as
> >>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> interceptor itself
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> be invoked. The
> >>>>>> feature for ServiceHandler
> >>>>>>>>> would
> >>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> to provide the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> API of
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> the type and then the
> >>>>>> infrastructure
> >>>>>>>>> required to
> >>>>>>>>>>> make
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> the interceptor
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> called. Existing
> >>>>>> documentation of the
> >>>>>>>>> feature:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>>> ser
> >>>>>>>>> vicehandler.html
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> john
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jason Porter
> >>>>>>>> http://lightguard-jp.blogspot.com
> >>>>>>>> http://twitter.com/lightguardjp
> >>>>>>>>
> >>>>>>>> Software Engineer
> >>>>>>>> Open Source Advocate
> >>>>>>>>
> >>>>>>>> PGP key id: 926CCFF5
> >>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>>>
> >>>
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
On 20 Dec 2012, at 12:32, John D. Ament wrote:
> All,
>
> So mostly ok from my perspective. One thing to note:
>
> @InvocationHandlerBinding
> public @interface Repository {}
>
> @Repository
> public interface MyRepository {
> ...
> }
>
> @Repository @InvocationHandler
> public class MyInvocationHandler implements InvocationHandler {
> ...
> }
>
> Why do we have a @InvocationHandler here? Is it supposed to be
> @InvocationHandlerBinding instead? If so, is it really needed here?
No, it should be @InvocationHandler, it's analagous to @Interceptor. It's not 100% necessary as we already implement the interface, which is enough of the marker.
>
> Thinking about the implementation for this, I think this actually becomes
> easier to use and easier to understand over the Solder solution. The
> implementation of the InvocationHandler becomes a true CDI bean.
>
> Should DS support Interceptors and Decorators on
> InvocationHandler beans?
>
> Do you mean the implementation class or the interface?
>
> John
>
>
> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> i'd rather say no because the idea is to ease "util" extension
>> writing. that's clearly not intended to be full business beans IMO (at
>> least for a first step)
>>
>> That's why i'd leave it as this for now
>>
>> wdyt?
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>> Mark refers to my call stack.
>>>
>>> Out of the box this call stack would exist just in OWB, because Weld
>> would
>>> not apply any Interceptors or Decorators...
>>>
>>> The question is: Should DS support Interceptors and Decorators on
>>> InvocationHandler beans? My answer would be: yes, if our implementation
>>> shall be a preview of CDI-110.
>>> And that would make things complicated in the implementation...
>>>
>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
>>> <rm...@gmail.com>:
>>>
>>>> is it an issue for servicehandler? i don't think so
>>>>
>>>> it is often used to get util classes dynamically created, it is rarely
>>>> (i never saw it) decorated directly
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Mark Struberg <st...@yahoo.de>:
>>>>> we stumbled about this lately. It seems CDI only forces support for
>>>>> interceptors and decorators for CDI-annotated classes, but not for
>>>>> Bean<T> which get added via extensions nor even producer methods and
>>>>> fields :/
>>>>>
>>>>>
>>>>> Of course OWB does it, but it would be not portable...
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Arne Limburg <ar...@openknowledge.de>
>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>> <de...@incubator.apache.org>
>>>>>> Cc:
>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>>> ServiceHandler
>>>>>>
>>>>>> T wo things about this: First: I don't like from the solder approach,
>>>>>> because the interface is annotated instead of the implementation.
>>>>>>
>>>>>> Second, if we implement this we should conceptually make clear how it
>>>>>> differentiates from Interceptors and Decorators. And personally I
>> think
>>>>>> this would work better with the InvocationHandler approach than with
>> an
>>>>>> approach that is very similar to interceptors.
>>>>>>
>>>>>> So +1 for an approach like this:
>>>>>>
>>>>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>> public class MyInvocationHandler implements InvocationHandler {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> Technically we would register a custom Bean for every found
>>>>>> InvocationHandler with that annotation and take over the
>>>>>> interceptor-bindings from the interfaceŠ
>>>>>> So the invocation stack would be clear, too:
>>>>>> First Interceptors,
>>>>>> Second Decorators,
>>>>>> Third InvocationHandler
>>>>>>
>>>>>> Wdyt?
>>>>>>
>>>>>> Arne
>>>>>>
>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>>>> <rm...@gmail.com>:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>>>> part portable ans it should be fine
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>> <jo...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Regarding the two open questions:
>>>>>>>>>
>>>>>>>>> 1) the approach (including the name/s) we agree on will be used
>>>>>> also
>>>>>>>>> for
>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>
>>>>>>>>> It looks like the JSR's answer
>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>> is still unresolved - I'm not sure if we can get any further
>>>>>> answer at
>>>>>>>>> this
>>>>>>>>> time. The last posts on the subject seem to discuss using
>>>>>> something
>>>>>>>>> along
>>>>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>>>>> Since
>>>>>>>>> we have some features coming up that are interested in having
>>>>>> service
>>>>>>>>> handlers available, do we
>>>>>>>>>
>>>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>>>> 2. Push EG on a resolution
>>>>>>>>> 3. Do it using invocation handlers.
>>>>>>>>> 4. Do it some other way?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> hi john,
>>>>>>>>>>
>>>>>>>>>> as mentioned before we need the answers to the existing
>>>>>> questions.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> All,
>>>>>>>>>>>
>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>>>>> apologize.
>>>>>>>>> it
>>>>>>>>>>> looks like where we last left off, Gerhard was still
>>>>>> requesting
>>>>>>>>>> additional
>>>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> hi george,
>>>>>>>>>>>>
>>>>>>>>>>>> thx for the information. i thought there might be at
>>>>>> least some
>>>>>>>>>>> additional
>>>>>>>>>>>> answers/clarifications, since pete asked for them in
>>>>>> several
>>>>>>>>> comments.
>>>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/12 George Gastaldi
>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>>>>> old, but I
>>>>>>>>> haven´t had
>>>>>>>>>>> time
>>>>>>>>>>>>> to work on it after that.
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> George
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>>>> i'm not sure if it is the latest state
>>>>>> of your discussion
>>>>>>>>> and/or
>>>>>>>>>> draft
>>>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
>>>>>> "Service Handler" might
>>>>>>>>> not
>>>>>>>>> be
>>>>>>>>>>> so
>>>>>>>>>>>>>>> appropriate, so it should be discussed
>>>>>> as well.
>>>>>>>>>>>>>>> Here is the latest pull request with
>>>>>> some comments from Pete
>>>>>>>>> yet
>>>>>>>>> to
>>>>>>>>>>> be
>>>>>>>>>>>>>>> reviewed:
>>>>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> George is working on it for CDI
>>>>>> 1.1. George, can you share
>>>>>>>>> your
>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>> Petracek wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> independent of my opinion
>>>>>> about the feature (which is
>>>>>>>>> still
>>>>>>>>>> +0):
>>>>>>>>>>>>>>>>> if it should be part of cdi
>>>>>> 1.1, we have the following
>>>>>>>>> options
>>>>>>>>>>> imo:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) the approach (including
>>>>>> the name/s) we agree on will
>>>>>>>>> be
>>>>>>>>> used
>>>>>>>>>>>> also
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>>>>> is the package)
>>>>>>>>>>>>>>>>> 2) the eg has a different
>>>>>> opinion about it ->
>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>>>>> this discussion
>>>>>>>>>>>>>>>>> 2b) we wait for the final
>>>>>> version and just allow the same
>>>>>>>>> with
>>>>>>>>>>> cdi
>>>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>>>> 3) if the eg doesn't
>>>>>> agree on the idea, it should be
>>>>>>>>> re-visited
>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> deltaspike (if we really need
>>>>>> it)
>>>>>>>>>>>>>>>>> 4) we agree on it independent
>>>>>> of the result in cdi 1.1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>>>>> #4
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm not sure what you
>>>>>> mean by a "super interceptor",
>>>>>>>>> but if
>>>>>>>>>> you
>>>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>> in "super man"
>>>>>> (something better than an interceptor),
>>>>>>>>> then
>>>>>>>>> I
>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> disagree, it's
>>>>>> actually a specialised form of
>>>>>>>>> interceptor.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The best use case I know
>>>>>> of is the one John mentions -
>>>>>>>>>> creating
>>>>>>>>>>>> type
>>>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>> from User u")
>>>>>>>>>>>>>>>>>> public List<User>
>>>>>> getAllUsers();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>> from User u order by u.name")
>>>>>>>>>>>>>>>>>> public List<User>
>>>>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now, it may be the case
>>>>>> that there aren't any other use
>>>>>>>>> cases
>>>>>>>>>>> for
>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>> handlers, in which case
>>>>>> we should perhaps just offer
>>>>>>>>> this
>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>> service handler -
>>>>>> references to type safe queries - as I
>>>>>>>>> think
>>>>>>>>>>>> this
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note, that at the moment
>>>>>> service handlers are scheduled
>>>>>>>>> for
>>>>>>>>>> CDI
>>>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>>>>> Jason Porter wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Somewhat. I
>>>>>> wouldn't really think of them as overrides,
>>>>>>>>> they,
>>>>>>>>>>> to
>>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>> seem more like items to
>>>>>> do in addition to whatever the
>>>>>>>>>> original
>>>>>>>>>>>> impl
>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
>>>>>> seem more like super
>>>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>>>>> 19:23, "John D. Ament" <
>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think the
>>>>>> concepts are very dissimilar.
>>>>>>>>> servicehandlers
>>>>>>>>>>>> create
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>> delegates are more like overrides and
>>>>>>>>> need
>>>>>>>>>> to
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>> the method
>>>>>> signature.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>> idea of ServiceHandlers are good, but,
>>>>>>>>> could
>>>>>>>>> we
>>>>>>>>>>> not
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> with
>>>>>> delegates?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sent from my
>>>>>> iPhone
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mar 6,
>>>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I
>>>>>> don't think it's a hard requirement for it to be
>>>>>>>>> on an
>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> One of
>>>>>> the best use-cases we built at my job is
>>>>>>>>> using it
>>>>>>>>>> for
>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
>>>>>> The JDBC bindings do work, but not pretty.
>>>>>>>>> we
>>>>>>>>>> were
>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>> a fairly
>>>>>> clean wrapper API, generic enough for
>>>>>>>>> binding
>>>>>>>>>>> in/out
>>>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue,
>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> actually I don't really see a real benefit. I just
>>>>>>>>> don't
>>>>>>>>>>> yet
>>>>>>>>>>>>>>> grok
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why
>>>>>> would one intercept an Interface and delegate
>>>>>>>>> the
>>>>>>>>>> calls
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>>>> This
>>>>>> could be neat for mocking, but there are
>>>>>>>>> better
>>>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> From: Gerhard Petracek
>>>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>>>>
>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> if you have a lot of shared code, you can extract
>>>>>>>>> it
>>>>>>>>> in
>>>>>>>>>>> 1-n
>>>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> abstract class which is still easier than a new
>>>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> at least i haven't seen an use-case which really
>>>>>>>>> needed
>>>>>>>>>>> it.
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>>>> with
>>>>>>>>>> adding
>>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>>>> boilerplate
>>>>>>>>>>>> code
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>> implement
>>>>>>>>> a
>>>>>>>>> bean
>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>>>> instead?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>> Petracek
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> no -1 because there are
>>>>>> use-cases for it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>>>> cdi mechanisms
>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>> fine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>>>> the subject of
>>>>>>>>>> ServiceHandler.
>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> added 113 as a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>>>> appropriate but not
>>>>>>>>> 100%
>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> (so please let
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> know if you think
>>>>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> feature in Solder that
>>>>>> allows you to define
>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> generic calls against
>>>>>> an injected interface.
>>>>>>>>> The
>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> is as follows:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -
>>>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> on an annotation that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be placed on the
>>>>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor would be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> for calls against this
>>>>>> interface.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It's then up to the
>>>>>> application
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> annotations that go on
>>>>>> methods, as well as
>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor itself
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be invoked. The
>>>>>> feature for ServiceHandler
>>>>>>>>> would
>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> to provide the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> the type and then the
>>>>>> infrastructure
>>>>>>>>> required to
>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> the interceptor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> called. Existing
>>>>>> documentation of the
>>>>>>>>> feature:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>> ser
>>>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jason Porter
>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>> http://twitter.com/lightguardjp
>>>>>>>>
>>>>>>>> Software Engineer
>>>>>>>> Open Source Advocate
>>>>>>>>
>>>>>>>> PGP key id: 926CCFF5
>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>
>>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
All,
So mostly ok from my perspective. One thing to note:
@InvocationHandlerBinding
public @interface Repository {}
@Repository
public interface MyRepository {
...
}
@Repository @InvocationHandler
public class MyInvocationHandler implements InvocationHandler {
...
}
Why do we have a @InvocationHandler here? Is it supposed to be
@InvocationHandlerBinding instead? If so, is it really needed here?
Thinking about the implementation for this, I think this actually becomes
easier to use and easier to understand over the Solder solution. The
implementation of the InvocationHandler becomes a true CDI bean.
Should DS support Interceptors and Decorators on
InvocationHandler beans?
Do you mean the implementation class or the interface?
John
On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> i'd rather say no because the idea is to ease "util" extension
> writing. that's clearly not intended to be full business beans IMO (at
> least for a first step)
>
> That's why i'd leave it as this for now
>
> wdyt?
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> > Mark refers to my call stack.
> >
> > Out of the box this call stack would exist just in OWB, because Weld
> would
> > not apply any Interceptors or Decorators...
> >
> > The question is: Should DS support Interceptors and Decorators on
> > InvocationHandler beans? My answer would be: yes, if our implementation
> > shall be a preview of CDI-110.
> > And that would make things complicated in the implementation...
> >
> > Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> > <rm...@gmail.com>:
> >
> >>is it an issue for servicehandler? i don't think so
> >>
> >>it is often used to get util classes dynamically created, it is rarely
> >>(i never saw it) decorated directly
> >>
> >>
> >>Romain Manni-Bucau
> >>Twitter: @rmannibucau
> >>Blog: http://rmannibucau.wordpress.com/
> >>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >>2012/12/20 Mark Struberg <st...@yahoo.de>:
> >>> we stumbled about this lately. It seems CDI only forces support for
> >>>interceptors and decorators for CDI-annotated classes, but not for
> >>>Bean<T> which get added via extensions nor even producer methods and
> >>>fields :/
> >>>
> >>>
> >>> Of course OWB does it, but it would be not portable...
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: Arne Limburg <ar...@openknowledge.de>
> >>>> To: "deltaspike-dev@incubator.apache.org"
> >>>><de...@incubator.apache.org>
> >>>> Cc:
> >>>> Sent: Thursday, December 20, 2012 10:18 AM
> >>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>ServiceHandler
> >>>>
> >>>>T wo things about this: First: I don't like from the solder approach,
> >>>> because the interface is annotated instead of the implementation.
> >>>>
> >>>> Second, if we implement this we should conceptually make clear how it
> >>>> differentiates from Interceptors and Decorators. And personally I
> think
> >>>> this would work better with the InvocationHandler approach than with
> an
> >>>> approach that is very similar to interceptors.
> >>>>
> >>>> So +1 for an approach like this:
> >>>>
> >>>> @HandlesInvocationsOn(MyInterface.class)
> >>>> public class MyInvocationHandler implements InvocationHandler {
> >>>> ...
> >>>> }
> >>>>
> >>>> Technically we would register a custom Bean for every found
> >>>> InvocationHandler with that annotation and take over the
> >>>> interceptor-bindings from the interfaceŠ
> >>>> So the invocation stack would be clear, too:
> >>>> First Interceptors,
> >>>> Second Decorators,
> >>>> Third InvocationHandler
> >>>>
> >>>> Wdyt?
> >>>>
> >>>> Arne
> >>>>
> >>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> >>>> <rm...@gmail.com>:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
> >>>>> part portable ans it should be fine
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> Twitter: @rmannibucau
> >>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>> Github: https://github.com/rmannibucau
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
> >>>>>> At this point, I'd say just do it as is in solder.
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> >>>>>> <jo...@gmail.com>wrote:
> >>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> Regarding the two open questions:
> >>>>>>>
> >>>>>>> 1) the approach (including the name/s) we agree on will be used
> >>>> also
> >>>>>>> for
> >>>>>>> cdi 1.1 (the only difference is the package)
> >>>>>>> 2) the eg has a different opinion about it ->
> >>>>>>>
> >>>>>>> It looks like the JSR's answer
> >>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>> is still unresolved - I'm not sure if we can get any further
> >>>> answer at
> >>>>>>> this
> >>>>>>> time. The last posts on the subject seem to discuss using
> >>>> something
> >>>>>>> along
> >>>>>>> the lines of an invocation handler, which I think would work well.
> >>>>>>> Since
> >>>>>>> we have some features coming up that are interested in having
> >>>> service
> >>>>>>> handlers available, do we
> >>>>>>>
> >>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
> >>>>>>> 2. Push EG on a resolution
> >>>>>>> 3. Do it using invocation handlers.
> >>>>>>> 4. Do it some other way?
> >>>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>> gerhard.petracek@gmail.com
> >>>>>>> > wrote:
> >>>>>>>
> >>>>>>> > hi john,
> >>>>>>> >
> >>>>>>> > as mentioned before we need the answers to the existing
> >>>> questions.
> >>>>>>> >
> >>>>>>> > regards,
> >>>>>>> > gerhard
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
> >>>>>>> >
> >>>>>>> > > All,
> >>>>>>> > >
> >>>>>>> > > I kind of let this one and the other drop off my radar, I
> >>>>>>> apologize.
> >>>>>>> it
> >>>>>>> > > looks like where we last left off, Gerhard was still
> >>>> requesting
> >>>>>>> > additional
> >>>>>>> > > comments from everyone. Any other feedback?
> >>>>>>> > >
> >>>>>>> > > John
> >>>>>>> > >
> >>>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>> > > gerhard.petracek@gmail.com> wrote:
> >>>>>>> > >
> >>>>>>> > > > hi george,
> >>>>>>> > > >
> >>>>>>> > > > thx for the information. i thought there might be at
> >>>> least some
> >>>>>>> > > additional
> >>>>>>> > > > answers/clarifications, since pete asked for them in
> >>>> several
> >>>>>>> comments.
> >>>>>>> > > > -> imo we should continue with them.
> >>>>>>> > > >
> >>>>>>> > > > regards,
> >>>>>>> > > > gerhard
> >>>>>>> > > >
> >>>>>>> > > >
> >>>>>>> > > >
> >>>>>>> > > > 2012/3/12 George Gastaldi
> >>>> <ge...@gmail.com>
> >>>>>>> > > >
> >>>>>>> > > > > Hello Gerhard,
> >>>>>>> > > > >
> >>>>>>> > > > > Yeah, it´s the last state. I know it´s quite
> >>>> old, but I
> >>>>>>> haven´t had
> >>>>>>> > > time
> >>>>>>> > > > > to work on it after that.
> >>>>>>> > > > > Regards,
> >>>>>>> > > > >
> >>>>>>> > > > > George
> >>>>>>> > > > >
> >>>>>>> > > > >
> >>>>>>> > > > > 2012/3/12 Gerhard Petracek
> >>>> <ge...@gmail.com>
> >>>>>>> > > > >
> >>>>>>> > > > >> hi george,
> >>>>>>> > > > >>
> >>>>>>> > > > >> thx for the link.
> >>>>>>> > > > >> i'm not sure if it is the latest state
> >>>> of your discussion
> >>>>>>> and/or
> >>>>>>> > draft
> >>>>>>> > > > >> (at least it's quite old already).
> >>>>>>> > > > >>
> >>>>>>> > > > >> regards,
> >>>>>>> > > > >> gerhard
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >> 2012/3/7 George Gastaldi
> >>>> <ge...@gmail.com>
> >>>>>>> > > > >>
> >>>>>>> > > > >>> Hi !
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> +1 to #1. I also agree that the term
> >>>> "Service Handler" might
> >>>>>>> not
> >>>>>>> be
> >>>>>>> > > so
> >>>>>>> > > > >>> appropriate, so it should be discussed
> >>>> as well.
> >>>>>>> > > > >>> Here is the latest pull request with
> >>>> some comments from Pete
> >>>>>>> yet
> >>>>>>> to
> >>>>>>> > > be
> >>>>>>> > > > >>> reviewed:
> >>>> https://github.com/jboss/cdi/pull/28
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> 2012/3/7 Pete Muir
> >>>> <pm...@redhat.com>
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> > Agreed :-)
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > George is working on it for CDI
> >>>> 1.1. George, can you share
> >>>>>>> your
> >>>>>>> > > > >>> proposal
> >>>>>>> > > > >>> > so far?
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
> >>>> Petracek wrote:
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > > hi pete,
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > independent of my opinion
> >>>> about the feature (which is
> >>>>>>> still
> >>>>>>> > +0):
> >>>>>>> > > > >>> > > if it should be part of cdi
> >>>> 1.1, we have the following
> >>>>>>> options
> >>>>>>> > > imo:
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 1) the approach (including
> >>>> the name/s) we agree on will
> >>>>>>> be
> >>>>>>> used
> >>>>>>> > > > also
> >>>>>>> > > > >>> for
> >>>>>>> > > > >>> > > cdi 1.1 (the only difference
> >>>> is the package)
> >>>>>>> > > > >>> > > 2) the eg has a different
> >>>> opinion about it ->
> >>>>>>> > > > >>> > > 2a) the rest of the eg joins
> >>>> this discussion
> >>>>>>> > > > >>> > > 2b) we wait for the final
> >>>> version and just allow the same
> >>>>>>> with
> >>>>>>> > > cdi
> >>>>>>> > > > >>> 1.0
> >>>>>>> > > > >>> > > 3) if the eg doesn't
> >>>> agree on the idea, it should be
> >>>>>>> re-visited
> >>>>>>> > > for
> >>>>>>> > > > >>> > > deltaspike (if we really need
> >>>> it)
> >>>>>>> > > > >>> > > 4) we agree on it independent
> >>>> of the result in cdi 1.1
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 1-3 is ok for me but -1 for
> >>>> #4
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > regards,
> >>>>>>> > > > >>> > > gerhard
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 2012/3/7 Pete Muir
> >>>> <pm...@redhat.com>
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >> I'm not sure what you
> >>>> mean by a "super interceptor",
> >>>>>>> but if
> >>>>>>> > you
> >>>>>>> > > > >>> mean it
> >>>>>>> > > > >>> > as
> >>>>>>> > > > >>> > >> in "super man"
> >>>> (something better than an interceptor),
> >>>>>>> then
> >>>>>>> I
> >>>>>>> > > > would
> >>>>>>> > > > >>> > >> disagree, it's
> >>>> actually a specialised form of
> >>>>>>> interceptor.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> The best use case I know
> >>>> of is the one John mentions -
> >>>>>>> > creating
> >>>>>>> > > > type
> >>>>>>> > > > >>> > safe
> >>>>>>> > > > >>> > >> references to queries:
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @QueryService
> >>>>>>> > > > >>> > >> interface UserQuery {
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @Query("select u
> >>>> from User u")
> >>>>>>> > > > >>> > >> public List<User>
> >>>> getAllUsers();
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @Query("select u
> >>>> from User u order by u.name")
> >>>>>>> > > > >>> > >> public List<User>
> >>>> getAllUsersSortedByName();
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> }
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> Now, it may be the case
> >>>> that there aren't any other use
> >>>>>>> cases
> >>>>>>> > > for
> >>>>>>> > > > >>> > service
> >>>>>>> > > > >>> > >> handlers, in which case
> >>>> we should perhaps just offer
> >>>>>>> this
> >>>>>>> > > > particular
> >>>>>>> > > > >>> > >> service handler -
> >>>> references to type safe queries - as I
> >>>>>>> think
> >>>>>>> > > > this
> >>>>>>> > > > >>> is
> >>>>>>> > > > >>> > an
> >>>>>>> > > > >>> > >> extremely powerful idea.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> Note, that at the moment
> >>>> service handlers are scheduled
> >>>>>>> for
> >>>>>>> > CDI
> >>>>>>> > > > 1.1.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
> >>>> Jason Porter wrote:
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>> Somewhat. I
> >>>> wouldn't really think of them as overrides,
> >>>>>>> they,
> >>>>>>> > > to
> >>>>>>> > > > >>> me,
> >>>>>>> > > > >>> > >> seem more like items to
> >>>> do in addition to whatever the
> >>>>>>> > original
> >>>>>>> > > > impl
> >>>>>>> > > > >>> > does.
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> ServiceHandlers to me
> >>>> seem more like super
> >>>>>>> interceptors.
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> Sent from my iPhone
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> On Mar 6, 2012, at
> >>>> 19:23, "John D. Ament" <
> >>>>>>> > > > john.d.ament@gmail.com>
> >>>>>>> > > > >>> > >> wrote:
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>>> @jason
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>> I think the
> >>>> concepts are very dissimilar.
> >>>>>>> servicehandlers
> >>>>>>> > > > create
> >>>>>>> > > > >>> the
> >>>>>>> > > > >>> > >>>> implementation.
> >>>> delegates are more like overrides and
> >>>>>>> need
> >>>>>>> > to
> >>>>>>> > > > >>> know
> >>>>>>> > > > >>> > >> about
> >>>>>>> > > > >>> > >>>> the method
> >>>> signature.
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>> On Tue, Mar 6,
> >>>> 2012 at 9:17 PM, Jason Porter <
> >>>>>>> > > > >>> lightguard.jp@gmail.com
> >>>>>>> > > > >>> > >>> wrote:
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>>> I think the
> >>>> idea of ServiceHandlers are good, but,
> >>>>>>> could
> >>>>>>> we
> >>>>>>> > > not
> >>>>>>> > > > >>> do
> >>>>>>> > > > >>> > this
> >>>>>>> > > > >>> > >>>>> with
> >>>> delegates?
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>> Sent from my
> >>>> iPhone
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>> On Mar 6,
> >>>> 2012, at 19:05, "John D. Ament" <
> >>>>>>> > > > >>> john.d.ament@gmail.com>
> >>>>>>> > > > >>> > >> wrote:
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>>> @mark
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> I
> >>>> don't think it's a hard requirement for it to be
> >>>>>>> on an
> >>>>>>> > > > >>> interface.
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> One of
> >>>> the best use-cases we built at my job is
> >>>>>>> using it
> >>>>>>> > for
> >>>>>>> > > > >>> calling
> >>>>>>> > > > >>> > >>>>>> PL/SQL.
> >>>> The JDBC bindings do work, but not pretty.
> >>>>>>> we
> >>>>>>> > were
> >>>>>>> > > > >>> able to
> >>>>>>> > > > >>> > >>>>> create
> >>>>>>> > > > >>> > >>>>>> a fairly
> >>>> clean wrapper API, generic enough for
> >>>>>>> binding
> >>>>>>> > > in/out
> >>>>>>> > > > >>> > >> parameters.
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> JOhn
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> On Tue,
> >>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>>>>>> > > > >>> struberg@yahoo.de>
> >>>>>>> > > > >>> > >>>>> wrote:
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>> actually I don't really see a real benefit. I just
> >>>>>>> don't
> >>>>>>> > > yet
> >>>>>>> > > > >>> grok
> >>>>>>> > > > >>> > the
> >>>>>>> > > > >>> > >>>>> use
> >>>>>>> > > > >>> > >>>>>>> case
> >>>> for real world projects.
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> Why
> >>>> would one intercept an Interface and delegate
> >>>>>>> the
> >>>>>>> > calls
> >>>>>>> > > > to
> >>>>>>> > > > >>> a
> >>>>>>> > > > >>> > >> method
> >>>>>>> > > > >>> > >>>>>>>
> >>>> handler?
> >>>>>>> > > > >>> > >>>>>>> This
> >>>> could be neat for mocking, but there are
> >>>>>>> better
> >>>>>>> > > > >>> frameworks for
> >>>>>>> > > > >>> > >>>>> that.
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> thus
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> -0.2
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>> LieGrue,
> >>>>>>> > > > >>> > >>>>>>> strub
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> -----
> >>>> Original Message -----
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> From: Gerhard Petracek
> >>>>>>> <ge...@gmail.com>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Cc:
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> >>>>>>> > Discuss
> >>>>>>> > > > >>> > >>>>>
> >>>> ServiceHandler
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> if you have a lot of shared code, you can extract
> >>>>>>> it
> >>>>>>> in
> >>>>>>> > > 1-n
> >>>>>>> > > > >>> > >> method/s or
> >>>>>>> > > > >>> > >>>>>>> an
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> abstract class which is still easier than a new
> >>>>>>> concept.
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> at least i haven't seen an use-case which really
> >>>>>>> needed
> >>>>>>> > > it.
> >>>>>>> > > > >>> that
> >>>>>>> > > > >>> > was
> >>>>>>> > > > >>> > >>>>> the
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> reason for a +0 (which still means that i'm ok
> >>>>>>> with
> >>>>>>> > adding
> >>>>>>> > > > >>> it).
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> regards,
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> gerhard
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> So, you mean just write a bean with all the
> >>>>>>> boilerplate
> >>>>>>> > > > code
> >>>>>>> > > > >>> in
> >>>>>>> > > > >>> > it?
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>> wrote:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> hi pete,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> instead of the interface you can just
> >>>> implement
> >>>>>>> a
> >>>>>>> bean
> >>>>>>> > > > which
> >>>>>>> > > > >>> > does
> >>>>>>> > > > >>> > >> the
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> same.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>>> <pm...@redhat.com>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> What CDI mechanism would you use
> >>>> instead?
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> >>>> Petracek
> >>>>>>> wrote:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> +0
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> no -1 because there are
> >>>> use-cases for it.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> no +1 because i would use std.
> >>>> cdi mechanisms
> >>>>>>> > instead.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> >>>>>>> > gerhard.petracek@gmail.com
> >>>>>>> > > >
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> hi john,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> the sub-task is perfectly
> >>>> fine.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> >>>>>>> <jo...@gmail.com>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> Hi All
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> I wanted to bring up
> >>>> the subject of
> >>>>>>> > ServiceHandler.
> >>>>>>> > > I
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> added 113 as a
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> child
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> >>>> appropriate but not
> >>>>>>> 100%
> >>>>>>> > > sure
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> (so please let
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> me
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> know if you think
> >>>> it's not appropriate as a
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> child). ServiceHandler
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> is
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> a
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> feature in Solder that
> >>>> allows you to define
> >>>>>>> an
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> manages
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> generic calls against
> >>>> an injected interface.
> >>>>>>> The
> >>>>>>> > > API
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> is as follows:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> -
> >>>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>> placed
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> on an annotation that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> would
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> be placed on the
> >>>> interface. Indicates what
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor would be
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> invoked
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> for calls against this
> >>>> interface.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> It's then up to the
> >>>> application
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> developer/framework author to define
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> annotations that go on
> >>>> methods, as well as
> >>>>>>> the
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor itself
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> will
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> be invoked. The
> >>>> feature for ServiceHandler
> >>>>>>> would
> >>>>>>> > be
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> to provide the
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> API of
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> the type and then the
> >>>> infrastructure
> >>>>>>> required to
> >>>>>>> > > make
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> the interceptor
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> be
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> called. Existing
> >>>> documentation of the
> >>>>>>> feature:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>>
> >>>>>>> > > >
> >>>>>>> > >
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>ser
> >>>>>>> vicehandler.html
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> Regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> john
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>>
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >
> >>>>>>> > > >
> >>>>>>> > >
> >>>>>>> >
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jason Porter
> >>>>>> http://lightguard-jp.blogspot.com
> >>>>>> http://twitter.com/lightguardjp
> >>>>>>
> >>>>>> Software Engineer
> >>>>>> Open Source Advocate
> >>>>>>
> >>>>>> PGP key id: 926CCFF5
> >>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i'd rather say no because the idea is to ease "util" extension
writing. that's clearly not intended to be full business beans IMO (at
least for a first step)
That's why i'd leave it as this for now
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> Mark refers to my call stack.
>
> Out of the box this call stack would exist just in OWB, because Weld would
> not apply any Interceptors or Decorators...
>
> The question is: Should DS support Interceptors and Decorators on
> InvocationHandler beans? My answer would be: yes, if our implementation
> shall be a preview of CDI-110.
> And that would make things complicated in the implementation...
>
> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> <rm...@gmail.com>:
>
>>is it an issue for servicehandler? i don't think so
>>
>>it is often used to get util classes dynamically created, it is rarely
>>(i never saw it) decorated directly
>>
>>
>>Romain Manni-Bucau
>>Twitter: @rmannibucau
>>Blog: http://rmannibucau.wordpress.com/
>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>Github: https://github.com/rmannibucau
>>
>>
>>
>>2012/12/20 Mark Struberg <st...@yahoo.de>:
>>> we stumbled about this lately. It seems CDI only forces support for
>>>interceptors and decorators for CDI-annotated classes, but not for
>>>Bean<T> which get added via extensions nor even producer methods and
>>>fields :/
>>>
>>>
>>> Of course OWB does it, but it would be not portable...
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Arne Limburg <ar...@openknowledge.de>
>>>> To: "deltaspike-dev@incubator.apache.org"
>>>><de...@incubator.apache.org>
>>>> Cc:
>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>ServiceHandler
>>>>
>>>>T wo things about this: First: I don't like from the solder approach,
>>>> because the interface is annotated instead of the implementation.
>>>>
>>>> Second, if we implement this we should conceptually make clear how it
>>>> differentiates from Interceptors and Decorators. And personally I think
>>>> this would work better with the InvocationHandler approach than with an
>>>> approach that is very similar to interceptors.
>>>>
>>>> So +1 for an approach like this:
>>>>
>>>> @HandlesInvocationsOn(MyInterface.class)
>>>> public class MyInvocationHandler implements InvocationHandler {
>>>> ...
>>>> }
>>>>
>>>> Technically we would register a custom Bean for every found
>>>> InvocationHandler with that annotation and take over the
>>>> interceptor-bindings from the interfaceŠ
>>>> So the invocation stack would be clear, too:
>>>> First Interceptors,
>>>> Second Decorators,
>>>> Third InvocationHandler
>>>>
>>>> Wdyt?
>>>>
>>>> Arne
>>>>
>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>> <rm...@gmail.com>:
>>>>
>>>>> +1
>>>>>
>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>> part portable ans it should be fine
>>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>> <jo...@gmail.com>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Regarding the two open questions:
>>>>>>>
>>>>>>> 1) the approach (including the name/s) we agree on will be used
>>>> also
>>>>>>> for
>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>
>>>>>>> It looks like the JSR's answer
>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>> is still unresolved - I'm not sure if we can get any further
>>>> answer at
>>>>>>> this
>>>>>>> time. The last posts on the subject seem to discuss using
>>>> something
>>>>>>> along
>>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>>> Since
>>>>>>> we have some features coming up that are interested in having
>>>> service
>>>>>>> handlers available, do we
>>>>>>>
>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>> 2. Push EG on a resolution
>>>>>>> 3. Do it using invocation handlers.
>>>>>>> 4. Do it some other way?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>> gerhard.petracek@gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>> > hi john,
>>>>>>> >
>>>>>>> > as mentioned before we need the answers to the existing
>>>> questions.
>>>>>>> >
>>>>>>> > regards,
>>>>>>> > gerhard
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>> >
>>>>>>> > > All,
>>>>>>> > >
>>>>>>> > > I kind of let this one and the other drop off my radar, I
>>>>>>> apologize.
>>>>>>> it
>>>>>>> > > looks like where we last left off, Gerhard was still
>>>> requesting
>>>>>>> > additional
>>>>>>> > > comments from everyone. Any other feedback?
>>>>>>> > >
>>>>>>> > > John
>>>>>>> > >
>>>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>> > > gerhard.petracek@gmail.com> wrote:
>>>>>>> > >
>>>>>>> > > > hi george,
>>>>>>> > > >
>>>>>>> > > > thx for the information. i thought there might be at
>>>> least some
>>>>>>> > > additional
>>>>>>> > > > answers/clarifications, since pete asked for them in
>>>> several
>>>>>>> comments.
>>>>>>> > > > -> imo we should continue with them.
>>>>>>> > > >
>>>>>>> > > > regards,
>>>>>>> > > > gerhard
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > 2012/3/12 George Gastaldi
>>>> <ge...@gmail.com>
>>>>>>> > > >
>>>>>>> > > > > Hello Gerhard,
>>>>>>> > > > >
>>>>>>> > > > > Yeah, it´s the last state. I know it´s quite
>>>> old, but I
>>>>>>> haven´t had
>>>>>>> > > time
>>>>>>> > > > > to work on it after that.
>>>>>>> > > > > Regards,
>>>>>>> > > > >
>>>>>>> > > > > George
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > 2012/3/12 Gerhard Petracek
>>>> <ge...@gmail.com>
>>>>>>> > > > >
>>>>>>> > > > >> hi george,
>>>>>>> > > > >>
>>>>>>> > > > >> thx for the link.
>>>>>>> > > > >> i'm not sure if it is the latest state
>>>> of your discussion
>>>>>>> and/or
>>>>>>> > draft
>>>>>>> > > > >> (at least it's quite old already).
>>>>>>> > > > >>
>>>>>>> > > > >> regards,
>>>>>>> > > > >> gerhard
>>>>>>> > > > >>
>>>>>>> > > > >>
>>>>>>> > > > >>
>>>>>>> > > > >> 2012/3/7 George Gastaldi
>>>> <ge...@gmail.com>
>>>>>>> > > > >>
>>>>>>> > > > >>> Hi !
>>>>>>> > > > >>>
>>>>>>> > > > >>> +1 to #1. I also agree that the term
>>>> "Service Handler" might
>>>>>>> not
>>>>>>> be
>>>>>>> > > so
>>>>>>> > > > >>> appropriate, so it should be discussed
>>>> as well.
>>>>>>> > > > >>> Here is the latest pull request with
>>>> some comments from Pete
>>>>>>> yet
>>>>>>> to
>>>>>>> > > be
>>>>>>> > > > >>> reviewed:
>>>> https://github.com/jboss/cdi/pull/28
>>>>>>> > > > >>>
>>>>>>> > > > >>> 2012/3/7 Pete Muir
>>>> <pm...@redhat.com>
>>>>>>> > > > >>>
>>>>>>> > > > >>> > Agreed :-)
>>>>>>> > > > >>> >
>>>>>>> > > > >>> > George is working on it for CDI
>>>> 1.1. George, can you share
>>>>>>> your
>>>>>>> > > > >>> proposal
>>>>>>> > > > >>> > so far?
>>>>>>> > > > >>> >
>>>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
>>>> Petracek wrote:
>>>>>>> > > > >>> >
>>>>>>> > > > >>> > > hi pete,
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > > independent of my opinion
>>>> about the feature (which is
>>>>>>> still
>>>>>>> > +0):
>>>>>>> > > > >>> > > if it should be part of cdi
>>>> 1.1, we have the following
>>>>>>> options
>>>>>>> > > imo:
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > > 1) the approach (including
>>>> the name/s) we agree on will
>>>>>>> be
>>>>>>> used
>>>>>>> > > > also
>>>>>>> > > > >>> for
>>>>>>> > > > >>> > > cdi 1.1 (the only difference
>>>> is the package)
>>>>>>> > > > >>> > > 2) the eg has a different
>>>> opinion about it ->
>>>>>>> > > > >>> > > 2a) the rest of the eg joins
>>>> this discussion
>>>>>>> > > > >>> > > 2b) we wait for the final
>>>> version and just allow the same
>>>>>>> with
>>>>>>> > > cdi
>>>>>>> > > > >>> 1.0
>>>>>>> > > > >>> > > 3) if the eg doesn't
>>>> agree on the idea, it should be
>>>>>>> re-visited
>>>>>>> > > for
>>>>>>> > > > >>> > > deltaspike (if we really need
>>>> it)
>>>>>>> > > > >>> > > 4) we agree on it independent
>>>> of the result in cdi 1.1
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > > 1-3 is ok for me but -1 for
>>>> #4
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > > regards,
>>>>>>> > > > >>> > > gerhard
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > > 2012/3/7 Pete Muir
>>>> <pm...@redhat.com>
>>>>>>> > > > >>> > >
>>>>>>> > > > >>> > >> I'm not sure what you
>>>> mean by a "super interceptor",
>>>>>>> but if
>>>>>>> > you
>>>>>>> > > > >>> mean it
>>>>>>> > > > >>> > as
>>>>>>> > > > >>> > >> in "super man"
>>>> (something better than an interceptor),
>>>>>>> then
>>>>>>> I
>>>>>>> > > > would
>>>>>>> > > > >>> > >> disagree, it's
>>>> actually a specialised form of
>>>>>>> interceptor.
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> The best use case I know
>>>> of is the one John mentions -
>>>>>>> > creating
>>>>>>> > > > type
>>>>>>> > > > >>> > safe
>>>>>>> > > > >>> > >> references to queries:
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> @QueryService
>>>>>>> > > > >>> > >> interface UserQuery {
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> @Query("select u
>>>> from User u")
>>>>>>> > > > >>> > >> public List<User>
>>>> getAllUsers();
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> @Query("select u
>>>> from User u order by u.name")
>>>>>>> > > > >>> > >> public List<User>
>>>> getAllUsersSortedByName();
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> }
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> Now, it may be the case
>>>> that there aren't any other use
>>>>>>> cases
>>>>>>> > > for
>>>>>>> > > > >>> > service
>>>>>>> > > > >>> > >> handlers, in which case
>>>> we should perhaps just offer
>>>>>>> this
>>>>>>> > > > particular
>>>>>>> > > > >>> > >> service handler -
>>>> references to type safe queries - as I
>>>>>>> think
>>>>>>> > > > this
>>>>>>> > > > >>> is
>>>>>>> > > > >>> > an
>>>>>>> > > > >>> > >> extremely powerful idea.
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> Note, that at the moment
>>>> service handlers are scheduled
>>>>>>> for
>>>>>>> > CDI
>>>>>>> > > > 1.1.
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
>>>> Jason Porter wrote:
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >>> Somewhat. I
>>>> wouldn't really think of them as overrides,
>>>>>>> they,
>>>>>>> > > to
>>>>>>> > > > >>> me,
>>>>>>> > > > >>> > >> seem more like items to
>>>> do in addition to whatever the
>>>>>>> > original
>>>>>>> > > > impl
>>>>>>> > > > >>> > does.
>>>>>>> > > > >>> > >>>
>>>>>>> > > > >>> > >>> ServiceHandlers to me
>>>> seem more like super
>>>>>>> interceptors.
>>>>>>> > > > >>> > >>>
>>>>>>> > > > >>> > >>> Sent from my iPhone
>>>>>>> > > > >>> > >>>
>>>>>>> > > > >>> > >>> On Mar 6, 2012, at
>>>> 19:23, "John D. Ament" <
>>>>>>> > > > john.d.ament@gmail.com>
>>>>>>> > > > >>> > >> wrote:
>>>>>>> > > > >>> > >>>
>>>>>>> > > > >>> > >>>> @jason
>>>>>>> > > > >>> > >>>>
>>>>>>> > > > >>> > >>>> I think the
>>>> concepts are very dissimilar.
>>>>>>> servicehandlers
>>>>>>> > > > create
>>>>>>> > > > >>> the
>>>>>>> > > > >>> > >>>> implementation.
>>>> delegates are more like overrides and
>>>>>>> need
>>>>>>> > to
>>>>>>> > > > >>> know
>>>>>>> > > > >>> > >> about
>>>>>>> > > > >>> > >>>> the method
>>>> signature.
>>>>>>> > > > >>> > >>>>
>>>>>>> > > > >>> > >>>> On Tue, Mar 6,
>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>> > > > >>> lightguard.jp@gmail.com
>>>>>>> > > > >>> > >>> wrote:
>>>>>>> > > > >>> > >>>>
>>>>>>> > > > >>> > >>>>> I think the
>>>> idea of ServiceHandlers are good, but,
>>>>>>> could
>>>>>>> we
>>>>>>> > > not
>>>>>>> > > > >>> do
>>>>>>> > > > >>> > this
>>>>>>> > > > >>> > >>>>> with
>>>> delegates?
>>>>>>> > > > >>> > >>>>>
>>>>>>> > > > >>> > >>>>> Sent from my
>>>> iPhone
>>>>>>> > > > >>> > >>>>>
>>>>>>> > > > >>> > >>>>> On Mar 6,
>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>> > > > >>> john.d.ament@gmail.com>
>>>>>>> > > > >>> > >> wrote:
>>>>>>> > > > >>> > >>>>>
>>>>>>> > > > >>> > >>>>>> @mark
>>>>>>> > > > >>> > >>>>>>
>>>>>>> > > > >>> > >>>>>> I
>>>> don't think it's a hard requirement for it to be
>>>>>>> on an
>>>>>>> > > > >>> interface.
>>>>>>> > > > >>> > >>>>>>
>>>>>>> > > > >>> > >>>>>> One of
>>>> the best use-cases we built at my job is
>>>>>>> using it
>>>>>>> > for
>>>>>>> > > > >>> calling
>>>>>>> > > > >>> > >>>>>> PL/SQL.
>>>> The JDBC bindings do work, but not pretty.
>>>>>>> we
>>>>>>> > were
>>>>>>> > > > >>> able to
>>>>>>> > > > >>> > >>>>> create
>>>>>>> > > > >>> > >>>>>> a fairly
>>>> clean wrapper API, generic enough for
>>>>>>> binding
>>>>>>> > > in/out
>>>>>>> > > > >>> > >> parameters.
>>>>>>> > > > >>> > >>>>>>
>>>>>>> > > > >>> > >>>>>> JOhn
>>>>>>> > > > >>> > >>>>>>
>>>>>>> > > > >>> > >>>>>> On Tue,
>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>> > > > >>> struberg@yahoo.de>
>>>>>>> > > > >>> > >>>>> wrote:
>>>>>>> > > > >>> > >>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>> actually I don't really see a real benefit. I just
>>>>>>> don't
>>>>>>> > > yet
>>>>>>> > > > >>> grok
>>>>>>> > > > >>> > the
>>>>>>> > > > >>> > >>>>> use
>>>>>>> > > > >>> > >>>>>>> case
>>>> for real world projects.
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>> Why
>>>> would one intercept an Interface and delegate
>>>>>>> the
>>>>>>> > calls
>>>>>>> > > > to
>>>>>>> > > > >>> a
>>>>>>> > > > >>> > >> method
>>>>>>> > > > >>> > >>>>>>>
>>>> handler?
>>>>>>> > > > >>> > >>>>>>> This
>>>> could be neat for mocking, but there are
>>>>>>> better
>>>>>>> > > > >>> frameworks for
>>>>>>> > > > >>> > >>>>> that.
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>> thus
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>> -0.2
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>> LieGrue,
>>>>>>> > > > >>> > >>>>>>> strub
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>>> -----
>>>> Original Message -----
>>>>>>> > > > >>> > >>>>>>>>
>>>> From: Gerhard Petracek
>>>>>>> <ge...@gmail.com>
>>>>>>> > > > >>> > >>>>>>>>
>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>> > > > >>> > >>>>>>>>
>>>> Cc:
>>>>>>> > > > >>> > >>>>>>>>
>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>> > > > >>> > >>>>>>>>
>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>> > Discuss
>>>>>>> > > > >>> > >>>>>
>>>> ServiceHandler
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>> if you have a lot of shared code, you can extract
>>>>>>> it
>>>>>>> in
>>>>>>> > > 1-n
>>>>>>> > > > >>> > >> method/s or
>>>>>>> > > > >>> > >>>>>>> an
>>>>>>> > > > >>> > >>>>>>>>
>>>> abstract class which is still easier than a new
>>>>>>> concept.
>>>>>>> > > > >>> > >>>>>>>>
>>>> at least i haven't seen an use-case which really
>>>>>>> needed
>>>>>>> > > it.
>>>>>>> > > > >>> that
>>>>>>> > > > >>> > was
>>>>>>> > > > >>> > >>>>> the
>>>>>>> > > > >>> > >>>>>>>>
>>>> reason for a +0 (which still means that i'm ok
>>>>>>> with
>>>>>>> > adding
>>>>>>> > > > >>> it).
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>> regards,
>>>>>>> > > > >>> > >>>>>>>>
>>>> gerhard
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>> boilerplate
>>>>>>> > > > code
>>>>>>> > > > >>> in
>>>>>>> > > > >>> > it?
>>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>> wrote:
>>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>> hi pete,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>> instead of the interface you can just
>>>> implement
>>>>>>> a
>>>>>>> bean
>>>>>>> > > > which
>>>>>>> > > > >>> > does
>>>>>>> > > > >>> > >> the
>>>>>>> > > > >>> >
>>>>>>>>>>>>> same.
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>> regards,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>> gerhard
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>> <pm...@redhat.com>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>> instead?
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>> Petracek
>>>>>>> wrote:
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> +0
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> no -1 because there are
>>>> use-cases for it.
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>> cdi mechanisms
>>>>>>> > instead.
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> regards,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> gerhard
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>> > gerhard.petracek@gmail.com
>>>>>>> > > >
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> hi john,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>> fine.
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> regards,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> gerhard
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>> <jo...@gmail.com>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> Hi All
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>> the subject of
>>>>>>> > ServiceHandler.
>>>>>>> > > I
>>>>>>> > > > >>> > >>>>>>>>
>>>> added 113 as a
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> child
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>> appropriate but not
>>>>>>> 100%
>>>>>>> > > sure
>>>>>>> > > > >>> > >>>>>>>>
>>>> (so please let
>>>>>>> > > > >>> >
>>>>>>>>>>>>> me
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> know if you think
>>>> it's not appropriate as a
>>>>>>> > > > >>> > >>>>>>>>
>>>> child). ServiceHandler
>>>>>>> > > > >>> >
>>>>>>>>>>>>> is
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> a
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> feature in Solder that
>>>> allows you to define
>>>>>>> an
>>>>>>> > > > >>> > >>>>>>>>
>>>> interceptor that
>>>>>>> > > > >>> >
>>>>>>>>>>>>> manages
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> generic calls against
>>>> an injected interface.
>>>>>>> The
>>>>>>> > > API
>>>>>>> > > > >>> > >>>>>>>>
>>>> is as follows:
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> -
>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>> placed
>>>>>>> > > > >>> > >>>>>>>>
>>>> on an annotation that
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> would
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> be placed on the
>>>> interface. Indicates what
>>>>>>> > > > >>> > >>>>>>>>
>>>> interceptor would be
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> invoked
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> for calls against this
>>>> interface.
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> It's then up to the
>>>> application
>>>>>>> > > > >>> > >>>>>>>>
>>>> developer/framework author to define
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> annotations that go on
>>>> methods, as well as
>>>>>>> the
>>>>>>> > > > >>> > >>>>>>>>
>>>> interceptor itself
>>>>>>> > > > >>> >
>>>>>>>>>>>>> that
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> will
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> be invoked. The
>>>> feature for ServiceHandler
>>>>>>> would
>>>>>>> > be
>>>>>>> > > > >>> > >>>>>>>>
>>>> to provide the
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> API of
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> the type and then the
>>>> infrastructure
>>>>>>> required to
>>>>>>> > > make
>>>>>>> > > > >>> > >>>>>>>>
>>>> the interceptor
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>> be
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> called. Existing
>>>> documentation of the
>>>>>>> feature:
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> >
>>>>>>> > > > >>>
>>>>>>> > > >
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>ser
>>>>>>> vicehandler.html
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>> john
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>>> > > > >>> > >>>>>>>>
>>>>>>> > > > >>> > >>>>>>>
>>>>>>> > > > >>> > >>>>>
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> > >>
>>>>>>> > > > >>> >
>>>>>>> > > > >>> >
>>>>>>> > > > >>>
>>>>>>> > > > >>
>>>>>>> > > > >>
>>>>>>> > > > >
>>>>>>> > > >
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason Porter
>>>>>> http://lightguard-jp.blogspot.com
>>>>>> http://twitter.com/lightguardjp
>>>>>>
>>>>>> Software Engineer
>>>>>> Open Source Advocate
>>>>>>
>>>>>> PGP key id: 926CCFF5
>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Arne Limburg <ar...@openknowledge.de>.
Mark refers to my call stack.
Out of the box this call stack would exist just in OWB, because Weld would
not apply any Interceptors or Decorators...
The question is: Should DS support Interceptors and Decorators on
InvocationHandler beans? My answer would be: yes, if our implementation
shall be a preview of CDI-110.
And that would make things complicated in the implementation...
Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
<rm...@gmail.com>:
>is it an issue for servicehandler? i don't think so
>
>it is often used to get util classes dynamically created, it is rarely
>(i never saw it) decorated directly
>
>
>Romain Manni-Bucau
>Twitter: @rmannibucau
>Blog: http://rmannibucau.wordpress.com/
>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>Github: https://github.com/rmannibucau
>
>
>
>2012/12/20 Mark Struberg <st...@yahoo.de>:
>> we stumbled about this lately. It seems CDI only forces support for
>>interceptors and decorators for CDI-annotated classes, but not for
>>Bean<T> which get added via extensions nor even producer methods and
>>fields :/
>>
>>
>> Of course OWB does it, but it would be not portable...
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Arne Limburg <ar...@openknowledge.de>
>>> To: "deltaspike-dev@incubator.apache.org"
>>><de...@incubator.apache.org>
>>> Cc:
>>> Sent: Thursday, December 20, 2012 10:18 AM
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>ServiceHandler
>>>
>>>T wo things about this: First: I don't like from the solder approach,
>>> because the interface is annotated instead of the implementation.
>>>
>>> Second, if we implement this we should conceptually make clear how it
>>> differentiates from Interceptors and Decorators. And personally I think
>>> this would work better with the InvocationHandler approach than with an
>>> approach that is very similar to interceptors.
>>>
>>> So +1 for an approach like this:
>>>
>>> @HandlesInvocationsOn(MyInterface.class)
>>> public class MyInvocationHandler implements InvocationHandler {
>>> ...
>>> }
>>>
>>> Technically we would register a custom Bean for every found
>>> InvocationHandler with that annotation and take over the
>>> interceptor-bindings from the interfaceŠ
>>> So the invocation stack would be clear, too:
>>> First Interceptors,
>>> Second Decorators,
>>> Third InvocationHandler
>>>
>>> Wdyt?
>>>
>>> Arne
>>>
>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>> <rm...@gmail.com>:
>>>
>>>> +1
>>>>
>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>> part portable ans it should be fine
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>> At this point, I'd say just do it as is in solder.
>>>>>
>>>>>
>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>> <jo...@gmail.com>wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Regarding the two open questions:
>>>>>>
>>>>>> 1) the approach (including the name/s) we agree on will be used
>>> also
>>>>>> for
>>>>>> cdi 1.1 (the only difference is the package)
>>>>>> 2) the eg has a different opinion about it ->
>>>>>>
>>>>>> It looks like the JSR's answer
>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>> is still unresolved - I'm not sure if we can get any further
>>> answer at
>>>>>> this
>>>>>> time. The last posts on the subject seem to discuss using
>>> something
>>>>>> along
>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>> Since
>>>>>> we have some features coming up that are interested in having
>>> service
>>>>>> handlers available, do we
>>>>>>
>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>> 2. Push EG on a resolution
>>>>>> 3. Do it using invocation handlers.
>>>>>> 4. Do it some other way?
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>> gerhard.petracek@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>> > hi john,
>>>>>> >
>>>>>> > as mentioned before we need the answers to the existing
>>> questions.
>>>>>> >
>>>>>> > regards,
>>>>>> > gerhard
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>> >
>>>>>> > > All,
>>>>>> > >
>>>>>> > > I kind of let this one and the other drop off my radar, I
>>>>>> apologize.
>>>>>> it
>>>>>> > > looks like where we last left off, Gerhard was still
>>> requesting
>>>>>> > additional
>>>>>> > > comments from everyone. Any other feedback?
>>>>>> > >
>>>>>> > > John
>>>>>> > >
>>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>> > > gerhard.petracek@gmail.com> wrote:
>>>>>> > >
>>>>>> > > > hi george,
>>>>>> > > >
>>>>>> > > > thx for the information. i thought there might be at
>>> least some
>>>>>> > > additional
>>>>>> > > > answers/clarifications, since pete asked for them in
>>> several
>>>>>> comments.
>>>>>> > > > -> imo we should continue with them.
>>>>>> > > >
>>>>>> > > > regards,
>>>>>> > > > gerhard
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > 2012/3/12 George Gastaldi
>>> <ge...@gmail.com>
>>>>>> > > >
>>>>>> > > > > Hello Gerhard,
>>>>>> > > > >
>>>>>> > > > > Yeah, it´s the last state. I know it´s quite
>>> old, but I
>>>>>> haven´t had
>>>>>> > > time
>>>>>> > > > > to work on it after that.
>>>>>> > > > > Regards,
>>>>>> > > > >
>>>>>> > > > > George
>>>>>> > > > >
>>>>>> > > > >
>>>>>> > > > > 2012/3/12 Gerhard Petracek
>>> <ge...@gmail.com>
>>>>>> > > > >
>>>>>> > > > >> hi george,
>>>>>> > > > >>
>>>>>> > > > >> thx for the link.
>>>>>> > > > >> i'm not sure if it is the latest state
>>> of your discussion
>>>>>> and/or
>>>>>> > draft
>>>>>> > > > >> (at least it's quite old already).
>>>>>> > > > >>
>>>>>> > > > >> regards,
>>>>>> > > > >> gerhard
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >> 2012/3/7 George Gastaldi
>>> <ge...@gmail.com>
>>>>>> > > > >>
>>>>>> > > > >>> Hi !
>>>>>> > > > >>>
>>>>>> > > > >>> +1 to #1. I also agree that the term
>>> "Service Handler" might
>>>>>> not
>>>>>> be
>>>>>> > > so
>>>>>> > > > >>> appropriate, so it should be discussed
>>> as well.
>>>>>> > > > >>> Here is the latest pull request with
>>> some comments from Pete
>>>>>> yet
>>>>>> to
>>>>>> > > be
>>>>>> > > > >>> reviewed:
>>> https://github.com/jboss/cdi/pull/28
>>>>>> > > > >>>
>>>>>> > > > >>> 2012/3/7 Pete Muir
>>> <pm...@redhat.com>
>>>>>> > > > >>>
>>>>>> > > > >>> > Agreed :-)
>>>>>> > > > >>> >
>>>>>> > > > >>> > George is working on it for CDI
>>> 1.1. George, can you share
>>>>>> your
>>>>>> > > > >>> proposal
>>>>>> > > > >>> > so far?
>>>>>> > > > >>> >
>>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
>>> Petracek wrote:
>>>>>> > > > >>> >
>>>>>> > > > >>> > > hi pete,
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > independent of my opinion
>>> about the feature (which is
>>>>>> still
>>>>>> > +0):
>>>>>> > > > >>> > > if it should be part of cdi
>>> 1.1, we have the following
>>>>>> options
>>>>>> > > imo:
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 1) the approach (including
>>> the name/s) we agree on will
>>>>>> be
>>>>>> used
>>>>>> > > > also
>>>>>> > > > >>> for
>>>>>> > > > >>> > > cdi 1.1 (the only difference
>>> is the package)
>>>>>> > > > >>> > > 2) the eg has a different
>>> opinion about it ->
>>>>>> > > > >>> > > 2a) the rest of the eg joins
>>> this discussion
>>>>>> > > > >>> > > 2b) we wait for the final
>>> version and just allow the same
>>>>>> with
>>>>>> > > cdi
>>>>>> > > > >>> 1.0
>>>>>> > > > >>> > > 3) if the eg doesn't
>>> agree on the idea, it should be
>>>>>> re-visited
>>>>>> > > for
>>>>>> > > > >>> > > deltaspike (if we really need
>>> it)
>>>>>> > > > >>> > > 4) we agree on it independent
>>> of the result in cdi 1.1
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 1-3 is ok for me but -1 for
>>> #4
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > regards,
>>>>>> > > > >>> > > gerhard
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 2012/3/7 Pete Muir
>>> <pm...@redhat.com>
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >> I'm not sure what you
>>> mean by a "super interceptor",
>>>>>> but if
>>>>>> > you
>>>>>> > > > >>> mean it
>>>>>> > > > >>> > as
>>>>>> > > > >>> > >> in "super man"
>>> (something better than an interceptor),
>>>>>> then
>>>>>> I
>>>>>> > > > would
>>>>>> > > > >>> > >> disagree, it's
>>> actually a specialised form of
>>>>>> interceptor.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> The best use case I know
>>> of is the one John mentions -
>>>>>> > creating
>>>>>> > > > type
>>>>>> > > > >>> > safe
>>>>>> > > > >>> > >> references to queries:
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @QueryService
>>>>>> > > > >>> > >> interface UserQuery {
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @Query("select u
>>> from User u")
>>>>>> > > > >>> > >> public List<User>
>>> getAllUsers();
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @Query("select u
>>> from User u order by u.name")
>>>>>> > > > >>> > >> public List<User>
>>> getAllUsersSortedByName();
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> }
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> Now, it may be the case
>>> that there aren't any other use
>>>>>> cases
>>>>>> > > for
>>>>>> > > > >>> > service
>>>>>> > > > >>> > >> handlers, in which case
>>> we should perhaps just offer
>>>>>> this
>>>>>> > > > particular
>>>>>> > > > >>> > >> service handler -
>>> references to type safe queries - as I
>>>>>> think
>>>>>> > > > this
>>>>>> > > > >>> is
>>>>>> > > > >>> > an
>>>>>> > > > >>> > >> extremely powerful idea.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> Note, that at the moment
>>> service handlers are scheduled
>>>>>> for
>>>>>> > CDI
>>>>>> > > > 1.1.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
>>> Jason Porter wrote:
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>> Somewhat. I
>>> wouldn't really think of them as overrides,
>>>>>> they,
>>>>>> > > to
>>>>>> > > > >>> me,
>>>>>> > > > >>> > >> seem more like items to
>>> do in addition to whatever the
>>>>>> > original
>>>>>> > > > impl
>>>>>> > > > >>> > does.
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> ServiceHandlers to me
>>> seem more like super
>>>>>> interceptors.
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> Sent from my iPhone
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> On Mar 6, 2012, at
>>> 19:23, "John D. Ament" <
>>>>>> > > > john.d.ament@gmail.com>
>>>>>> > > > >>> > >> wrote:
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>>> @jason
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>> I think the
>>> concepts are very dissimilar.
>>>>>> servicehandlers
>>>>>> > > > create
>>>>>> > > > >>> the
>>>>>> > > > >>> > >>>> implementation.
>>> delegates are more like overrides and
>>>>>> need
>>>>>> > to
>>>>>> > > > >>> know
>>>>>> > > > >>> > >> about
>>>>>> > > > >>> > >>>> the method
>>> signature.
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>> On Tue, Mar 6,
>>> 2012 at 9:17 PM, Jason Porter <
>>>>>> > > > >>> lightguard.jp@gmail.com
>>>>>> > > > >>> > >>> wrote:
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>>> I think the
>>> idea of ServiceHandlers are good, but,
>>>>>> could
>>>>>> we
>>>>>> > > not
>>>>>> > > > >>> do
>>>>>> > > > >>> > this
>>>>>> > > > >>> > >>>>> with
>>> delegates?
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>> Sent from my
>>> iPhone
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>> On Mar 6,
>>> 2012, at 19:05, "John D. Ament" <
>>>>>> > > > >>> john.d.ament@gmail.com>
>>>>>> > > > >>> > >> wrote:
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>>> @mark
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> I
>>> don't think it's a hard requirement for it to be
>>>>>> on an
>>>>>> > > > >>> interface.
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> One of
>>> the best use-cases we built at my job is
>>>>>> using it
>>>>>> > for
>>>>>> > > > >>> calling
>>>>>> > > > >>> > >>>>>> PL/SQL.
>>> The JDBC bindings do work, but not pretty.
>>>>>> we
>>>>>> > were
>>>>>> > > > >>> able to
>>>>>> > > > >>> > >>>>> create
>>>>>> > > > >>> > >>>>>> a fairly
>>> clean wrapper API, generic enough for
>>>>>> binding
>>>>>> > > in/out
>>>>>> > > > >>> > >> parameters.
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> JOhn
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> On Tue,
>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>> > > > >>> struberg@yahoo.de>
>>>>>> > > > >>> > >>>>> wrote:
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>>>
>>> actually I don't really see a real benefit. I just
>>>>>> don't
>>>>>> > > yet
>>>>>> > > > >>> grok
>>>>>> > > > >>> > the
>>>>>> > > > >>> > >>>>> use
>>>>>> > > > >>> > >>>>>>> case
>>> for real world projects.
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> Why
>>> would one intercept an Interface and delegate
>>>>>> the
>>>>>> > calls
>>>>>> > > > to
>>>>>> > > > >>> a
>>>>>> > > > >>> > >> method
>>>>>> > > > >>> > >>>>>>>
>>> handler?
>>>>>> > > > >>> > >>>>>>> This
>>> could be neat for mocking, but there are
>>>>>> better
>>>>>> > > > >>> frameworks for
>>>>>> > > > >>> > >>>>> that.
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> thus
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> -0.2
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>> LieGrue,
>>>>>> > > > >>> > >>>>>>> strub
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> -----
>>> Original Message -----
>>>>>> > > > >>> > >>>>>>>>
>>> From: Gerhard Petracek
>>>>>> <ge...@gmail.com>
>>>>>> > > > >>> > >>>>>>>>
>>> To: deltaspike-dev@incubator.apache.org
>>>>>> > > > >>> > >>>>>>>>
>>> Cc:
>>>>>> > > > >>> > >>>>>>>>
>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>> > > > >>> > >>>>>>>>
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>> > Discuss
>>>>>> > > > >>> > >>>>>
>>> ServiceHandler
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>> if you have a lot of shared code, you can extract
>>>>>> it
>>>>>> in
>>>>>> > > 1-n
>>>>>> > > > >>> > >> method/s or
>>>>>> > > > >>> > >>>>>>> an
>>>>>> > > > >>> > >>>>>>>>
>>> abstract class which is still easier than a new
>>>>>> concept.
>>>>>> > > > >>> > >>>>>>>>
>>> at least i haven't seen an use-case which really
>>>>>> needed
>>>>>> > > it.
>>>>>> > > > >>> that
>>>>>> > > > >>> > was
>>>>>> > > > >>> > >>>>> the
>>>>>> > > > >>> > >>>>>>>>
>>> reason for a +0 (which still means that i'm ok
>>>>>> with
>>>>>> > adding
>>>>>> > > > >>> it).
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>> regards,
>>>>>> > > > >>> > >>>>>>>>
>>> gerhard
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>> boilerplate
>>>>>> > > > code
>>>>>> > > > >>> in
>>>>>> > > > >>> > it?
>>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>> wrote:
>>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>> hi pete,
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>> instead of the interface you can just
>>> implement
>>>>>> a
>>>>>> bean
>>>>>> > > > which
>>>>>> > > > >>> > does
>>>>>> > > > >>> > >> the
>>>>>> > > > >>> >
>>>>>>>>>>>> same.
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>> regards,
>>>>>> > > > >>> >
>>>>>>>>>>>>> gerhard
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>> <pm...@redhat.com>
>>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>> What CDI mechanism would you use
>>> instead?
>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>> Petracek
>>>>>> wrote:
>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> +0
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> no -1 because there are
>>> use-cases for it.
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> no +1 because i would use std.
>>> cdi mechanisms
>>>>>> > instead.
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> regards,
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> gerhard
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>> > gerhard.petracek@gmail.com
>>>>>> > > >
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> hi john,
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> the sub-task is perfectly
>>> fine.
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> regards,
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> gerhard
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>> <jo...@gmail.com>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>> Hi All
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> I wanted to bring up
>>> the subject of
>>>>>> > ServiceHandler.
>>>>>> > > I
>>>>>> > > > >>> > >>>>>>>>
>>> added 113 as a
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> child
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>> appropriate but not
>>>>>> 100%
>>>>>> > > sure
>>>>>> > > > >>> > >>>>>>>>
>>> (so please let
>>>>>> > > > >>> >
>>>>>>>>>>>> me
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> know if you think
>>> it's not appropriate as a
>>>>>> > > > >>> > >>>>>>>>
>>> child). ServiceHandler
>>>>>> > > > >>> >
>>>>>>>>>>>> is
>>>>>> > > > >>> >
>>>>>>>>>>>>>> a
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> feature in Solder that
>>> allows you to define
>>>>>> an
>>>>>> > > > >>> > >>>>>>>>
>>> interceptor that
>>>>>> > > > >>> >
>>>>>>>>>>>> manages
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> generic calls against
>>> an injected interface.
>>>>>> The
>>>>>> > > API
>>>>>> > > > >>> > >>>>>>>>
>>> is as follows:
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> -
>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>> placed
>>>>>> > > > >>> > >>>>>>>>
>>> on an annotation that
>>>>>> > > > >>> >
>>>>>>>>>>>>>> would
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> be placed on the
>>> interface. Indicates what
>>>>>> > > > >>> > >>>>>>>>
>>> interceptor would be
>>>>>> > > > >>> >
>>>>>>>>>>>>>> invoked
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> for calls against this
>>> interface.
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> It's then up to the
>>> application
>>>>>> > > > >>> > >>>>>>>>
>>> developer/framework author to define
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> annotations that go on
>>> methods, as well as
>>>>>> the
>>>>>> > > > >>> > >>>>>>>>
>>> interceptor itself
>>>>>> > > > >>> >
>>>>>>>>>>>> that
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> will
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> be invoked. The
>>> feature for ServiceHandler
>>>>>> would
>>>>>> > be
>>>>>> > > > >>> > >>>>>>>>
>>> to provide the
>>>>>> > > > >>> >
>>>>>>>>>>>>>> API of
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> the type and then the
>>> infrastructure
>>>>>> required to
>>>>>> > > make
>>>>>> > > > >>> > >>>>>>>>
>>> the interceptor
>>>>>> > > > >>> >
>>>>>>>>>>>>>> be
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> called. Existing
>>> documentation of the
>>>>>> feature:
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> >
>>>>>> > > > >>>
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>ser
>>>>>> vicehandler.html
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> Regards,
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>> john
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> >
>>>>>> > > > >>> >
>>>>>> > > > >>>
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> http://lightguard-jp.blogspot.com
>>>>> http://twitter.com/lightguardjp
>>>>>
>>>>> Software Engineer
>>>>> Open Source Advocate
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
is it an issue for servicehandler? i don't think so
it is often used to get util classes dynamically created, it is rarely
(i never saw it) decorated directly
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Mark Struberg <st...@yahoo.de>:
> we stumbled about this lately. It seems CDI only forces support for interceptors and decorators for CDI-annotated classes, but not for Bean<T> which get added via extensions nor even producer methods and fields :/
>
>
> Of course OWB does it, but it would be not portable...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Arne Limburg <ar...@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
>> Cc:
>> Sent: Thursday, December 20, 2012 10:18 AM
>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>>
>>T wo things about this: First: I don't like from the solder approach,
>> because the interface is annotated instead of the implementation.
>>
>> Second, if we implement this we should conceptually make clear how it
>> differentiates from Interceptors and Decorators. And personally I think
>> this would work better with the InvocationHandler approach than with an
>> approach that is very similar to interceptors.
>>
>> So +1 for an approach like this:
>>
>> @HandlesInvocationsOn(MyInterface.class)
>> public class MyInvocationHandler implements InvocationHandler {
>> ...
>> }
>>
>> Technically we would register a custom Bean for every found
>> InvocationHandler with that annotation and take over the
>> interceptor-bindings from the interfaceŠ
>> So the invocation stack would be clear, too:
>> First Interceptors,
>> Second Decorators,
>> Third InvocationHandler
>>
>> Wdyt?
>>
>> Arne
>>
>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>> <rm...@gmail.com>:
>>
>>> +1
>>>
>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>> part portable ans it should be fine
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>> At this point, I'd say just do it as is in solder.
>>>>
>>>>
>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>> <jo...@gmail.com>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Regarding the two open questions:
>>>>>
>>>>> 1) the approach (including the name/s) we agree on will be used
>> also
>>>>> for
>>>>> cdi 1.1 (the only difference is the package)
>>>>> 2) the eg has a different opinion about it ->
>>>>>
>>>>> It looks like the JSR's answer
>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>> is still unresolved - I'm not sure if we can get any further
>> answer at
>>>>> this
>>>>> time. The last posts on the subject seem to discuss using
>> something
>>>>> along
>>>>> the lines of an invocation handler, which I think would work well.
>>>>> Since
>>>>> we have some features coming up that are interested in having
>> service
>>>>> handlers available, do we
>>>>>
>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>> 2. Push EG on a resolution
>>>>> 3. Do it using invocation handlers.
>>>>> 4. Do it some other way?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>> gerhard.petracek@gmail.com
>>>>> > wrote:
>>>>>
>>>>> > hi john,
>>>>> >
>>>>> > as mentioned before we need the answers to the existing
>> questions.
>>>>> >
>>>>> > regards,
>>>>> > gerhard
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>> >
>>>>> > > All,
>>>>> > >
>>>>> > > I kind of let this one and the other drop off my radar, I
>>>>> apologize.
>>>>> it
>>>>> > > looks like where we last left off, Gerhard was still
>> requesting
>>>>> > additional
>>>>> > > comments from everyone. Any other feedback?
>>>>> > >
>>>>> > > John
>>>>> > >
>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>> > > gerhard.petracek@gmail.com> wrote:
>>>>> > >
>>>>> > > > hi george,
>>>>> > > >
>>>>> > > > thx for the information. i thought there might be at
>> least some
>>>>> > > additional
>>>>> > > > answers/clarifications, since pete asked for them in
>> several
>>>>> comments.
>>>>> > > > -> imo we should continue with them.
>>>>> > > >
>>>>> > > > regards,
>>>>> > > > gerhard
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 2012/3/12 George Gastaldi
>> <ge...@gmail.com>
>>>>> > > >
>>>>> > > > > Hello Gerhard,
>>>>> > > > >
>>>>> > > > > Yeah, it´s the last state. I know it´s quite
>> old, but I
>>>>> haven´t had
>>>>> > > time
>>>>> > > > > to work on it after that.
>>>>> > > > > Regards,
>>>>> > > > >
>>>>> > > > > George
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > 2012/3/12 Gerhard Petracek
>> <ge...@gmail.com>
>>>>> > > > >
>>>>> > > > >> hi george,
>>>>> > > > >>
>>>>> > > > >> thx for the link.
>>>>> > > > >> i'm not sure if it is the latest state
>> of your discussion
>>>>> and/or
>>>>> > draft
>>>>> > > > >> (at least it's quite old already).
>>>>> > > > >>
>>>>> > > > >> regards,
>>>>> > > > >> gerhard
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2012/3/7 George Gastaldi
>> <ge...@gmail.com>
>>>>> > > > >>
>>>>> > > > >>> Hi !
>>>>> > > > >>>
>>>>> > > > >>> +1 to #1. I also agree that the term
>> "Service Handler" might
>>>>> not
>>>>> be
>>>>> > > so
>>>>> > > > >>> appropriate, so it should be discussed
>> as well.
>>>>> > > > >>> Here is the latest pull request with
>> some comments from Pete
>>>>> yet
>>>>> to
>>>>> > > be
>>>>> > > > >>> reviewed:
>> https://github.com/jboss/cdi/pull/28
>>>>> > > > >>>
>>>>> > > > >>> 2012/3/7 Pete Muir
>> <pm...@redhat.com>
>>>>> > > > >>>
>>>>> > > > >>> > Agreed :-)
>>>>> > > > >>> >
>>>>> > > > >>> > George is working on it for CDI
>> 1.1. George, can you share
>>>>> your
>>>>> > > > >>> proposal
>>>>> > > > >>> > so far?
>>>>> > > > >>> >
>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
>> Petracek wrote:
>>>>> > > > >>> >
>>>>> > > > >>> > > hi pete,
>>>>> > > > >>> > >
>>>>> > > > >>> > > independent of my opinion
>> about the feature (which is
>>>>> still
>>>>> > +0):
>>>>> > > > >>> > > if it should be part of cdi
>> 1.1, we have the following
>>>>> options
>>>>> > > imo:
>>>>> > > > >>> > >
>>>>> > > > >>> > > 1) the approach (including
>> the name/s) we agree on will
>>>>> be
>>>>> used
>>>>> > > > also
>>>>> > > > >>> for
>>>>> > > > >>> > > cdi 1.1 (the only difference
>> is the package)
>>>>> > > > >>> > > 2) the eg has a different
>> opinion about it ->
>>>>> > > > >>> > > 2a) the rest of the eg joins
>> this discussion
>>>>> > > > >>> > > 2b) we wait for the final
>> version and just allow the same
>>>>> with
>>>>> > > cdi
>>>>> > > > >>> 1.0
>>>>> > > > >>> > > 3) if the eg doesn't
>> agree on the idea, it should be
>>>>> re-visited
>>>>> > > for
>>>>> > > > >>> > > deltaspike (if we really need
>> it)
>>>>> > > > >>> > > 4) we agree on it independent
>> of the result in cdi 1.1
>>>>> > > > >>> > >
>>>>> > > > >>> > > 1-3 is ok for me but -1 for
>> #4
>>>>> > > > >>> > >
>>>>> > > > >>> > > regards,
>>>>> > > > >>> > > gerhard
>>>>> > > > >>> > >
>>>>> > > > >>> > >
>>>>> > > > >>> > >
>>>>> > > > >>> > > 2012/3/7 Pete Muir
>> <pm...@redhat.com>
>>>>> > > > >>> > >
>>>>> > > > >>> > >> I'm not sure what you
>> mean by a "super interceptor",
>>>>> but if
>>>>> > you
>>>>> > > > >>> mean it
>>>>> > > > >>> > as
>>>>> > > > >>> > >> in "super man"
>> (something better than an interceptor),
>>>>> then
>>>>> I
>>>>> > > > would
>>>>> > > > >>> > >> disagree, it's
>> actually a specialised form of
>>>>> interceptor.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> The best use case I know
>> of is the one John mentions -
>>>>> > creating
>>>>> > > > type
>>>>> > > > >>> > safe
>>>>> > > > >>> > >> references to queries:
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @QueryService
>>>>> > > > >>> > >> interface UserQuery {
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @Query("select u
>> from User u")
>>>>> > > > >>> > >> public List<User>
>> getAllUsers();
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @Query("select u
>> from User u order by u.name")
>>>>> > > > >>> > >> public List<User>
>> getAllUsersSortedByName();
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> }
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> Now, it may be the case
>> that there aren't any other use
>>>>> cases
>>>>> > > for
>>>>> > > > >>> > service
>>>>> > > > >>> > >> handlers, in which case
>> we should perhaps just offer
>>>>> this
>>>>> > > > particular
>>>>> > > > >>> > >> service handler -
>> references to type safe queries - as I
>>>>> think
>>>>> > > > this
>>>>> > > > >>> is
>>>>> > > > >>> > an
>>>>> > > > >>> > >> extremely powerful idea.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> Note, that at the moment
>> service handlers are scheduled
>>>>> for
>>>>> > CDI
>>>>> > > > 1.1.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
>> Jason Porter wrote:
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>> Somewhat. I
>> wouldn't really think of them as overrides,
>>>>> they,
>>>>> > > to
>>>>> > > > >>> me,
>>>>> > > > >>> > >> seem more like items to
>> do in addition to whatever the
>>>>> > original
>>>>> > > > impl
>>>>> > > > >>> > does.
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> ServiceHandlers to me
>> seem more like super
>>>>> interceptors.
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> Sent from my iPhone
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> On Mar 6, 2012, at
>> 19:23, "John D. Ament" <
>>>>> > > > john.d.ament@gmail.com>
>>>>> > > > >>> > >> wrote:
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>>> @jason
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>> I think the
>> concepts are very dissimilar.
>>>>> servicehandlers
>>>>> > > > create
>>>>> > > > >>> the
>>>>> > > > >>> > >>>> implementation.
>> delegates are more like overrides and
>>>>> need
>>>>> > to
>>>>> > > > >>> know
>>>>> > > > >>> > >> about
>>>>> > > > >>> > >>>> the method
>> signature.
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>> On Tue, Mar 6,
>> 2012 at 9:17 PM, Jason Porter <
>>>>> > > > >>> lightguard.jp@gmail.com
>>>>> > > > >>> > >>> wrote:
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>>> I think the
>> idea of ServiceHandlers are good, but,
>>>>> could
>>>>> we
>>>>> > > not
>>>>> > > > >>> do
>>>>> > > > >>> > this
>>>>> > > > >>> > >>>>> with
>> delegates?
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>> Sent from my
>> iPhone
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>> On Mar 6,
>> 2012, at 19:05, "John D. Ament" <
>>>>> > > > >>> john.d.ament@gmail.com>
>>>>> > > > >>> > >> wrote:
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>>> @mark
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> I
>> don't think it's a hard requirement for it to be
>>>>> on an
>>>>> > > > >>> interface.
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> One of
>> the best use-cases we built at my job is
>>>>> using it
>>>>> > for
>>>>> > > > >>> calling
>>>>> > > > >>> > >>>>>> PL/SQL.
>> The JDBC bindings do work, but not pretty.
>>>>> we
>>>>> > were
>>>>> > > > >>> able to
>>>>> > > > >>> > >>>>> create
>>>>> > > > >>> > >>>>>> a fairly
>> clean wrapper API, generic enough for
>>>>> binding
>>>>> > > in/out
>>>>> > > > >>> > >> parameters.
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> JOhn
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> On Tue,
>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>> > > > >>> struberg@yahoo.de>
>>>>> > > > >>> > >>>>> wrote:
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>>>
>> actually I don't really see a real benefit. I just
>>>>> don't
>>>>> > > yet
>>>>> > > > >>> grok
>>>>> > > > >>> > the
>>>>> > > > >>> > >>>>> use
>>>>> > > > >>> > >>>>>>> case
>> for real world projects.
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> Why
>> would one intercept an Interface and delegate
>>>>> the
>>>>> > calls
>>>>> > > > to
>>>>> > > > >>> a
>>>>> > > > >>> > >> method
>>>>> > > > >>> > >>>>>>>
>> handler?
>>>>> > > > >>> > >>>>>>> This
>> could be neat for mocking, but there are
>>>>> better
>>>>> > > > >>> frameworks for
>>>>> > > > >>> > >>>>> that.
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> thus
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> -0.2
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>>
>> LieGrue,
>>>>> > > > >>> > >>>>>>> strub
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> -----
>> Original Message -----
>>>>> > > > >>> > >>>>>>>>
>> From: Gerhard Petracek
>>>>> <ge...@gmail.com>
>>>>> > > > >>> > >>>>>>>>
>> To: deltaspike-dev@incubator.apache.org
>>>>> > > > >>> > >>>>>>>>
>> Cc:
>>>>> > > > >>> > >>>>>>>>
>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>> > > > >>> > >>>>>>>>
>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>> > Discuss
>>>>> > > > >>> > >>>>>
>> ServiceHandler
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>> if you have a lot of shared code, you can extract
>>>>> it
>>>>> in
>>>>> > > 1-n
>>>>> > > > >>> > >> method/s or
>>>>> > > > >>> > >>>>>>> an
>>>>> > > > >>> > >>>>>>>>
>> abstract class which is still easier than a new
>>>>> concept.
>>>>> > > > >>> > >>>>>>>>
>> at least i haven't seen an use-case which really
>>>>> needed
>>>>> > > it.
>>>>> > > > >>> that
>>>>> > > > >>> > was
>>>>> > > > >>> > >>>>> the
>>>>> > > > >>> > >>>>>>>>
>> reason for a +0 (which still means that i'm ok
>>>>> with
>>>>> > adding
>>>>> > > > >>> it).
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>> regards,
>>>>> > > > >>> > >>>>>>>>
>> gerhard
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>> So, you mean just write a bean with all the
>>>>> boilerplate
>>>>> > > > code
>>>>> > > > >>> in
>>>>> > > > >>> > it?
>>>>> > > > >>> >
>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>> wrote:
>>>>> > > > >>> >
>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>> hi pete,
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>> instead of the interface you can just
>> implement
>>>>> a
>>>>> bean
>>>>> > > > which
>>>>> > > > >>> > does
>>>>> > > > >>> > >> the
>>>>> > > > >>> >
>>>>>>>>>>> same.
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>> regards,
>>>>> > > > >>> >
>>>>>>>>>>>> gerhard
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>> 2012/3/6 Pete Muir
>> <pm...@redhat.com>
>>>>> > > > >>> >
>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>> What CDI mechanism would you use
>> instead?
>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>> Petracek
>>>>> wrote:
>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>> +0
>>>>> > > > >>> >
>>>>>>>>>>>>>> no -1 because there are
>> use-cases for it.
>>>>> > > > >>> >
>>>>>>>>>>>>>> no +1 because i would use std.
>> cdi mechanisms
>>>>> > instead.
>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>> regards,
>>>>> > > > >>> >
>>>>>>>>>>>>>> gerhard
>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>> > gerhard.petracek@gmail.com
>>>>> > > >
>>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>> hi john,
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>> the sub-task is perfectly
>> fine.
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>> regards,
>>>>> > > > >>> >
>>>>>>>>>>>>>>> gerhard
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>> <jo...@gmail.com>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>> Hi All
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> I wanted to bring up
>> the subject of
>>>>> > ServiceHandler.
>>>>> > > I
>>>>> > > > >>> > >>>>>>>>
>> added 113 as a
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> child
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>> appropriate but not
>>>>> 100%
>>>>> > > sure
>>>>> > > > >>> > >>>>>>>>
>> (so please let
>>>>> > > > >>> >
>>>>>>>>>>> me
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> know if you think
>> it's not appropriate as a
>>>>> > > > >>> > >>>>>>>>
>> child). ServiceHandler
>>>>> > > > >>> >
>>>>>>>>>>> is
>>>>> > > > >>> >
>>>>>>>>>>>>> a
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> feature in Solder that
>> allows you to define
>>>>> an
>>>>> > > > >>> > >>>>>>>>
>> interceptor that
>>>>> > > > >>> >
>>>>>>>>>>> manages
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> generic calls against
>> an injected interface.
>>>>> The
>>>>> > > API
>>>>> > > > >>> > >>>>>>>>
>> is as follows:
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> -
>> @ServiceHandlerType(Class<?> clazz) -
>>>>> placed
>>>>> > > > >>> > >>>>>>>>
>> on an annotation that
>>>>> > > > >>> >
>>>>>>>>>>>>> would
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> be placed on the
>> interface. Indicates what
>>>>> > > > >>> > >>>>>>>>
>> interceptor would be
>>>>> > > > >>> >
>>>>>>>>>>>>> invoked
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> for calls against this
>> interface.
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> It's then up to the
>> application
>>>>> > > > >>> > >>>>>>>>
>> developer/framework author to define
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> annotations that go on
>> methods, as well as
>>>>> the
>>>>> > > > >>> > >>>>>>>>
>> interceptor itself
>>>>> > > > >>> >
>>>>>>>>>>> that
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> will
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> be invoked. The
>> feature for ServiceHandler
>>>>> would
>>>>> > be
>>>>> > > > >>> > >>>>>>>>
>> to provide the
>>>>> > > > >>> >
>>>>>>>>>>>>> API of
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> the type and then the
>> infrastructure
>>>>> required to
>>>>> > > make
>>>>> > > > >>> > >>>>>>>>
>> the interceptor
>>>>> > > > >>> >
>>>>>>>>>>>>> be
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> called. Existing
>> documentation of the
>>>>> feature:
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>
>>>>> > > > >>> >
>>>>> > > > >>>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-ser
>>>>> vicehandler.html
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> Regards,
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>> john
>>>>> > > > >>> >
>>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>
>>>>> > > > >>> >
>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>
>>>>> > > > >>> >
>>>>> > > > >>> >
>>>>> > > > >>>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jason Porter
>>>> http://lightguard-jp.blogspot.com
>>>> http://twitter.com/lightguardjp
>>>>
>>>> Software Engineer
>>>> Open Source Advocate
>>>>
>>>> PGP key id: 926CCFF5
>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Arne Limburg <ar...@openknowledge.de>.
Yes, decorators would be cool, since it would introduce the ability to use
decorators as mixins without having a base class.
For those who are not familiar with mixins, I have coded a gist where
mixins are used to resolve a multiple inheritance scenario [1]
The base idea of mixins is to create small code snippets (smaller than a
complete class), that the provide more reusability than a class...
In my example there is a mixin that holds just one property ("title") that
can be used for every component that has a title
and another mixin that provides a better implementation of the Comparable
interface…
The base idea for using mixins that way comes from qi4j [2]
[1] https://gist.github.com/4345897
[2] http://qi4j.org/
Am 20.12.12 11:57 schrieb "Pete Muir" unter <pm...@redhat.com>:
>Interceptors don't matter, a service handler is essentially an
>interceptor already. Decorators would be nice, for sure, but I don't
>think this stops us implementing this feature.
>
>On 20 Dec 2012, at 10:06, Mark Struberg wrote:
>
>> we stumbled about this lately. It seems CDI only forces support for
>>interceptors and decorators for CDI-annotated classes, but not for
>>Bean<T> which get added via extensions nor even producer methods and
>>fields :/
>>
>>
>> Of course OWB does it, but it would be not portable...
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Arne Limburg <ar...@openknowledge.de>
>>> To: "deltaspike-dev@incubator.apache.org"
>>><de...@incubator.apache.org>
>>> Cc:
>>> Sent: Thursday, December 20, 2012 10:18 AM
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>ServiceHandler
>>>
>>> T wo things about this: First: I don't like from the solder approach,
>>> because the interface is annotated instead of the implementation.
>>>
>>> Second, if we implement this we should conceptually make clear how it
>>> differentiates from Interceptors and Decorators. And personally I think
>>> this would work better with the InvocationHandler approach than with an
>>> approach that is very similar to interceptors.
>>>
>>> So +1 for an approach like this:
>>>
>>> @HandlesInvocationsOn(MyInterface.class)
>>> public class MyInvocationHandler implements InvocationHandler {
>>> ...
>>> }
>>>
>>> Technically we would register a custom Bean for every found
>>> InvocationHandler with that annotation and take over the
>>> interceptor-bindings from the interfaceŠ
>>> So the invocation stack would be clear, too:
>>> First Interceptors,
>>> Second Decorators,
>>> Third InvocationHandler
>>>
>>> Wdyt?
>>>
>>> Arne
>>>
>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>> <rm...@gmail.com>:
>>>
>>>> +1
>>>>
>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>> part portable ans it should be fine
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>> At this point, I'd say just do it as is in solder.
>>>>>
>>>>>
>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>> <jo...@gmail.com>wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Regarding the two open questions:
>>>>>>
>>>>>> 1) the approach (including the name/s) we agree on will be used
>>> also
>>>>>> for
>>>>>> cdi 1.1 (the only difference is the package)
>>>>>> 2) the eg has a different opinion about it ->
>>>>>>
>>>>>> It looks like the JSR's answer
>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>> is still unresolved - I'm not sure if we can get any further
>>> answer at
>>>>>> this
>>>>>> time. The last posts on the subject seem to discuss using
>>> something
>>>>>> along
>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>> Since
>>>>>> we have some features coming up that are interested in having
>>> service
>>>>>> handlers available, do we
>>>>>>
>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>> 2. Push EG on a resolution
>>>>>> 3. Do it using invocation handlers.
>>>>>> 4. Do it some other way?
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>> gerhard.petracek@gmail.com
>>>>>>> wrote:
>>>>>>
>>>>>>> hi john,
>>>>>>>
>>>>>>> as mentioned before we need the answers to the existing
>>> questions.
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>> apologize.
>>>>>> it
>>>>>>>> looks like where we last left off, Gerhard was still
>>> requesting
>>>>>>> additional
>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> hi george,
>>>>>>>>>
>>>>>>>>> thx for the information. i thought there might be at
>>> least some
>>>>>>>> additional
>>>>>>>>> answers/clarifications, since pete asked for them in
>>> several
>>>>>> comments.
>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> gerhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/3/12 George Gastaldi
>>> <ge...@gmail.com>
>>>>>>>>>
>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>
>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>> old, but I
>>>>>> haven´t had
>>>>>>>> time
>>>>>>>>>> to work on it after that.
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> George
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>> <ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> hi george,
>>>>>>>>>>>
>>>>>>>>>>> thx for the link.
>>>>>>>>>>> i'm not sure if it is the latest state
>>> of your discussion
>>>>>> and/or
>>>>>>> draft
>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/7 George Gastaldi
>>> <ge...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> Hi !
>>>>>>>>>>>>
>>>>>>>>>>>> +1 to #1. I also agree that the term
>>> "Service Handler" might
>>>>>> not
>>>>>> be
>>>>>>>> so
>>>>>>>>>>>> appropriate, so it should be discussed
>>> as well.
>>>>>>>>>>>> Here is the latest pull request with
>>> some comments from Pete
>>>>>> yet
>>>>>> to
>>>>>>>> be
>>>>>>>>>>>> reviewed:
>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/7 Pete Muir
>>> <pm...@redhat.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> George is working on it for CDI
>>> 1.1. George, can you share
>>>>>> your
>>>>>>>>>>>> proposal
>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>> Petracek wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> independent of my opinion
>>> about the feature (which is
>>>>>> still
>>>>>>> +0):
>>>>>>>>>>>>>> if it should be part of cdi
>>> 1.1, we have the following
>>>>>> options
>>>>>>>> imo:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) the approach (including
>>> the name/s) we agree on will
>>>>>> be
>>>>>> used
>>>>>>>>> also
>>>>>>>>>>>> for
>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>> is the package)
>>>>>>>>>>>>>> 2) the eg has a different
>>> opinion about it ->
>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>> this discussion
>>>>>>>>>>>>>> 2b) we wait for the final
>>> version and just allow the same
>>>>>> with
>>>>>>>> cdi
>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>> 3) if the eg doesn't
>>> agree on the idea, it should be
>>>>>> re-visited
>>>>>>>> for
>>>>>>>>>>>>>> deltaspike (if we really need
>>> it)
>>>>>>>>>>>>>> 4) we agree on it independent
>>> of the result in cdi 1.1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>> #4
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>> <pm...@redhat.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure what you
>>> mean by a "super interceptor",
>>>>>> but if
>>>>>>> you
>>>>>>>>>>>> mean it
>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> in "super man"
>>> (something better than an interceptor),
>>>>>> then
>>>>>> I
>>>>>>>>> would
>>>>>>>>>>>>>>> disagree, it's
>>> actually a specialised form of
>>>>>> interceptor.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The best use case I know
>>> of is the one John mentions -
>>>>>>> creating
>>>>>>>>> type
>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Query("select u
>>> from User u")
>>>>>>>>>>>>>>> public List<User>
>>> getAllUsers();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Query("select u
>>> from User u order by u.name")
>>>>>>>>>>>>>>> public List<User>
>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now, it may be the case
>>> that there aren't any other use
>>>>>> cases
>>>>>>>> for
>>>>>>>>>>>>> service
>>>>>>>>>>>>>>> handlers, in which case
>>> we should perhaps just offer
>>>>>> this
>>>>>>>>> particular
>>>>>>>>>>>>>>> service handler -
>>> references to type safe queries - as I
>>>>>> think
>>>>>>>>> this
>>>>>>>>>>>> is
>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note, that at the moment
>>> service handlers are scheduled
>>>>>> for
>>>>>>> CDI
>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>> Jason Porter wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Somewhat. I
>>> wouldn't really think of them as overrides,
>>>>>> they,
>>>>>>>> to
>>>>>>>>>>>> me,
>>>>>>>>>>>>>>> seem more like items to
>>> do in addition to whatever the
>>>>>>> original
>>>>>>>>> impl
>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ServiceHandlers to me
>>> seem more like super
>>>>>> interceptors.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>> 19:23, "John D. Ament" <
>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the
>>> concepts are very dissimilar.
>>>>>> servicehandlers
>>>>>>>>> create
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> implementation.
>>> delegates are more like overrides and
>>>>>> need
>>>>>>> to
>>>>>>>>>>>> know
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> the method
>>> signature.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think the
>>> idea of ServiceHandlers are good, but,
>>>>>> could
>>>>>> we
>>>>>>>> not
>>>>>>>>>>>> do
>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> with
>>> delegates?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sent from my
>>> iPhone
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mar 6,
>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I
>>> don't think it's a hard requirement for it to be
>>>>>> on an
>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> One of
>>> the best use-cases we built at my job is
>>>>>> using it
>>>>>>> for
>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>> PL/SQL.
>>> The JDBC bindings do work, but not pretty.
>>>>>> we
>>>>>>> were
>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>> a fairly
>>> clean wrapper API, generic enough for
>>>>>> binding
>>>>>>>> in/out
>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue,
>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>> actually I don't really see a real benefit. I just
>>>>>> don't
>>>>>>>> yet
>>>>>>>>>>>> grok
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>> case
>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Why
>>> would one intercept an Interface and delegate
>>>>>> the
>>>>>>> calls
>>>>>>>>> to
>>>>>>>>>>>> a
>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>
>>> handler?
>>>>>>>>>>>>>>>>>>>> This
>>> could be neat for mocking, but there are
>>>>>> better
>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>> LieGrue,
>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -----
>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>
>>> From: Gerhard Petracek
>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>
>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>
>>> Cc:
>>>>>>>>>>>>>>>>>>>>>
>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>
>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>> if you have a lot of shared code, you can extract
>>>>>> it
>>>>>> in
>>>>>>>> 1-n
>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>
>>> abstract class which is still easier than a new
>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>
>>> at least i haven't seen an use-case which really
>>>>>> needed
>>>>>>>> it.
>>>>>>>>>>>> that
>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>
>>> reason for a +0 (which still means that i'm ok
>>>>>> with
>>>>>>> adding
>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>> regards,
>>>>>>>>>>>>>>>>>>>>>
>>> gerhard
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>> boilerplate
>>>>>>>>> code
>>>>>>>>>>>> in
>>>>>>>>>>>>> it?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> instead of the interface you can just
>>> implement
>>>>>> a
>>>>>> bean
>>>>>>>>> which
>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> same.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>> <pm...@redhat.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What CDI mechanism would you use
>>> instead?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>> Petracek
>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> no -1 because there are
>>> use-cases for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> no +1 because i would use std.
>>> cdi mechanisms
>>>>>>> instead.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the sub-task is perfectly
>>> fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I wanted to bring up
>>> the subject of
>>>>>>> ServiceHandler.
>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>
>>> added 113 as a
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>> appropriate but not
>>>>>> 100%
>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>
>>> (so please let
>>>>>>>>>>>>>
>>>>>>>>>>>> me
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> know if you think
>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>
>>> child). ServiceHandler
>>>>>>>>>>>>>
>>>>>>>>>>>> is
>>>>>>>>>>>>>
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> feature in Solder that
>>> allows you to define
>>>>>> an
>>>>>>>>>>>>>>>>>>>>>
>>> interceptor that
>>>>>>>>>>>>>
>>>>>>>>>>>> manages
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> generic calls against
>>> an injected interface.
>>>>>> The
>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>
>>> is as follows:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -
>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>
>>> on an annotation that
>>>>>>>>>>>>>
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be placed on the
>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>
>>> interceptor would be
>>>>>>>>>>>>>
>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> for calls against this
>>> interface.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's then up to the
>>> application
>>>>>>>>>>>>>>>>>>>>>
>>> developer/framework author to define
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> annotations that go on
>>> methods, as well as
>>>>>> the
>>>>>>>>>>>>>>>>>>>>>
>>> interceptor itself
>>>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be invoked. The
>>> feature for ServiceHandler
>>>>>> would
>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>
>>> to provide the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the type and then the
>>> infrastructure
>>>>>> required to
>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>
>>> the interceptor
>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> called. Existing
>>> documentation of the
>>>>>> feature:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>ser
>>>>>> vicehandler.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> http://lightguard-jp.blogspot.com
>>>>> http://twitter.com/lightguardjp
>>>>>
>>>>> Software Engineer
>>>>> Open Source Advocate
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
Interceptors don't matter, a service handler is essentially an interceptor already. Decorators would be nice, for sure, but I don't think this stops us implementing this feature.
On 20 Dec 2012, at 10:06, Mark Struberg wrote:
> we stumbled about this lately. It seems CDI only forces support for interceptors and decorators for CDI-annotated classes, but not for Bean<T> which get added via extensions nor even producer methods and fields :/
>
>
> Of course OWB does it, but it would be not portable...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Arne Limburg <ar...@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
>> Cc:
>> Sent: Thursday, December 20, 2012 10:18 AM
>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>>
>> T wo things about this: First: I don't like from the solder approach,
>> because the interface is annotated instead of the implementation.
>>
>> Second, if we implement this we should conceptually make clear how it
>> differentiates from Interceptors and Decorators. And personally I think
>> this would work better with the InvocationHandler approach than with an
>> approach that is very similar to interceptors.
>>
>> So +1 for an approach like this:
>>
>> @HandlesInvocationsOn(MyInterface.class)
>> public class MyInvocationHandler implements InvocationHandler {
>> ...
>> }
>>
>> Technically we would register a custom Bean for every found
>> InvocationHandler with that annotation and take over the
>> interceptor-bindings from the interfaceŠ
>> So the invocation stack would be clear, too:
>> First Interceptors,
>> Second Decorators,
>> Third InvocationHandler
>>
>> Wdyt?
>>
>> Arne
>>
>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>> <rm...@gmail.com>:
>>
>>> +1
>>>
>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>> part portable ans it should be fine
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>> At this point, I'd say just do it as is in solder.
>>>>
>>>>
>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>> <jo...@gmail.com>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Regarding the two open questions:
>>>>>
>>>>> 1) the approach (including the name/s) we agree on will be used
>> also
>>>>> for
>>>>> cdi 1.1 (the only difference is the package)
>>>>> 2) the eg has a different opinion about it ->
>>>>>
>>>>> It looks like the JSR's answer
>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>> is still unresolved - I'm not sure if we can get any further
>> answer at
>>>>> this
>>>>> time. The last posts on the subject seem to discuss using
>> something
>>>>> along
>>>>> the lines of an invocation handler, which I think would work well.
>>>>> Since
>>>>> we have some features coming up that are interested in having
>> service
>>>>> handlers available, do we
>>>>>
>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>> 2. Push EG on a resolution
>>>>> 3. Do it using invocation handlers.
>>>>> 4. Do it some other way?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>> gerhard.petracek@gmail.com
>>>>>> wrote:
>>>>>
>>>>>> hi john,
>>>>>>
>>>>>> as mentioned before we need the answers to the existing
>> questions.
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>> apologize.
>>>>> it
>>>>>>> looks like where we last left off, Gerhard was still
>> requesting
>>>>>> additional
>>>>>>> comments from everyone. Any other feedback?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>
>>>>>>>> hi george,
>>>>>>>>
>>>>>>>> thx for the information. i thought there might be at
>> least some
>>>>>>> additional
>>>>>>>> answers/clarifications, since pete asked for them in
>> several
>>>>> comments.
>>>>>>>> -> imo we should continue with them.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/12 George Gastaldi
>> <ge...@gmail.com>
>>>>>>>>
>>>>>>>>> Hello Gerhard,
>>>>>>>>>
>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>> old, but I
>>>>> haven´t had
>>>>>>> time
>>>>>>>>> to work on it after that.
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> George
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/3/12 Gerhard Petracek
>> <ge...@gmail.com>
>>>>>>>>>
>>>>>>>>>> hi george,
>>>>>>>>>>
>>>>>>>>>> thx for the link.
>>>>>>>>>> i'm not sure if it is the latest state
>> of your discussion
>>>>> and/or
>>>>>> draft
>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/7 George Gastaldi
>> <ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Hi !
>>>>>>>>>>>
>>>>>>>>>>> +1 to #1. I also agree that the term
>> "Service Handler" might
>>>>> not
>>>>> be
>>>>>>> so
>>>>>>>>>>> appropriate, so it should be discussed
>> as well.
>>>>>>>>>>> Here is the latest pull request with
>> some comments from Pete
>>>>> yet
>>>>> to
>>>>>>> be
>>>>>>>>>>> reviewed:
>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/7 Pete Muir
>> <pm...@redhat.com>
>>>>>>>>>>>
>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>
>>>>>>>>>>>> George is working on it for CDI
>> 1.1. George, can you share
>>>>> your
>>>>>>>>>>> proposal
>>>>>>>>>>>> so far?
>>>>>>>>>>>>
>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>> Petracek wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>
>>>>>>>>>>>>> independent of my opinion
>> about the feature (which is
>>>>> still
>>>>>> +0):
>>>>>>>>>>>>> if it should be part of cdi
>> 1.1, we have the following
>>>>> options
>>>>>>> imo:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) the approach (including
>> the name/s) we agree on will
>>>>> be
>>>>> used
>>>>>>>> also
>>>>>>>>>>> for
>>>>>>>>>>>>> cdi 1.1 (the only difference
>> is the package)
>>>>>>>>>>>>> 2) the eg has a different
>> opinion about it ->
>>>>>>>>>>>>> 2a) the rest of the eg joins
>> this discussion
>>>>>>>>>>>>> 2b) we wait for the final
>> version and just allow the same
>>>>> with
>>>>>>> cdi
>>>>>>>>>>> 1.0
>>>>>>>>>>>>> 3) if the eg doesn't
>> agree on the idea, it should be
>>>>> re-visited
>>>>>>> for
>>>>>>>>>>>>> deltaspike (if we really need
>> it)
>>>>>>>>>>>>> 4) we agree on it independent
>> of the result in cdi 1.1
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>> #4
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/7 Pete Muir
>> <pm...@redhat.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure what you
>> mean by a "super interceptor",
>>>>> but if
>>>>>> you
>>>>>>>>>>> mean it
>>>>>>>>>>>> as
>>>>>>>>>>>>>> in "super man"
>> (something better than an interceptor),
>>>>> then
>>>>> I
>>>>>>>> would
>>>>>>>>>>>>>> disagree, it's
>> actually a specialised form of
>>>>> interceptor.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The best use case I know
>> of is the one John mentions -
>>>>>> creating
>>>>>>>> type
>>>>>>>>>>>> safe
>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Query("select u
>> from User u")
>>>>>>>>>>>>>> public List<User>
>> getAllUsers();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Query("select u
>> from User u order by u.name")
>>>>>>>>>>>>>> public List<User>
>> getAllUsersSortedByName();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, it may be the case
>> that there aren't any other use
>>>>> cases
>>>>>>> for
>>>>>>>>>>>> service
>>>>>>>>>>>>>> handlers, in which case
>> we should perhaps just offer
>>>>> this
>>>>>>>> particular
>>>>>>>>>>>>>> service handler -
>> references to type safe queries - as I
>>>>> think
>>>>>>>> this
>>>>>>>>>>> is
>>>>>>>>>>>> an
>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note, that at the moment
>> service handlers are scheduled
>>>>> for
>>>>>> CDI
>>>>>>>> 1.1.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>> Jason Porter wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Somewhat. I
>> wouldn't really think of them as overrides,
>>>>> they,
>>>>>>> to
>>>>>>>>>>> me,
>>>>>>>>>>>>>> seem more like items to
>> do in addition to whatever the
>>>>>> original
>>>>>>>> impl
>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ServiceHandlers to me
>> seem more like super
>>>>> interceptors.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mar 6, 2012, at
>> 19:23, "John D. Ament" <
>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the
>> concepts are very dissimilar.
>>>>> servicehandlers
>>>>>>>> create
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> implementation.
>> delegates are more like overrides and
>>>>> need
>>>>>> to
>>>>>>>>>>> know
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> the method
>> signature.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Mar 6,
>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the
>> idea of ServiceHandlers are good, but,
>>>>> could
>>>>> we
>>>>>>> not
>>>>>>>>>>> do
>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> with
>> delegates?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sent from my
>> iPhone
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mar 6,
>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I
>> don't think it's a hard requirement for it to be
>>>>> on an
>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One of
>> the best use-cases we built at my job is
>>>>> using it
>>>>>> for
>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>> PL/SQL.
>> The JDBC bindings do work, but not pretty.
>>>>> we
>>>>>> were
>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>> a fairly
>> clean wrapper API, generic enough for
>>>>> binding
>>>>>>> in/out
>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue,
>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>> actually I don't really see a real benefit. I just
>>>>> don't
>>>>>>> yet
>>>>>>>>>>> grok
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>> case
>> for real world projects.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why
>> would one intercept an Interface and delegate
>>>>> the
>>>>>> calls
>>>>>>>> to
>>>>>>>>>>> a
>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>
>> handler?
>>>>>>>>>>>>>>>>>>> This
>> could be neat for mocking, but there are
>>>>> better
>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>> LieGrue,
>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----
>> Original Message -----
>>>>>>>>>>>>>>>>>>>>
>> From: Gerhard Petracek
>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>
>> Cc:
>>>>>>>>>>>>>>>>>>>>
>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>
>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>> Discuss
>>>>>>>>>>>>>>>>>
>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>> if you have a lot of shared code, you can extract
>>>>> it
>>>>> in
>>>>>>> 1-n
>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>
>> abstract class which is still easier than a new
>>>>> concept.
>>>>>>>>>>>>>>>>>>>>
>> at least i haven't seen an use-case which really
>>>>> needed
>>>>>>> it.
>>>>>>>>>>> that
>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>
>> reason for a +0 (which still means that i'm ok
>>>>> with
>>>>>> adding
>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>> regards,
>>>>>>>>>>>>>>>>>>>>
>> gerhard
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> So, you mean just write a bean with all the
>>>>> boilerplate
>>>>>>>> code
>>>>>>>>>>> in
>>>>>>>>>>>> it?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> instead of the interface you can just
>> implement
>>>>> a
>>>>> bean
>>>>>>>> which
>>>>>>>>>>>> does
>>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> same.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>>
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/6 Pete Muir
>> <pm...@redhat.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> What CDI mechanism would you use
>> instead?
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>> Petracek
>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> +0
>>>>>>>>>>>>
>>>>>>>>>>>>>> no -1 because there are
>> use-cases for it.
>>>>>>>>>>>>
>>>>>>>>>>>>>> no +1 because i would use std.
>> cdi mechanisms
>>>>>> instead.
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>
>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>> gerhard.petracek@gmail.com
>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> the sub-task is perfectly
>> fine.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>
>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>> <jo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wanted to bring up
>> the subject of
>>>>>> ServiceHandler.
>>>>>>> I
>>>>>>>>>>>>>>>>>>>>
>> added 113 as a
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>> appropriate but not
>>>>> 100%
>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>
>> (so please let
>>>>>>>>>>>>
>>>>>>>>>>> me
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> know if you think
>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>
>> child). ServiceHandler
>>>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>>> a
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> feature in Solder that
>> allows you to define
>>>>> an
>>>>>>>>>>>>>>>>>>>>
>> interceptor that
>>>>>>>>>>>>
>>>>>>>>>>> manages
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> generic calls against
>> an injected interface.
>>>>> The
>>>>>>> API
>>>>>>>>>>>>>>>>>>>>
>> is as follows:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -
>> @ServiceHandlerType(Class<?> clazz) -
>>>>> placed
>>>>>>>>>>>>>>>>>>>>
>> on an annotation that
>>>>>>>>>>>>
>>>>>>>>>>>>> would
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> be placed on the
>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>
>> interceptor would be
>>>>>>>>>>>>
>>>>>>>>>>>>> invoked
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> for calls against this
>> interface.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's then up to the
>> application
>>>>>>>>>>>>>>>>>>>>
>> developer/framework author to define
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> annotations that go on
>> methods, as well as
>>>>> the
>>>>>>>>>>>>>>>>>>>>
>> interceptor itself
>>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> be invoked. The
>> feature for ServiceHandler
>>>>> would
>>>>>> be
>>>>>>>>>>>>>>>>>>>>
>> to provide the
>>>>>>>>>>>>
>>>>>>>>>>>>> API of
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the type and then the
>> infrastructure
>>>>> required to
>>>>>>> make
>>>>>>>>>>>>>>>>>>>>
>> the interceptor
>>>>>>>>>>>>
>>>>>>>>>>>>> be
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> called. Existing
>> documentation of the
>>>>> feature:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-ser
>>>>> vicehandler.html
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jason Porter
>>>> http://lightguard-jp.blogspot.com
>>>> http://twitter.com/lightguardjp
>>>>
>>>> Software Engineer
>>>> Open Source Advocate
>>>>
>>>> PGP key id: 926CCFF5
>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
we stumbled about this lately. It seems CDI only forces support for interceptors and decorators for CDI-annotated classes, but not for Bean<T> which get added via extensions nor even producer methods and fields :/
Of course OWB does it, but it would be not portable...
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Thursday, December 20, 2012 10:18 AM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>
>T wo things about this: First: I don't like from the solder approach,
> because the interface is annotated instead of the implementation.
>
> Second, if we implement this we should conceptually make clear how it
> differentiates from Interceptors and Decorators. And personally I think
> this would work better with the InvocationHandler approach than with an
> approach that is very similar to interceptors.
>
> So +1 for an approach like this:
>
> @HandlesInvocationsOn(MyInterface.class)
> public class MyInvocationHandler implements InvocationHandler {
> ...
> }
>
> Technically we would register a custom Bean for every found
> InvocationHandler with that annotation and take over the
> interceptor-bindings from the interfaceŠ
> So the invocation stack would be clear, too:
> First Interceptors,
> Second Decorators,
> Third InvocationHandler
>
> Wdyt?
>
> Arne
>
> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> <rm...@gmail.com>:
>
>> +1
>>
>> that's a need, DS targets CDI 1.0 for now so just make this solder
>> part portable ans it should be fine
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>> At this point, I'd say just do it as is in solder.
>>>
>>>
>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>> <jo...@gmail.com>wrote:
>>>
>>>> Hi All,
>>>>
>>>> Regarding the two open questions:
>>>>
>>>> 1) the approach (including the name/s) we agree on will be used
> also
>>>> for
>>>> cdi 1.1 (the only difference is the package)
>>>> 2) the eg has a different opinion about it ->
>>>>
>>>> It looks like the JSR's answer
>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>> is still unresolved - I'm not sure if we can get any further
> answer at
>>>> this
>>>> time. The last posts on the subject seem to discuss using
> something
>>>> along
>>>> the lines of an invocation handler, which I think would work well.
>>>> Since
>>>> we have some features coming up that are interested in having
> service
>>>> handlers available, do we
>>>>
>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>> 2. Push EG on a resolution
>>>> 3. Do it using invocation handlers.
>>>> 4. Do it some other way?
>>>>
>>>> John
>>>>
>>>>
>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>> gerhard.petracek@gmail.com
>>>> > wrote:
>>>>
>>>> > hi john,
>>>> >
>>>> > as mentioned before we need the answers to the existing
> questions.
>>>> >
>>>> > regards,
>>>> > gerhard
>>>> >
>>>> >
>>>> >
>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>> >
>>>> > > All,
>>>> > >
>>>> > > I kind of let this one and the other drop off my radar, I
>>>> apologize.
>>>> it
>>>> > > looks like where we last left off, Gerhard was still
> requesting
>>>> > additional
>>>> > > comments from everyone. Any other feedback?
>>>> > >
>>>> > > John
>>>> > >
>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>> > > gerhard.petracek@gmail.com> wrote:
>>>> > >
>>>> > > > hi george,
>>>> > > >
>>>> > > > thx for the information. i thought there might be at
> least some
>>>> > > additional
>>>> > > > answers/clarifications, since pete asked for them in
> several
>>>> comments.
>>>> > > > -> imo we should continue with them.
>>>> > > >
>>>> > > > regards,
>>>> > > > gerhard
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > 2012/3/12 George Gastaldi
> <ge...@gmail.com>
>>>> > > >
>>>> > > > > Hello Gerhard,
>>>> > > > >
>>>> > > > > Yeah, it´s the last state. I know it´s quite
> old, but I
>>>> haven´t had
>>>> > > time
>>>> > > > > to work on it after that.
>>>> > > > > Regards,
>>>> > > > >
>>>> > > > > George
>>>> > > > >
>>>> > > > >
>>>> > > > > 2012/3/12 Gerhard Petracek
> <ge...@gmail.com>
>>>> > > > >
>>>> > > > >> hi george,
>>>> > > > >>
>>>> > > > >> thx for the link.
>>>> > > > >> i'm not sure if it is the latest state
> of your discussion
>>>> and/or
>>>> > draft
>>>> > > > >> (at least it's quite old already).
>>>> > > > >>
>>>> > > > >> regards,
>>>> > > > >> gerhard
>>>> > > > >>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> 2012/3/7 George Gastaldi
> <ge...@gmail.com>
>>>> > > > >>
>>>> > > > >>> Hi !
>>>> > > > >>>
>>>> > > > >>> +1 to #1. I also agree that the term
> "Service Handler" might
>>>> not
>>>> be
>>>> > > so
>>>> > > > >>> appropriate, so it should be discussed
> as well.
>>>> > > > >>> Here is the latest pull request with
> some comments from Pete
>>>> yet
>>>> to
>>>> > > be
>>>> > > > >>> reviewed:
> https://github.com/jboss/cdi/pull/28
>>>> > > > >>>
>>>> > > > >>> 2012/3/7 Pete Muir
> <pm...@redhat.com>
>>>> > > > >>>
>>>> > > > >>> > Agreed :-)
>>>> > > > >>> >
>>>> > > > >>> > George is working on it for CDI
> 1.1. George, can you share
>>>> your
>>>> > > > >>> proposal
>>>> > > > >>> > so far?
>>>> > > > >>> >
>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
> Petracek wrote:
>>>> > > > >>> >
>>>> > > > >>> > > hi pete,
>>>> > > > >>> > >
>>>> > > > >>> > > independent of my opinion
> about the feature (which is
>>>> still
>>>> > +0):
>>>> > > > >>> > > if it should be part of cdi
> 1.1, we have the following
>>>> options
>>>> > > imo:
>>>> > > > >>> > >
>>>> > > > >>> > > 1) the approach (including
> the name/s) we agree on will
>>>> be
>>>> used
>>>> > > > also
>>>> > > > >>> for
>>>> > > > >>> > > cdi 1.1 (the only difference
> is the package)
>>>> > > > >>> > > 2) the eg has a different
> opinion about it ->
>>>> > > > >>> > > 2a) the rest of the eg joins
> this discussion
>>>> > > > >>> > > 2b) we wait for the final
> version and just allow the same
>>>> with
>>>> > > cdi
>>>> > > > >>> 1.0
>>>> > > > >>> > > 3) if the eg doesn't
> agree on the idea, it should be
>>>> re-visited
>>>> > > for
>>>> > > > >>> > > deltaspike (if we really need
> it)
>>>> > > > >>> > > 4) we agree on it independent
> of the result in cdi 1.1
>>>> > > > >>> > >
>>>> > > > >>> > > 1-3 is ok for me but -1 for
> #4
>>>> > > > >>> > >
>>>> > > > >>> > > regards,
>>>> > > > >>> > > gerhard
>>>> > > > >>> > >
>>>> > > > >>> > >
>>>> > > > >>> > >
>>>> > > > >>> > > 2012/3/7 Pete Muir
> <pm...@redhat.com>
>>>> > > > >>> > >
>>>> > > > >>> > >> I'm not sure what you
> mean by a "super interceptor",
>>>> but if
>>>> > you
>>>> > > > >>> mean it
>>>> > > > >>> > as
>>>> > > > >>> > >> in "super man"
> (something better than an interceptor),
>>>> then
>>>> I
>>>> > > > would
>>>> > > > >>> > >> disagree, it's
> actually a specialised form of
>>>> interceptor.
>>>> > > > >>> > >>
>>>> > > > >>> > >> The best use case I know
> of is the one John mentions -
>>>> > creating
>>>> > > > type
>>>> > > > >>> > safe
>>>> > > > >>> > >> references to queries:
>>>> > > > >>> > >>
>>>> > > > >>> > >> @QueryService
>>>> > > > >>> > >> interface UserQuery {
>>>> > > > >>> > >>
>>>> > > > >>> > >> @Query("select u
> from User u")
>>>> > > > >>> > >> public List<User>
> getAllUsers();
>>>> > > > >>> > >>
>>>> > > > >>> > >> @Query("select u
> from User u order by u.name")
>>>> > > > >>> > >> public List<User>
> getAllUsersSortedByName();
>>>> > > > >>> > >>
>>>> > > > >>> > >> }
>>>> > > > >>> > >>
>>>> > > > >>> > >> Now, it may be the case
> that there aren't any other use
>>>> cases
>>>> > > for
>>>> > > > >>> > service
>>>> > > > >>> > >> handlers, in which case
> we should perhaps just offer
>>>> this
>>>> > > > particular
>>>> > > > >>> > >> service handler -
> references to type safe queries - as I
>>>> think
>>>> > > > this
>>>> > > > >>> is
>>>> > > > >>> > an
>>>> > > > >>> > >> extremely powerful idea.
>>>> > > > >>> > >>
>>>> > > > >>> > >> Note, that at the moment
> service handlers are scheduled
>>>> for
>>>> > CDI
>>>> > > > 1.1.
>>>> > > > >>> > >>
>>>> > > > >>> > >>
>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
> Jason Porter wrote:
>>>> > > > >>> > >>
>>>> > > > >>> > >>> Somewhat. I
> wouldn't really think of them as overrides,
>>>> they,
>>>> > > to
>>>> > > > >>> me,
>>>> > > > >>> > >> seem more like items to
> do in addition to whatever the
>>>> > original
>>>> > > > impl
>>>> > > > >>> > does.
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> ServiceHandlers to me
> seem more like super
>>>> interceptors.
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> Sent from my iPhone
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> On Mar 6, 2012, at
> 19:23, "John D. Ament" <
>>>> > > > john.d.ament@gmail.com>
>>>> > > > >>> > >> wrote:
>>>> > > > >>> > >>>
>>>> > > > >>> > >>>> @jason
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>> I think the
> concepts are very dissimilar.
>>>> servicehandlers
>>>> > > > create
>>>> > > > >>> the
>>>> > > > >>> > >>>> implementation.
> delegates are more like overrides and
>>>> need
>>>> > to
>>>> > > > >>> know
>>>> > > > >>> > >> about
>>>> > > > >>> > >>>> the method
> signature.
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>> On Tue, Mar 6,
> 2012 at 9:17 PM, Jason Porter <
>>>> > > > >>> lightguard.jp@gmail.com
>>>> > > > >>> > >>> wrote:
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>>> I think the
> idea of ServiceHandlers are good, but,
>>>> could
>>>> we
>>>> > > not
>>>> > > > >>> do
>>>> > > > >>> > this
>>>> > > > >>> > >>>>> with
> delegates?
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>> Sent from my
> iPhone
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>> On Mar 6,
> 2012, at 19:05, "John D. Ament" <
>>>> > > > >>> john.d.ament@gmail.com>
>>>> > > > >>> > >> wrote:
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>>> @mark
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> I
> don't think it's a hard requirement for it to be
>>>> on an
>>>> > > > >>> interface.
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> One of
> the best use-cases we built at my job is
>>>> using it
>>>> > for
>>>> > > > >>> calling
>>>> > > > >>> > >>>>>> PL/SQL.
> The JDBC bindings do work, but not pretty.
>>>> we
>>>> > were
>>>> > > > >>> able to
>>>> > > > >>> > >>>>> create
>>>> > > > >>> > >>>>>> a fairly
> clean wrapper API, generic enough for
>>>> binding
>>>> > > in/out
>>>> > > > >>> > >> parameters.
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> JOhn
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> On Tue,
> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>> > > > >>> struberg@yahoo.de>
>>>> > > > >>> > >>>>> wrote:
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>>>
> actually I don't really see a real benefit. I just
>>>> don't
>>>> > > yet
>>>> > > > >>> grok
>>>> > > > >>> > the
>>>> > > > >>> > >>>>> use
>>>> > > > >>> > >>>>>>> case
> for real world projects.
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> Why
> would one intercept an Interface and delegate
>>>> the
>>>> > calls
>>>> > > > to
>>>> > > > >>> a
>>>> > > > >>> > >> method
>>>> > > > >>> > >>>>>>>
> handler?
>>>> > > > >>> > >>>>>>> This
> could be neat for mocking, but there are
>>>> better
>>>> > > > >>> frameworks for
>>>> > > > >>> > >>>>> that.
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> thus
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> -0.2
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>>
> LieGrue,
>>>> > > > >>> > >>>>>>> strub
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> -----
> Original Message -----
>>>> > > > >>> > >>>>>>>>
> From: Gerhard Petracek
>>>> <ge...@gmail.com>
>>>> > > > >>> > >>>>>>>>
> To: deltaspike-dev@incubator.apache.org
>>>> > > > >>> > >>>>>>>>
> Cc:
>>>> > > > >>> > >>>>>>>>
> Sent: Tuesday, March 6, 2012 5:15 PM
>>>> > > > >>> > >>>>>>>>
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>> > Discuss
>>>> > > > >>> > >>>>>
> ServiceHandler
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
> if you have a lot of shared code, you can extract
>>>> it
>>>> in
>>>> > > 1-n
>>>> > > > >>> > >> method/s or
>>>> > > > >>> > >>>>>>> an
>>>> > > > >>> > >>>>>>>>
> abstract class which is still easier than a new
>>>> concept.
>>>> > > > >>> > >>>>>>>>
> at least i haven't seen an use-case which really
>>>> needed
>>>> > > it.
>>>> > > > >>> that
>>>> > > > >>> > was
>>>> > > > >>> > >>>>> the
>>>> > > > >>> > >>>>>>>>
> reason for a +0 (which still means that i'm ok
>>>> with
>>>> > adding
>>>> > > > >>> it).
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
> regards,
>>>> > > > >>> > >>>>>>>>
> gerhard
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> >
>>>>>>>>>> So, you mean just write a bean with all the
>>>> boilerplate
>>>> > > > code
>>>> > > > >>> in
>>>> > > > >>> > it?
>>>> > > > >>> >
>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> wrote:
>>>> > > > >>> >
>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>> hi pete,
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>> instead of the interface you can just
> implement
>>>> a
>>>> bean
>>>> > > > which
>>>> > > > >>> > does
>>>> > > > >>> > >> the
>>>> > > > >>> >
>>>>>>>>>> same.
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>> regards,
>>>> > > > >>> >
>>>>>>>>>>> gerhard
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>> 2012/3/6 Pete Muir
> <pm...@redhat.com>
>>>> > > > >>> >
>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>> What CDI mechanism would you use
> instead?
>>>> > > > >>> >
>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> Petracek
>>>> wrote:
>>>> > > > >>> >
>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>> +0
>>>> > > > >>> >
>>>>>>>>>>>>> no -1 because there are
> use-cases for it.
>>>> > > > >>> >
>>>>>>>>>>>>> no +1 because i would use std.
> cdi mechanisms
>>>> > instead.
>>>> > > > >>> >
>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>> regards,
>>>> > > > >>> >
>>>>>>>>>>>>> gerhard
>>>> > > > >>> >
>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>> > gerhard.petracek@gmail.com
>>>> > > >
>>>> > > > >>> >
>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>> hi john,
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>> the sub-task is perfectly
> fine.
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>> regards,
>>>> > > > >>> >
>>>>>>>>>>>>>> gerhard
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>> <jo...@gmail.com>
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>> Hi All
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>> I wanted to bring up
> the subject of
>>>> > ServiceHandler.
>>>> > > I
>>>> > > > >>> > >>>>>>>>
> added 113 as a
>>>> > > > >>> >
>>>>>>>>>>>>>>> child
>>>> > > > >>> >
>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> appropriate but not
>>>> 100%
>>>> > > sure
>>>> > > > >>> > >>>>>>>>
> (so please let
>>>> > > > >>> >
>>>>>>>>>> me
>>>> > > > >>> >
>>>>>>>>>>>>>>> know if you think
> it's not appropriate as a
>>>> > > > >>> > >>>>>>>>
> child). ServiceHandler
>>>> > > > >>> >
>>>>>>>>>> is
>>>> > > > >>> >
>>>>>>>>>>>> a
>>>> > > > >>> >
>>>>>>>>>>>>>>> feature in Solder that
> allows you to define
>>>> an
>>>> > > > >>> > >>>>>>>>
> interceptor that
>>>> > > > >>> >
>>>>>>>>>> manages
>>>> > > > >>> >
>>>>>>>>>>>>>>> generic calls against
> an injected interface.
>>>> The
>>>> > > API
>>>> > > > >>> > >>>>>>>>
> is as follows:
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>> -
> @ServiceHandlerType(Class<?> clazz) -
>>>> placed
>>>> > > > >>> > >>>>>>>>
> on an annotation that
>>>> > > > >>> >
>>>>>>>>>>>> would
>>>> > > > >>> >
>>>>>>>>>>>>>>> be placed on the
> interface. Indicates what
>>>> > > > >>> > >>>>>>>>
> interceptor would be
>>>> > > > >>> >
>>>>>>>>>>>> invoked
>>>> > > > >>> >
>>>>>>>>>>>>>>> for calls against this
> interface.
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>> It's then up to the
> application
>>>> > > > >>> > >>>>>>>>
> developer/framework author to define
>>>> > > > >>> >
>>>>>>>>>>>>>>> annotations that go on
> methods, as well as
>>>> the
>>>> > > > >>> > >>>>>>>>
> interceptor itself
>>>> > > > >>> >
>>>>>>>>>> that
>>>> > > > >>> >
>>>>>>>>>>>>>>> will
>>>> > > > >>> >
>>>>>>>>>>>>>>> be invoked. The
> feature for ServiceHandler
>>>> would
>>>> > be
>>>> > > > >>> > >>>>>>>>
> to provide the
>>>> > > > >>> >
>>>>>>>>>>>> API of
>>>> > > > >>> >
>>>>>>>>>>>>>>> the type and then the
> infrastructure
>>>> required to
>>>> > > make
>>>> > > > >>> > >>>>>>>>
> the interceptor
>>>> > > > >>> >
>>>>>>>>>>>> be
>>>> > > > >>> >
>>>>>>>>>>>>>>> called. Existing
> documentation of the
>>>> feature:
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>
>>>> > > > >>> >
>>>> > > > >>>
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-ser
>>>> vicehandler.html
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>> Regards,
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>> john
>>>> > > > >>> >
>>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>
>>>> > > > >>> >
>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>
>>>> > > > >>> > >>
>>>> > > > >>> >
>>>> > > > >>> >
>>>> > > > >>>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
+1 for doing it with bindings, I wish I had done it this way the first time around :-)
On 20 Dec 2012, at 09:36, Romain Manni-Bucau wrote:
> yep this one is fine :)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>> That was my first idea, however thinking about it, that wouldn't be much
>> CDI-like ;-)
>>
>> So we would introduce a @InvocationHandlerBinding meta-annotation?
>> Like:
>>
>> @InvocationHandlerBinding
>> public @interface Repository {}
>>
>> @Repository
>> public interface MyRepository {
>> ...
>> }
>>
>> @Repository @InvocationHandler
>> public class MyInvocationHandler implements InvocationHandler {
>> ...
>> }
>>
>> Looks much better, I think...
>>
>> Am 20.12.12 10:24 schrieb "Romain Manni-Bucau" unter
>> <rm...@gmail.com>:
>>
>>> sounds *almost* fine for me
>>>
>>> @Arne: maybe i got it wrong: you link a handler with an interface?
>>>
>>> what is nice with the annotation API is the handler doesn't know about
>>> the interface it proxies
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>>> Two things about this: First: I don't like from the solder approach,
>>>> because the interface is annotated instead of the implementation.
>>>>
>>>> Second, if we implement this we should conceptually make clear how it
>>>> differentiates from Interceptors and Decorators. And personally I think
>>>> this would work better with the InvocationHandler approach than with an
>>>> approach that is very similar to interceptors.
>>>>
>>>> So +1 for an approach like this:
>>>>
>>>> @HandlesInvocationsOn(MyInterface.class)
>>>> public class MyInvocationHandler implements InvocationHandler {
>>>> ...
>>>> }
>>>>
>>>> Technically we would register a custom Bean for every found
>>>> InvocationHandler with that annotation and take over the
>>>> interceptor-bindings from the interfaceŠ
>>>> So the invocation stack would be clear, too:
>>>> First Interceptors,
>>>> Second Decorators,
>>>> Third InvocationHandler
>>>>
>>>> Wdyt?
>>>>
>>>> Arne
>>>>
>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>> <rm...@gmail.com>:
>>>>
>>>>> +1
>>>>>
>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>> part portable ans it should be fine
>>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2012/12/20 Jason Porter <li...@gmail.com>:
>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>> <jo...@gmail.com>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Regarding the two open questions:
>>>>>>>
>>>>>>> 1) the approach (including the name/s) we agree on will be used also
>>>>>>> for
>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>
>>>>>>> It looks like the JSR's answer
>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>> is still unresolved - I'm not sure if we can get any further answer
>>>>>>> at
>>>>>>> this
>>>>>>> time. The last posts on the subject seem to discuss using something
>>>>>>> along
>>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>>> Since
>>>>>>> we have some features coming up that are interested in having service
>>>>>>> handlers available, do we
>>>>>>>
>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>> 2. Push EG on a resolution
>>>>>>> 3. Do it using invocation handlers.
>>>>>>> 4. Do it some other way?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>> gerhard.petracek@gmail.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> hi john,
>>>>>>>>
>>>>>>>> as mentioned before we need the answers to the existing questions.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>>> apologize.
>>>>>>> it
>>>>>>>>> looks like where we last left off, Gerhard was still requesting
>>>>>>>> additional
>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>> gerhard.petracek@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> hi george,
>>>>>>>>>>
>>>>>>>>>> thx for the information. i thought there might be at least some
>>>>>>>>> additional
>>>>>>>>>> answers/clarifications, since pete asked for them in several
>>>>>>> comments.
>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/12 George Gastaldi <ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>
>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite old, but I
>>>>>>> haven´t had
>>>>>>>>> time
>>>>>>>>>>> to work on it after that.
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> George
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> hi george,
>>>>>>>>>>>>
>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>> i'm not sure if it is the latest state of your discussion
>>>>>>> and/or
>>>>>>>> draft
>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1 to #1. I also agree that the term "Service Handler"
>>>>>>> might
>>>>>>> not
>>>>>>> be
>>>>>>>>> so
>>>>>>>>>>>>> appropriate, so it should be discussed as well.
>>>>>>>>>>>>> Here is the latest pull request with some comments from
>>>>>>> Pete
>>>>>>> yet
>>>>>>> to
>>>>>>>>> be
>>>>>>>>>>>>> reviewed: https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> George is working on it for CDI 1.1. George, can you
>>>>>>> share
>>>>>>> your
>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> independent of my opinion about the feature (which is
>>>>>>> still
>>>>>>>> +0):
>>>>>>>>>>>>>>> if it should be part of cdi 1.1, we have the following
>>>>>>> options
>>>>>>>>> imo:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) the approach (including the name/s) we agree on will
>>>>>>> be
>>>>>>> used
>>>>>>>>>> also
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>>>>>>> 2a) the rest of the eg joins this discussion
>>>>>>>>>>>>>>> 2b) we wait for the final version and just allow the
>>>>>>> same
>>>>>>> with
>>>>>>>>> cdi
>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>> 3) if the eg doesn't agree on the idea, it should be
>>>>>>> re-visited
>>>>>>>>> for
>>>>>>>>>>>>>>> deltaspike (if we really need it)
>>>>>>>>>>>>>>> 4) we agree on it independent of the result in cdi 1.1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for #4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure what you mean by a "super interceptor",
>>>>>>> but if
>>>>>>>> you
>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>> in "super man" (something better than an interceptor),
>>>>>>> then
>>>>>>> I
>>>>>>>>>> would
>>>>>>>>>>>>>>>> disagree, it's actually a specialised form of
>>>>>>> interceptor.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The best use case I know of is the one John mentions -
>>>>>>>> creating
>>>>>>>>>> type
>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Query("select u from User u")
>>>>>>>>>>>>>>>> public List<User> getAllUsers();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Query("select u from User u order by u.name")
>>>>>>>>>>>>>>>> public List<User> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now, it may be the case that there aren't any other
>>>>>>> use
>>>>>>> cases
>>>>>>>>> for
>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>> handlers, in which case we should perhaps just offer
>>>>>>> this
>>>>>>>>>> particular
>>>>>>>>>>>>>>>> service handler - references to type safe queries -
>>>>>>> as I
>>>>>>> think
>>>>>>>>>> this
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note, that at the moment service handlers are
>>>>>>> scheduled
>>>>>>> for
>>>>>>>> CDI
>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Somewhat. I wouldn't really think of them as
>>>>>>> overrides,
>>>>>>> they,
>>>>>>>>> to
>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>> seem more like items to do in addition to whatever the
>>>>>>>> original
>>>>>>>>>> impl
>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ServiceHandlers to me seem more like super
>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think the concepts are very dissimilar.
>>>>>>> servicehandlers
>>>>>>>>>> create
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> implementation. delegates are more like overrides
>>>>>>> and
>>>>>>> need
>>>>>>>> to
>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> the method signature.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>> lightguard.jp@gmail.com
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think the idea of ServiceHandlers are good, but,
>>>>>>> could
>>>>>>> we
>>>>>>>>> not
>>>>>>>>>>>>> do
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> with delegates?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>> john.d.ament@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't think it's a hard requirement for it to be
>>>>>>> on an
>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> One of the best use-cases we built at my job is
>>>>>>> using it
>>>>>>>> for
>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>> PL/SQL. The JDBC bindings do work, but not
>>>>>>> pretty.
>>>>>>> we
>>>>>>>> were
>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>> a fairly clean wrapper API, generic enough for
>>>>>>> binding
>>>>>>>>> in/out
>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>> struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> actually I don't really see a real benefit. I
>>>>>>> just
>>>>>>> don't
>>>>>>>>> yet
>>>>>>>>>>>>> grok
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> case for real world projects.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why would one intercept an Interface and delegate
>>>>>>> the
>>>>>>>> calls
>>>>>>>>>> to
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>> This could be neat for mocking, but there are
>>>>>>> better
>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>>>>> From: Gerhard Petracek
>>>>>>> <ge...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review
>>>>>>> and
>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> if you have a lot of shared code, you can
>>>>>>> extract
>>>>>>> it
>>>>>>> in
>>>>>>>>> 1-n
>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> abstract class which is still easier than a new
>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>> at least i haven't seen an use-case which really
>>>>>>> needed
>>>>>>>>> it.
>>>>>>>>>>>>> that
>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>> with
>>>>>>>> adding
>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>> boilerplate
>>>>>>>>>> code
>>>>>>>>>>>>> in
>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>>> implement
>>>>>>> a
>>>>>>> bean
>>>>>>>>>> which
>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> What CDI mechanism would you use instead?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>>>>>>>>>>> no -1 because there are use-cases for it.
>>>>>>>>>>>>>>>>>>>>>>>>>> no +1 because i would use std. cdi
>>>>>>> mechanisms
>>>>>>>> instead.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>> gerhard.petracek@gmail.com
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>> <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to bring up the subject of
>>>>>>>> ServiceHandler.
>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>> added 113 as a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but
>>>>>>> not
>>>>>>> 100%
>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>> (so please let
>>>>>>>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>>>>>>>>>>> know if you think it's not appropriate as
>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> feature in Solder that allows you to
>>>>>>> define
>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> interceptor that
>>>>>>>>>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>>>>>>>>>>>>> generic calls against an injected
>>>>>>> interface.
>>>>>>> The
>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>> is as follows:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) -
>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>> on an annotation that
>>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>>>>>> be placed on the interface. Indicates
>>>>>>> what
>>>>>>>>>>>>>>>>>>>>>> interceptor would be
>>>>>>>>>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>>>>>>>>>>>>> for calls against this interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's then up to the application
>>>>>>>>>>>>>>>>>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>>>>>>>>>>>>> annotations that go on methods, as well as
>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> interceptor itself
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>>>>> be invoked. The feature for
>>>>>>> ServiceHandler
>>>>>>> would
>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> to provide the
>>>>>>>>>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the type and then the infrastructure
>>>>>>> required to
>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>> the interceptor
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> called. Existing documentation of the
>>>>>>> feature:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-s
>>>>>>> er
>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason Porter
>>>>>> http://lightguard-jp.blogspot.com
>>>>>> http://twitter.com/lightguardjp
>>>>>>
>>>>>> Software Engineer
>>>>>> Open Source Advocate
>>>>>>
>>>>>> PGP key id: 926CCFF5
>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep this one is fine :)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> That was my first idea, however thinking about it, that wouldn't be much
> CDI-like ;-)
>
> So we would introduce a @InvocationHandlerBinding meta-annotation?
> Like:
>
> @InvocationHandlerBinding
> public @interface Repository {}
>
> @Repository
> public interface MyRepository {
> ...
> }
>
> @Repository @InvocationHandler
> public class MyInvocationHandler implements InvocationHandler {
> ...
> }
>
> Looks much better, I think...
>
> Am 20.12.12 10:24 schrieb "Romain Manni-Bucau" unter
> <rm...@gmail.com>:
>
>>sounds *almost* fine for me
>>
>>@Arne: maybe i got it wrong: you link a handler with an interface?
>>
>>what is nice with the annotation API is the handler doesn't know about
>>the interface it proxies
>>
>>Romain Manni-Bucau
>>Twitter: @rmannibucau
>>Blog: http://rmannibucau.wordpress.com/
>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>Github: https://github.com/rmannibucau
>>
>>
>>
>>2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>>> Two things about this: First: I don't like from the solder approach,
>>> because the interface is annotated instead of the implementation.
>>>
>>> Second, if we implement this we should conceptually make clear how it
>>> differentiates from Interceptors and Decorators. And personally I think
>>> this would work better with the InvocationHandler approach than with an
>>> approach that is very similar to interceptors.
>>>
>>> So +1 for an approach like this:
>>>
>>> @HandlesInvocationsOn(MyInterface.class)
>>> public class MyInvocationHandler implements InvocationHandler {
>>> ...
>>> }
>>>
>>> Technically we would register a custom Bean for every found
>>> InvocationHandler with that annotation and take over the
>>> interceptor-bindings from the interfaceŠ
>>> So the invocation stack would be clear, too:
>>> First Interceptors,
>>> Second Decorators,
>>> Third InvocationHandler
>>>
>>> Wdyt?
>>>
>>> Arne
>>>
>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>> <rm...@gmail.com>:
>>>
>>>>+1
>>>>
>>>>that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>part portable ans it should be fine
>>>>
>>>>Romain Manni-Bucau
>>>>Twitter: @rmannibucau
>>>>Blog: http://rmannibucau.wordpress.com/
>>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>>2012/12/20 Jason Porter <li...@gmail.com>:
>>>>> At this point, I'd say just do it as is in solder.
>>>>>
>>>>>
>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>><jo...@gmail.com>wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Regarding the two open questions:
>>>>>>
>>>>>> 1) the approach (including the name/s) we agree on will be used also
>>>>>>for
>>>>>> cdi 1.1 (the only difference is the package)
>>>>>> 2) the eg has a different opinion about it ->
>>>>>>
>>>>>> It looks like the JSR's answer
>>>>>>(https://issues.jboss.org/browse/CDI-110 )
>>>>>> is still unresolved - I'm not sure if we can get any further answer
>>>>>>at
>>>>>>this
>>>>>> time. The last posts on the subject seem to discuss using something
>>>>>>along
>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>>Since
>>>>>> we have some features coming up that are interested in having service
>>>>>> handlers available, do we
>>>>>>
>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>> 2. Push EG on a resolution
>>>>>> 3. Do it using invocation handlers.
>>>>>> 4. Do it some other way?
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>> gerhard.petracek@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>> > hi john,
>>>>>> >
>>>>>> > as mentioned before we need the answers to the existing questions.
>>>>>> >
>>>>>> > regards,
>>>>>> > gerhard
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>>> >
>>>>>> > > All,
>>>>>> > >
>>>>>> > > I kind of let this one and the other drop off my radar, I
>>>>>>apologize.
>>>>>> it
>>>>>> > > looks like where we last left off, Gerhard was still requesting
>>>>>> > additional
>>>>>> > > comments from everyone. Any other feedback?
>>>>>> > >
>>>>>> > > John
>>>>>> > >
>>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>> > > gerhard.petracek@gmail.com> wrote:
>>>>>> > >
>>>>>> > > > hi george,
>>>>>> > > >
>>>>>> > > > thx for the information. i thought there might be at least some
>>>>>> > > additional
>>>>>> > > > answers/clarifications, since pete asked for them in several
>>>>>> comments.
>>>>>> > > > -> imo we should continue with them.
>>>>>> > > >
>>>>>> > > > regards,
>>>>>> > > > gerhard
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
>>>>>> > > >
>>>>>> > > > > Hello Gerhard,
>>>>>> > > > >
>>>>>> > > > > Yeah, it´s the last state. I know it´s quite old, but I
>>>>>>haven´t had
>>>>>> > > time
>>>>>> > > > > to work on it after that.
>>>>>> > > > > Regards,
>>>>>> > > > >
>>>>>> > > > > George
>>>>>> > > > >
>>>>>> > > > >
>>>>>> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>>>>>> > > > >
>>>>>> > > > >> hi george,
>>>>>> > > > >>
>>>>>> > > > >> thx for the link.
>>>>>> > > > >> i'm not sure if it is the latest state of your discussion
>>>>>>and/or
>>>>>> > draft
>>>>>> > > > >> (at least it's quite old already).
>>>>>> > > > >>
>>>>>> > > > >> regards,
>>>>>> > > > >> gerhard
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>>>>> > > > >>
>>>>>> > > > >>> Hi !
>>>>>> > > > >>>
>>>>>> > > > >>> +1 to #1. I also agree that the term "Service Handler"
>>>>>>might
>>>>>>not
>>>>>> be
>>>>>> > > so
>>>>>> > > > >>> appropriate, so it should be discussed as well.
>>>>>> > > > >>> Here is the latest pull request with some comments from
>>>>>>Pete
>>>>>>yet
>>>>>> to
>>>>>> > > be
>>>>>> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
>>>>>> > > > >>>
>>>>>> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>>> > > > >>>
>>>>>> > > > >>> > Agreed :-)
>>>>>> > > > >>> >
>>>>>> > > > >>> > George is working on it for CDI 1.1. George, can you
>>>>>>share
>>>>>>your
>>>>>> > > > >>> proposal
>>>>>> > > > >>> > so far?
>>>>>> > > > >>> >
>>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>>>>> > > > >>> >
>>>>>> > > > >>> > > hi pete,
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > independent of my opinion about the feature (which is
>>>>>>still
>>>>>> > +0):
>>>>>> > > > >>> > > if it should be part of cdi 1.1, we have the following
>>>>>> options
>>>>>> > > imo:
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 1) the approach (including the name/s) we agree on will
>>>>>>be
>>>>>> used
>>>>>> > > > also
>>>>>> > > > >>> for
>>>>>> > > > >>> > > cdi 1.1 (the only difference is the package)
>>>>>> > > > >>> > > 2) the eg has a different opinion about it ->
>>>>>> > > > >>> > > 2a) the rest of the eg joins this discussion
>>>>>> > > > >>> > > 2b) we wait for the final version and just allow the
>>>>>>same
>>>>>> with
>>>>>> > > cdi
>>>>>> > > > >>> 1.0
>>>>>> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
>>>>>> re-visited
>>>>>> > > for
>>>>>> > > > >>> > > deltaspike (if we really need it)
>>>>>> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 1-3 is ok for me but -1 for #4
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > regards,
>>>>>> > > > >>> > > gerhard
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >
>>>>>> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>>> > > > >>> > >
>>>>>> > > > >>> > >> I'm not sure what you mean by a "super interceptor",
>>>>>>but if
>>>>>> > you
>>>>>> > > > >>> mean it
>>>>>> > > > >>> > as
>>>>>> > > > >>> > >> in "super man" (something better than an interceptor),
>>>>>>then
>>>>>> I
>>>>>> > > > would
>>>>>> > > > >>> > >> disagree, it's actually a specialised form of
>>>>>>interceptor.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> The best use case I know of is the one John mentions -
>>>>>> > creating
>>>>>> > > > type
>>>>>> > > > >>> > safe
>>>>>> > > > >>> > >> references to queries:
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @QueryService
>>>>>> > > > >>> > >> interface UserQuery {
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @Query("select u from User u")
>>>>>> > > > >>> > >> public List<User> getAllUsers();
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> @Query("select u from User u order by u.name")
>>>>>> > > > >>> > >> public List<User> getAllUsersSortedByName();
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> }
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> Now, it may be the case that there aren't any other
>>>>>>use
>>>>>> cases
>>>>>> > > for
>>>>>> > > > >>> > service
>>>>>> > > > >>> > >> handlers, in which case we should perhaps just offer
>>>>>>this
>>>>>> > > > particular
>>>>>> > > > >>> > >> service handler - references to type safe queries -
>>>>>>as I
>>>>>> think
>>>>>> > > > this
>>>>>> > > > >>> is
>>>>>> > > > >>> > an
>>>>>> > > > >>> > >> extremely powerful idea.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> Note, that at the moment service handlers are
>>>>>>scheduled
>>>>>>for
>>>>>> > CDI
>>>>>> > > > 1.1.
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>> Somewhat. I wouldn't really think of them as
>>>>>>overrides,
>>>>>> they,
>>>>>> > > to
>>>>>> > > > >>> me,
>>>>>> > > > >>> > >> seem more like items to do in addition to whatever the
>>>>>> > original
>>>>>> > > > impl
>>>>>> > > > >>> > does.
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> ServiceHandlers to me seem more like super
>>>>>>interceptors.
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> Sent from my iPhone
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>>>>>> > > > john.d.ament@gmail.com>
>>>>>> > > > >>> > >> wrote:
>>>>>> > > > >>> > >>>
>>>>>> > > > >>> > >>>> @jason
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>> I think the concepts are very dissimilar.
>>>>>>servicehandlers
>>>>>> > > > create
>>>>>> > > > >>> the
>>>>>> > > > >>> > >>>> implementation. delegates are more like overrides
>>>>>>and
>>>>>> need
>>>>>> > to
>>>>>> > > > >>> know
>>>>>> > > > >>> > >> about
>>>>>> > > > >>> > >>>> the method signature.
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>>>>> > > > >>> lightguard.jp@gmail.com
>>>>>> > > > >>> > >>> wrote:
>>>>>> > > > >>> > >>>>
>>>>>> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but,
>>>>>>could
>>>>>> we
>>>>>> > > not
>>>>>> > > > >>> do
>>>>>> > > > >>> > this
>>>>>> > > > >>> > >>>>> with delegates?
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>> Sent from my iPhone
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>>>>> > > > >>> john.d.ament@gmail.com>
>>>>>> > > > >>> > >> wrote:
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>>>>> @mark
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be
>>>>>>on an
>>>>>> > > > >>> interface.
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> One of the best use-cases we built at my job is
>>>>>>using it
>>>>>> > for
>>>>>> > > > >>> calling
>>>>>> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not
>>>>>>pretty.
>>>>>> we
>>>>>> > were
>>>>>> > > > >>> able to
>>>>>> > > > >>> > >>>>> create
>>>>>> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for
>>>>>>binding
>>>>>> > > in/out
>>>>>> > > > >>> > >> parameters.
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> JOhn
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>> > > > >>> struberg@yahoo.de>
>>>>>> > > > >>> > >>>>> wrote:
>>>>>> > > > >>> > >>>>>>
>>>>>> > > > >>> > >>>>>>> actually I don't really see a real benefit. I
>>>>>>just
>>>>>> don't
>>>>>> > > yet
>>>>>> > > > >>> grok
>>>>>> > > > >>> > the
>>>>>> > > > >>> > >>>>> use
>>>>>> > > > >>> > >>>>>>> case for real world projects.
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate
>>>>>>the
>>>>>> > calls
>>>>>> > > > to
>>>>>> > > > >>> a
>>>>>> > > > >>> > >> method
>>>>>> > > > >>> > >>>>>>> handler?
>>>>>> > > > >>> > >>>>>>> This could be neat for mocking, but there are
>>>>>>better
>>>>>> > > > >>> frameworks for
>>>>>> > > > >>> > >>>>> that.
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> thus
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> -0.2
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> LieGrue,
>>>>>> > > > >>> > >>>>>>> strub
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>>> ----- Original Message -----
>>>>>> > > > >>> > >>>>>>>> From: Gerhard Petracek
>>>>>><ge...@gmail.com>
>>>>>> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>> > > > >>> > >>>>>>>> Cc:
>>>>>> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review
>>>>>>and
>>>>>> > Discuss
>>>>>> > > > >>> > >>>>> ServiceHandler
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>> if you have a lot of shared code, you can
>>>>>>extract
>>>>>>it
>>>>>> in
>>>>>> > > 1-n
>>>>>> > > > >>> > >> method/s or
>>>>>> > > > >>> > >>>>>>> an
>>>>>> > > > >>> > >>>>>>>> abstract class which is still easier than a new
>>>>>> concept.
>>>>>> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
>>>>>> needed
>>>>>> > > it.
>>>>>> > > > >>> that
>>>>>> > > > >>> > was
>>>>>> > > > >>> > >>>>> the
>>>>>> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>with
>>>>>> > adding
>>>>>> > > > >>> it).
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>> regards,
>>>>>> > > > >>> > >>>>>>>> gerhard
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
>>>>>> boilerplate
>>>>>> > > > code
>>>>>> > > > >>> in
>>>>>> > > > >>> > it?
>>>>>> > > > >>> > >>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>>wrote:
>>>>>> > > > >>> > >>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>> hi pete,
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>> instead of the interface you can just
>>>>>>implement
>>>>>>a
>>>>>> bean
>>>>>> > > > which
>>>>>> > > > >>> > does
>>>>>> > > > >>> > >> the
>>>>>> > > > >>> > >>>>>>>>> same.
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>> regards,
>>>>>> > > > >>> > >>>>>>>>>> gerhard
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>> > > > >>> > >>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>>>>>> > > > >>> > >>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek
>>>>>>wrote:
>>>>>> > > > >>> > >>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>> +0
>>>>>> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>>>>>> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi
>>>>>>mechanisms
>>>>>> > instead.
>>>>>> > > > >>> > >>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>> regards,
>>>>>> > > > >>> > >>>>>>>>>>>> gerhard
>>>>>> > > > >>> > >>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>> > gerhard.petracek@gmail.com
>>>>>> > > >
>>>>>> > > > >>> > >>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>> hi john,
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>> regards,
>>>>>> > > > >>> > >>>>>>>>>>>>> gerhard
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>><jo...@gmail.com>
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>> Hi All
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
>>>>>> > ServiceHandler.
>>>>>> > > I
>>>>>> > > > >>> > >>>>>>>> added 113 as a
>>>>>> > > > >>> > >>>>>>>>>>>>>> child
>>>>>> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but
>>>>>>not
>>>>>>100%
>>>>>> > > sure
>>>>>> > > > >>> > >>>>>>>> (so please let
>>>>>> > > > >>> > >>>>>>>>> me
>>>>>> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as
>>>>>>a
>>>>>> > > > >>> > >>>>>>>> child). ServiceHandler
>>>>>> > > > >>> > >>>>>>>>> is
>>>>>> > > > >>> > >>>>>>>>>>> a
>>>>>> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to
>>>>>>define
>>>>>>an
>>>>>> > > > >>> > >>>>>>>> interceptor that
>>>>>> > > > >>> > >>>>>>>>> manages
>>>>>> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected
>>>>>>interface.
>>>>>> The
>>>>>> > > API
>>>>>> > > > >>> > >>>>>>>> is as follows:
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) -
>>>>>>placed
>>>>>> > > > >>> > >>>>>>>> on an annotation that
>>>>>> > > > >>> > >>>>>>>>>>> would
>>>>>> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates
>>>>>>what
>>>>>> > > > >>> > >>>>>>>> interceptor would be
>>>>>> > > > >>> > >>>>>>>>>>> invoked
>>>>>> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
>>>>>> > > > >>> > >>>>>>>> developer/framework author to define
>>>>>> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as
>>>>>>the
>>>>>> > > > >>> > >>>>>>>> interceptor itself
>>>>>> > > > >>> > >>>>>>>>> that
>>>>>> > > > >>> > >>>>>>>>>>>>>> will
>>>>>> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for
>>>>>>ServiceHandler
>>>>>> would
>>>>>> > be
>>>>>> > > > >>> > >>>>>>>> to provide the
>>>>>> > > > >>> > >>>>>>>>>>> API of
>>>>>> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure
>>>>>>required to
>>>>>> > > make
>>>>>> > > > >>> > >>>>>>>> the interceptor
>>>>>> > > > >>> > >>>>>>>>>>> be
>>>>>> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the
>>>>>>feature:
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> >
>>>>>> > > > >>>
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-s
>>>>>>er
>>>>>>vicehandler.html
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>> Regards,
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>> john
>>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>>
>>>>>> > > > >>> > >>>>>>>>
>>>>>> > > > >>> > >>>>>>>
>>>>>> > > > >>> > >>>>>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> > >>
>>>>>> > > > >>> >
>>>>>> > > > >>> >
>>>>>> > > > >>>
>>>>>> > > > >>
>>>>>> > > > >>
>>>>>> > > > >
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> http://lightguard-jp.blogspot.com
>>>>> http://twitter.com/lightguardjp
>>>>>
>>>>> Software Engineer
>>>>> Open Source Advocate
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Arne Limburg <ar...@openknowledge.de>.
That was my first idea, however thinking about it, that wouldn't be much
CDI-like ;-)
So we would introduce a @InvocationHandlerBinding meta-annotation?
Like:
@InvocationHandlerBinding
public @interface Repository {}
@Repository
public interface MyRepository {
...
}
@Repository @InvocationHandler
public class MyInvocationHandler implements InvocationHandler {
...
}
Looks much better, I think...
Am 20.12.12 10:24 schrieb "Romain Manni-Bucau" unter
<rm...@gmail.com>:
>sounds *almost* fine for me
>
>@Arne: maybe i got it wrong: you link a handler with an interface?
>
>what is nice with the annotation API is the handler doesn't know about
>the interface it proxies
>
>Romain Manni-Bucau
>Twitter: @rmannibucau
>Blog: http://rmannibucau.wordpress.com/
>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>Github: https://github.com/rmannibucau
>
>
>
>2012/12/20 Arne Limburg <ar...@openknowledge.de>:
>> Two things about this: First: I don't like from the solder approach,
>> because the interface is annotated instead of the implementation.
>>
>> Second, if we implement this we should conceptually make clear how it
>> differentiates from Interceptors and Decorators. And personally I think
>> this would work better with the InvocationHandler approach than with an
>> approach that is very similar to interceptors.
>>
>> So +1 for an approach like this:
>>
>> @HandlesInvocationsOn(MyInterface.class)
>> public class MyInvocationHandler implements InvocationHandler {
>> ...
>> }
>>
>> Technically we would register a custom Bean for every found
>> InvocationHandler with that annotation and take over the
>> interceptor-bindings from the interfaceŠ
>> So the invocation stack would be clear, too:
>> First Interceptors,
>> Second Decorators,
>> Third InvocationHandler
>>
>> Wdyt?
>>
>> Arne
>>
>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>> <rm...@gmail.com>:
>>
>>>+1
>>>
>>>that's a need, DS targets CDI 1.0 for now so just make this solder
>>>part portable ans it should be fine
>>>
>>>Romain Manni-Bucau
>>>Twitter: @rmannibucau
>>>Blog: http://rmannibucau.wordpress.com/
>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>>2012/12/20 Jason Porter <li...@gmail.com>:
>>>> At this point, I'd say just do it as is in solder.
>>>>
>>>>
>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>><jo...@gmail.com>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Regarding the two open questions:
>>>>>
>>>>> 1) the approach (including the name/s) we agree on will be used also
>>>>>for
>>>>> cdi 1.1 (the only difference is the package)
>>>>> 2) the eg has a different opinion about it ->
>>>>>
>>>>> It looks like the JSR's answer
>>>>>(https://issues.jboss.org/browse/CDI-110 )
>>>>> is still unresolved - I'm not sure if we can get any further answer
>>>>>at
>>>>>this
>>>>> time. The last posts on the subject seem to discuss using something
>>>>>along
>>>>> the lines of an invocation handler, which I think would work well.
>>>>>Since
>>>>> we have some features coming up that are interested in having service
>>>>> handlers available, do we
>>>>>
>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>> 2. Push EG on a resolution
>>>>> 3. Do it using invocation handlers.
>>>>> 4. Do it some other way?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>> gerhard.petracek@gmail.com
>>>>> > wrote:
>>>>>
>>>>> > hi john,
>>>>> >
>>>>> > as mentioned before we need the answers to the existing questions.
>>>>> >
>>>>> > regards,
>>>>> > gerhard
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>>> >
>>>>> > > All,
>>>>> > >
>>>>> > > I kind of let this one and the other drop off my radar, I
>>>>>apologize.
>>>>> it
>>>>> > > looks like where we last left off, Gerhard was still requesting
>>>>> > additional
>>>>> > > comments from everyone. Any other feedback?
>>>>> > >
>>>>> > > John
>>>>> > >
>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>> > > gerhard.petracek@gmail.com> wrote:
>>>>> > >
>>>>> > > > hi george,
>>>>> > > >
>>>>> > > > thx for the information. i thought there might be at least some
>>>>> > > additional
>>>>> > > > answers/clarifications, since pete asked for them in several
>>>>> comments.
>>>>> > > > -> imo we should continue with them.
>>>>> > > >
>>>>> > > > regards,
>>>>> > > > gerhard
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
>>>>> > > >
>>>>> > > > > Hello Gerhard,
>>>>> > > > >
>>>>> > > > > Yeah, it´s the last state. I know it´s quite old, but I
>>>>>haven´t had
>>>>> > > time
>>>>> > > > > to work on it after that.
>>>>> > > > > Regards,
>>>>> > > > >
>>>>> > > > > George
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>>>>> > > > >
>>>>> > > > >> hi george,
>>>>> > > > >>
>>>>> > > > >> thx for the link.
>>>>> > > > >> i'm not sure if it is the latest state of your discussion
>>>>>and/or
>>>>> > draft
>>>>> > > > >> (at least it's quite old already).
>>>>> > > > >>
>>>>> > > > >> regards,
>>>>> > > > >> gerhard
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>>>> > > > >>
>>>>> > > > >>> Hi !
>>>>> > > > >>>
>>>>> > > > >>> +1 to #1. I also agree that the term "Service Handler"
>>>>>might
>>>>>not
>>>>> be
>>>>> > > so
>>>>> > > > >>> appropriate, so it should be discussed as well.
>>>>> > > > >>> Here is the latest pull request with some comments from
>>>>>Pete
>>>>>yet
>>>>> to
>>>>> > > be
>>>>> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
>>>>> > > > >>>
>>>>> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>> > > > >>>
>>>>> > > > >>> > Agreed :-)
>>>>> > > > >>> >
>>>>> > > > >>> > George is working on it for CDI 1.1. George, can you
>>>>>share
>>>>>your
>>>>> > > > >>> proposal
>>>>> > > > >>> > so far?
>>>>> > > > >>> >
>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>>>> > > > >>> >
>>>>> > > > >>> > > hi pete,
>>>>> > > > >>> > >
>>>>> > > > >>> > > independent of my opinion about the feature (which is
>>>>>still
>>>>> > +0):
>>>>> > > > >>> > > if it should be part of cdi 1.1, we have the following
>>>>> options
>>>>> > > imo:
>>>>> > > > >>> > >
>>>>> > > > >>> > > 1) the approach (including the name/s) we agree on will
>>>>>be
>>>>> used
>>>>> > > > also
>>>>> > > > >>> for
>>>>> > > > >>> > > cdi 1.1 (the only difference is the package)
>>>>> > > > >>> > > 2) the eg has a different opinion about it ->
>>>>> > > > >>> > > 2a) the rest of the eg joins this discussion
>>>>> > > > >>> > > 2b) we wait for the final version and just allow the
>>>>>same
>>>>> with
>>>>> > > cdi
>>>>> > > > >>> 1.0
>>>>> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
>>>>> re-visited
>>>>> > > for
>>>>> > > > >>> > > deltaspike (if we really need it)
>>>>> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
>>>>> > > > >>> > >
>>>>> > > > >>> > > 1-3 is ok for me but -1 for #4
>>>>> > > > >>> > >
>>>>> > > > >>> > > regards,
>>>>> > > > >>> > > gerhard
>>>>> > > > >>> > >
>>>>> > > > >>> > >
>>>>> > > > >>> > >
>>>>> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>>>>> > > > >>> > >
>>>>> > > > >>> > >> I'm not sure what you mean by a "super interceptor",
>>>>>but if
>>>>> > you
>>>>> > > > >>> mean it
>>>>> > > > >>> > as
>>>>> > > > >>> > >> in "super man" (something better than an interceptor),
>>>>>then
>>>>> I
>>>>> > > > would
>>>>> > > > >>> > >> disagree, it's actually a specialised form of
>>>>>interceptor.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> The best use case I know of is the one John mentions -
>>>>> > creating
>>>>> > > > type
>>>>> > > > >>> > safe
>>>>> > > > >>> > >> references to queries:
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @QueryService
>>>>> > > > >>> > >> interface UserQuery {
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @Query("select u from User u")
>>>>> > > > >>> > >> public List<User> getAllUsers();
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> @Query("select u from User u order by u.name")
>>>>> > > > >>> > >> public List<User> getAllUsersSortedByName();
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> }
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> Now, it may be the case that there aren't any other
>>>>>use
>>>>> cases
>>>>> > > for
>>>>> > > > >>> > service
>>>>> > > > >>> > >> handlers, in which case we should perhaps just offer
>>>>>this
>>>>> > > > particular
>>>>> > > > >>> > >> service handler - references to type safe queries -
>>>>>as I
>>>>> think
>>>>> > > > this
>>>>> > > > >>> is
>>>>> > > > >>> > an
>>>>> > > > >>> > >> extremely powerful idea.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> Note, that at the moment service handlers are
>>>>>scheduled
>>>>>for
>>>>> > CDI
>>>>> > > > 1.1.
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>
>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>> Somewhat. I wouldn't really think of them as
>>>>>overrides,
>>>>> they,
>>>>> > > to
>>>>> > > > >>> me,
>>>>> > > > >>> > >> seem more like items to do in addition to whatever the
>>>>> > original
>>>>> > > > impl
>>>>> > > > >>> > does.
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> ServiceHandlers to me seem more like super
>>>>>interceptors.
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> Sent from my iPhone
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>>>>> > > > john.d.ament@gmail.com>
>>>>> > > > >>> > >> wrote:
>>>>> > > > >>> > >>>
>>>>> > > > >>> > >>>> @jason
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>> I think the concepts are very dissimilar.
>>>>>servicehandlers
>>>>> > > > create
>>>>> > > > >>> the
>>>>> > > > >>> > >>>> implementation. delegates are more like overrides
>>>>>and
>>>>> need
>>>>> > to
>>>>> > > > >>> know
>>>>> > > > >>> > >> about
>>>>> > > > >>> > >>>> the method signature.
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>>>> > > > >>> lightguard.jp@gmail.com
>>>>> > > > >>> > >>> wrote:
>>>>> > > > >>> > >>>>
>>>>> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but,
>>>>>could
>>>>> we
>>>>> > > not
>>>>> > > > >>> do
>>>>> > > > >>> > this
>>>>> > > > >>> > >>>>> with delegates?
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>> Sent from my iPhone
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>>>> > > > >>> john.d.ament@gmail.com>
>>>>> > > > >>> > >> wrote:
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>>>>> @mark
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be
>>>>>on an
>>>>> > > > >>> interface.
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> One of the best use-cases we built at my job is
>>>>>using it
>>>>> > for
>>>>> > > > >>> calling
>>>>> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not
>>>>>pretty.
>>>>> we
>>>>> > were
>>>>> > > > >>> able to
>>>>> > > > >>> > >>>>> create
>>>>> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for
>>>>>binding
>>>>> > > in/out
>>>>> > > > >>> > >> parameters.
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> JOhn
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>> > > > >>> struberg@yahoo.de>
>>>>> > > > >>> > >>>>> wrote:
>>>>> > > > >>> > >>>>>>
>>>>> > > > >>> > >>>>>>> actually I don't really see a real benefit. I
>>>>>just
>>>>> don't
>>>>> > > yet
>>>>> > > > >>> grok
>>>>> > > > >>> > the
>>>>> > > > >>> > >>>>> use
>>>>> > > > >>> > >>>>>>> case for real world projects.
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate
>>>>>the
>>>>> > calls
>>>>> > > > to
>>>>> > > > >>> a
>>>>> > > > >>> > >> method
>>>>> > > > >>> > >>>>>>> handler?
>>>>> > > > >>> > >>>>>>> This could be neat for mocking, but there are
>>>>>better
>>>>> > > > >>> frameworks for
>>>>> > > > >>> > >>>>> that.
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> thus
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> -0.2
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> LieGrue,
>>>>> > > > >>> > >>>>>>> strub
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>>> ----- Original Message -----
>>>>> > > > >>> > >>>>>>>> From: Gerhard Petracek
>>>>><ge...@gmail.com>
>>>>> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>> > > > >>> > >>>>>>>> Cc:
>>>>> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review
>>>>>and
>>>>> > Discuss
>>>>> > > > >>> > >>>>> ServiceHandler
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>> if you have a lot of shared code, you can
>>>>>extract
>>>>>it
>>>>> in
>>>>> > > 1-n
>>>>> > > > >>> > >> method/s or
>>>>> > > > >>> > >>>>>>> an
>>>>> > > > >>> > >>>>>>>> abstract class which is still easier than a new
>>>>> concept.
>>>>> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
>>>>> needed
>>>>> > > it.
>>>>> > > > >>> that
>>>>> > > > >>> > was
>>>>> > > > >>> > >>>>> the
>>>>> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok
>>>>>with
>>>>> > adding
>>>>> > > > >>> it).
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>> regards,
>>>>> > > > >>> > >>>>>>>> gerhard
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
>>>>> boilerplate
>>>>> > > > code
>>>>> > > > >>> in
>>>>> > > > >>> > it?
>>>>> > > > >>> > >>>>>>>>>
>>>>> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>wrote:
>>>>> > > > >>> > >>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>> hi pete,
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>> instead of the interface you can just
>>>>>implement
>>>>>a
>>>>> bean
>>>>> > > > which
>>>>> > > > >>> > does
>>>>> > > > >>> > >> the
>>>>> > > > >>> > >>>>>>>>> same.
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>> regards,
>>>>> > > > >>> > >>>>>>>>>> gerhard
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>> > > > >>> > >>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>>>>> > > > >>> > >>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek
>>>>>wrote:
>>>>> > > > >>> > >>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>> +0
>>>>> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>>>>> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi
>>>>>mechanisms
>>>>> > instead.
>>>>> > > > >>> > >>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>> regards,
>>>>> > > > >>> > >>>>>>>>>>>> gerhard
>>>>> > > > >>> > >>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>> > gerhard.petracek@gmail.com
>>>>> > > >
>>>>> > > > >>> > >>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>> hi john,
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>> regards,
>>>>> > > > >>> > >>>>>>>>>>>>> gerhard
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>><jo...@gmail.com>
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>> Hi All
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
>>>>> > ServiceHandler.
>>>>> > > I
>>>>> > > > >>> > >>>>>>>> added 113 as a
>>>>> > > > >>> > >>>>>>>>>>>>>> child
>>>>> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but
>>>>>not
>>>>>100%
>>>>> > > sure
>>>>> > > > >>> > >>>>>>>> (so please let
>>>>> > > > >>> > >>>>>>>>> me
>>>>> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as
>>>>>a
>>>>> > > > >>> > >>>>>>>> child). ServiceHandler
>>>>> > > > >>> > >>>>>>>>> is
>>>>> > > > >>> > >>>>>>>>>>> a
>>>>> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to
>>>>>define
>>>>>an
>>>>> > > > >>> > >>>>>>>> interceptor that
>>>>> > > > >>> > >>>>>>>>> manages
>>>>> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected
>>>>>interface.
>>>>> The
>>>>> > > API
>>>>> > > > >>> > >>>>>>>> is as follows:
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) -
>>>>>placed
>>>>> > > > >>> > >>>>>>>> on an annotation that
>>>>> > > > >>> > >>>>>>>>>>> would
>>>>> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates
>>>>>what
>>>>> > > > >>> > >>>>>>>> interceptor would be
>>>>> > > > >>> > >>>>>>>>>>> invoked
>>>>> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
>>>>> > > > >>> > >>>>>>>> developer/framework author to define
>>>>> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as
>>>>>the
>>>>> > > > >>> > >>>>>>>> interceptor itself
>>>>> > > > >>> > >>>>>>>>> that
>>>>> > > > >>> > >>>>>>>>>>>>>> will
>>>>> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for
>>>>>ServiceHandler
>>>>> would
>>>>> > be
>>>>> > > > >>> > >>>>>>>> to provide the
>>>>> > > > >>> > >>>>>>>>>>> API of
>>>>> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure
>>>>>required to
>>>>> > > make
>>>>> > > > >>> > >>>>>>>> the interceptor
>>>>> > > > >>> > >>>>>>>>>>> be
>>>>> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the
>>>>>feature:
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>
>>>>> > > > >>> >
>>>>> > > > >>>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-s
>>>>>er
>>>>>vicehandler.html
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>> Regards,
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>> john
>>>>> > > > >>> > >>>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>
>>>>> > > > >>> > >>>>>>>>>
>>>>> > > > >>> > >>>>>>>>
>>>>> > > > >>> > >>>>>>>
>>>>> > > > >>> > >>>>>
>>>>> > > > >>> > >>
>>>>> > > > >>> > >>
>>>>> > > > >>> >
>>>>> > > > >>> >
>>>>> > > > >>>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jason Porter
>>>> http://lightguard-jp.blogspot.com
>>>> http://twitter.com/lightguardjp
>>>>
>>>> Software Engineer
>>>> Open Source Advocate
>>>>
>>>> PGP key id: 926CCFF5
>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
sounds *almost* fine for me
@Arne: maybe i got it wrong: you link a handler with an interface?
what is nice with the annotation API is the handler doesn't know about
the interface it proxies
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Arne Limburg <ar...@openknowledge.de>:
> Two things about this: First: I don't like from the solder approach,
> because the interface is annotated instead of the implementation.
>
> Second, if we implement this we should conceptually make clear how it
> differentiates from Interceptors and Decorators. And personally I think
> this would work better with the InvocationHandler approach than with an
> approach that is very similar to interceptors.
>
> So +1 for an approach like this:
>
> @HandlesInvocationsOn(MyInterface.class)
> public class MyInvocationHandler implements InvocationHandler {
> ...
> }
>
> Technically we would register a custom Bean for every found
> InvocationHandler with that annotation and take over the
> interceptor-bindings from the interfaceŠ
> So the invocation stack would be clear, too:
> First Interceptors,
> Second Decorators,
> Third InvocationHandler
>
> Wdyt?
>
> Arne
>
> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> <rm...@gmail.com>:
>
>>+1
>>
>>that's a need, DS targets CDI 1.0 for now so just make this solder
>>part portable ans it should be fine
>>
>>Romain Manni-Bucau
>>Twitter: @rmannibucau
>>Blog: http://rmannibucau.wordpress.com/
>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>Github: https://github.com/rmannibucau
>>
>>
>>
>>2012/12/20 Jason Porter <li...@gmail.com>:
>>> At this point, I'd say just do it as is in solder.
>>>
>>>
>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>><jo...@gmail.com>wrote:
>>>
>>>> Hi All,
>>>>
>>>> Regarding the two open questions:
>>>>
>>>> 1) the approach (including the name/s) we agree on will be used also
>>>>for
>>>> cdi 1.1 (the only difference is the package)
>>>> 2) the eg has a different opinion about it ->
>>>>
>>>> It looks like the JSR's answer
>>>>(https://issues.jboss.org/browse/CDI-110 )
>>>> is still unresolved - I'm not sure if we can get any further answer at
>>>>this
>>>> time. The last posts on the subject seem to discuss using something
>>>>along
>>>> the lines of an invocation handler, which I think would work well.
>>>>Since
>>>> we have some features coming up that are interested in having service
>>>> handlers available, do we
>>>>
>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>> 2. Push EG on a resolution
>>>> 3. Do it using invocation handlers.
>>>> 4. Do it some other way?
>>>>
>>>> John
>>>>
>>>>
>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>> gerhard.petracek@gmail.com
>>>> > wrote:
>>>>
>>>> > hi john,
>>>> >
>>>> > as mentioned before we need the answers to the existing questions.
>>>> >
>>>> > regards,
>>>> > gerhard
>>>> >
>>>> >
>>>> >
>>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>>> >
>>>> > > All,
>>>> > >
>>>> > > I kind of let this one and the other drop off my radar, I
>>>>apologize.
>>>> it
>>>> > > looks like where we last left off, Gerhard was still requesting
>>>> > additional
>>>> > > comments from everyone. Any other feedback?
>>>> > >
>>>> > > John
>>>> > >
>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>> > > gerhard.petracek@gmail.com> wrote:
>>>> > >
>>>> > > > hi george,
>>>> > > >
>>>> > > > thx for the information. i thought there might be at least some
>>>> > > additional
>>>> > > > answers/clarifications, since pete asked for them in several
>>>> comments.
>>>> > > > -> imo we should continue with them.
>>>> > > >
>>>> > > > regards,
>>>> > > > gerhard
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
>>>> > > >
>>>> > > > > Hello Gerhard,
>>>> > > > >
>>>> > > > > Yeah, it´s the last state. I know it´s quite old, but I
>>>>haven´t had
>>>> > > time
>>>> > > > > to work on it after that.
>>>> > > > > Regards,
>>>> > > > >
>>>> > > > > George
>>>> > > > >
>>>> > > > >
>>>> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>>>> > > > >
>>>> > > > >> hi george,
>>>> > > > >>
>>>> > > > >> thx for the link.
>>>> > > > >> i'm not sure if it is the latest state of your discussion
>>>>and/or
>>>> > draft
>>>> > > > >> (at least it's quite old already).
>>>> > > > >>
>>>> > > > >> regards,
>>>> > > > >> gerhard
>>>> > > > >>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>>> > > > >>
>>>> > > > >>> Hi !
>>>> > > > >>>
>>>> > > > >>> +1 to #1. I also agree that the term "Service Handler" might
>>>>not
>>>> be
>>>> > > so
>>>> > > > >>> appropriate, so it should be discussed as well.
>>>> > > > >>> Here is the latest pull request with some comments from Pete
>>>>yet
>>>> to
>>>> > > be
>>>> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
>>>> > > > >>>
>>>> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>> > > > >>>
>>>> > > > >>> > Agreed :-)
>>>> > > > >>> >
>>>> > > > >>> > George is working on it for CDI 1.1. George, can you share
>>>>your
>>>> > > > >>> proposal
>>>> > > > >>> > so far?
>>>> > > > >>> >
>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>>> > > > >>> >
>>>> > > > >>> > > hi pete,
>>>> > > > >>> > >
>>>> > > > >>> > > independent of my opinion about the feature (which is
>>>>still
>>>> > +0):
>>>> > > > >>> > > if it should be part of cdi 1.1, we have the following
>>>> options
>>>> > > imo:
>>>> > > > >>> > >
>>>> > > > >>> > > 1) the approach (including the name/s) we agree on will
>>>>be
>>>> used
>>>> > > > also
>>>> > > > >>> for
>>>> > > > >>> > > cdi 1.1 (the only difference is the package)
>>>> > > > >>> > > 2) the eg has a different opinion about it ->
>>>> > > > >>> > > 2a) the rest of the eg joins this discussion
>>>> > > > >>> > > 2b) we wait for the final version and just allow the same
>>>> with
>>>> > > cdi
>>>> > > > >>> 1.0
>>>> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
>>>> re-visited
>>>> > > for
>>>> > > > >>> > > deltaspike (if we really need it)
>>>> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
>>>> > > > >>> > >
>>>> > > > >>> > > 1-3 is ok for me but -1 for #4
>>>> > > > >>> > >
>>>> > > > >>> > > regards,
>>>> > > > >>> > > gerhard
>>>> > > > >>> > >
>>>> > > > >>> > >
>>>> > > > >>> > >
>>>> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>>>> > > > >>> > >
>>>> > > > >>> > >> I'm not sure what you mean by a "super interceptor",
>>>>but if
>>>> > you
>>>> > > > >>> mean it
>>>> > > > >>> > as
>>>> > > > >>> > >> in "super man" (something better than an interceptor),
>>>>then
>>>> I
>>>> > > > would
>>>> > > > >>> > >> disagree, it's actually a specialised form of
>>>>interceptor.
>>>> > > > >>> > >>
>>>> > > > >>> > >> The best use case I know of is the one John mentions -
>>>> > creating
>>>> > > > type
>>>> > > > >>> > safe
>>>> > > > >>> > >> references to queries:
>>>> > > > >>> > >>
>>>> > > > >>> > >> @QueryService
>>>> > > > >>> > >> interface UserQuery {
>>>> > > > >>> > >>
>>>> > > > >>> > >> @Query("select u from User u")
>>>> > > > >>> > >> public List<User> getAllUsers();
>>>> > > > >>> > >>
>>>> > > > >>> > >> @Query("select u from User u order by u.name")
>>>> > > > >>> > >> public List<User> getAllUsersSortedByName();
>>>> > > > >>> > >>
>>>> > > > >>> > >> }
>>>> > > > >>> > >>
>>>> > > > >>> > >> Now, it may be the case that there aren't any other use
>>>> cases
>>>> > > for
>>>> > > > >>> > service
>>>> > > > >>> > >> handlers, in which case we should perhaps just offer
>>>>this
>>>> > > > particular
>>>> > > > >>> > >> service handler - references to type safe queries - as I
>>>> think
>>>> > > > this
>>>> > > > >>> is
>>>> > > > >>> > an
>>>> > > > >>> > >> extremely powerful idea.
>>>> > > > >>> > >>
>>>> > > > >>> > >> Note, that at the moment service handlers are scheduled
>>>>for
>>>> > CDI
>>>> > > > 1.1.
>>>> > > > >>> > >>
>>>> > > > >>> > >>
>>>> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>>> > > > >>> > >>
>>>> > > > >>> > >>> Somewhat. I wouldn't really think of them as overrides,
>>>> they,
>>>> > > to
>>>> > > > >>> me,
>>>> > > > >>> > >> seem more like items to do in addition to whatever the
>>>> > original
>>>> > > > impl
>>>> > > > >>> > does.
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> ServiceHandlers to me seem more like super
>>>>interceptors.
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> Sent from my iPhone
>>>> > > > >>> > >>>
>>>> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>>>> > > > john.d.ament@gmail.com>
>>>> > > > >>> > >> wrote:
>>>> > > > >>> > >>>
>>>> > > > >>> > >>>> @jason
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>> I think the concepts are very dissimilar.
>>>>servicehandlers
>>>> > > > create
>>>> > > > >>> the
>>>> > > > >>> > >>>> implementation. delegates are more like overrides and
>>>> need
>>>> > to
>>>> > > > >>> know
>>>> > > > >>> > >> about
>>>> > > > >>> > >>>> the method signature.
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>>> > > > >>> lightguard.jp@gmail.com
>>>> > > > >>> > >>> wrote:
>>>> > > > >>> > >>>>
>>>> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but,
>>>>could
>>>> we
>>>> > > not
>>>> > > > >>> do
>>>> > > > >>> > this
>>>> > > > >>> > >>>>> with delegates?
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>> Sent from my iPhone
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>>> > > > >>> john.d.ament@gmail.com>
>>>> > > > >>> > >> wrote:
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>>>>> @mark
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be
>>>>on an
>>>> > > > >>> interface.
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> One of the best use-cases we built at my job is
>>>>using it
>>>> > for
>>>> > > > >>> calling
>>>> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty.
>>>> we
>>>> > were
>>>> > > > >>> able to
>>>> > > > >>> > >>>>> create
>>>> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for
>>>>binding
>>>> > > in/out
>>>> > > > >>> > >> parameters.
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> JOhn
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>> > > > >>> struberg@yahoo.de>
>>>> > > > >>> > >>>>> wrote:
>>>> > > > >>> > >>>>>>
>>>> > > > >>> > >>>>>>> actually I don't really see a real benefit. I just
>>>> don't
>>>> > > yet
>>>> > > > >>> grok
>>>> > > > >>> > the
>>>> > > > >>> > >>>>> use
>>>> > > > >>> > >>>>>>> case for real world projects.
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate
>>>>the
>>>> > calls
>>>> > > > to
>>>> > > > >>> a
>>>> > > > >>> > >> method
>>>> > > > >>> > >>>>>>> handler?
>>>> > > > >>> > >>>>>>> This could be neat for mocking, but there are
>>>>better
>>>> > > > >>> frameworks for
>>>> > > > >>> > >>>>> that.
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> thus
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> -0.2
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> LieGrue,
>>>> > > > >>> > >>>>>>> strub
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>>> ----- Original Message -----
>>>> > > > >>> > >>>>>>>> From: Gerhard Petracek
>>>><ge...@gmail.com>
>>>> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>> > > > >>> > >>>>>>>> Cc:
>>>> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>> > Discuss
>>>> > > > >>> > >>>>> ServiceHandler
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>> if you have a lot of shared code, you can extract
>>>>it
>>>> in
>>>> > > 1-n
>>>> > > > >>> > >> method/s or
>>>> > > > >>> > >>>>>>> an
>>>> > > > >>> > >>>>>>>> abstract class which is still easier than a new
>>>> concept.
>>>> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
>>>> needed
>>>> > > it.
>>>> > > > >>> that
>>>> > > > >>> > was
>>>> > > > >>> > >>>>> the
>>>> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok
>>>>with
>>>> > adding
>>>> > > > >>> it).
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>> regards,
>>>> > > > >>> > >>>>>>>> gerhard
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
>>>> boilerplate
>>>> > > > code
>>>> > > > >>> in
>>>> > > > >>> > it?
>>>> > > > >>> > >>>>>>>>>
>>>> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>> > > > >>> > >>>>>>>>>
>>>> > > > >>> > >>>>>>>>>> hi pete,
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>> instead of the interface you can just implement
>>>>a
>>>> bean
>>>> > > > which
>>>> > > > >>> > does
>>>> > > > >>> > >> the
>>>> > > > >>> > >>>>>>>>> same.
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>> regards,
>>>> > > > >>> > >>>>>>>>>> gerhard
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>> > > > >>> > >>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>>>> > > > >>> > >>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek
>>>>wrote:
>>>> > > > >>> > >>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>> +0
>>>> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>>>> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms
>>>> > instead.
>>>> > > > >>> > >>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>> regards,
>>>> > > > >>> > >>>>>>>>>>>> gerhard
>>>> > > > >>> > >>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>> > gerhard.petracek@gmail.com
>>>> > > >
>>>> > > > >>> > >>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>> hi john,
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>> regards,
>>>> > > > >>> > >>>>>>>>>>>>> gerhard
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>><jo...@gmail.com>
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>> Hi All
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
>>>> > ServiceHandler.
>>>> > > I
>>>> > > > >>> > >>>>>>>> added 113 as a
>>>> > > > >>> > >>>>>>>>>>>>>> child
>>>> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not
>>>>100%
>>>> > > sure
>>>> > > > >>> > >>>>>>>> (so please let
>>>> > > > >>> > >>>>>>>>> me
>>>> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
>>>> > > > >>> > >>>>>>>> child). ServiceHandler
>>>> > > > >>> > >>>>>>>>> is
>>>> > > > >>> > >>>>>>>>>>> a
>>>> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define
>>>>an
>>>> > > > >>> > >>>>>>>> interceptor that
>>>> > > > >>> > >>>>>>>>> manages
>>>> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected interface.
>>>> The
>>>> > > API
>>>> > > > >>> > >>>>>>>> is as follows:
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) -
>>>>placed
>>>> > > > >>> > >>>>>>>> on an annotation that
>>>> > > > >>> > >>>>>>>>>>> would
>>>> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
>>>> > > > >>> > >>>>>>>> interceptor would be
>>>> > > > >>> > >>>>>>>>>>> invoked
>>>> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
>>>> > > > >>> > >>>>>>>> developer/framework author to define
>>>> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as
>>>>the
>>>> > > > >>> > >>>>>>>> interceptor itself
>>>> > > > >>> > >>>>>>>>> that
>>>> > > > >>> > >>>>>>>>>>>>>> will
>>>> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler
>>>> would
>>>> > be
>>>> > > > >>> > >>>>>>>> to provide the
>>>> > > > >>> > >>>>>>>>>>> API of
>>>> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure
>>>>required to
>>>> > > make
>>>> > > > >>> > >>>>>>>> the interceptor
>>>> > > > >>> > >>>>>>>>>>> be
>>>> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the
>>>>feature:
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>
>>>> > > > >>> >
>>>> > > > >>>
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-ser
>>>>vicehandler.html
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>> Regards,
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>> john
>>>> > > > >>> > >>>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>>>
>>>> > > > >>> > >>>>>>>>>
>>>> > > > >>> > >>>>>>>>>
>>>> > > > >>> > >>>>>>>>
>>>> > > > >>> > >>>>>>>
>>>> > > > >>> > >>>>>
>>>> > > > >>> > >>
>>>> > > > >>> > >>
>>>> > > > >>> >
>>>> > > > >>> >
>>>> > > > >>>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Arne Limburg <ar...@openknowledge.de>.
Two things about this: First: I don't like from the solder approach,
because the interface is annotated instead of the implementation.
Second, if we implement this we should conceptually make clear how it
differentiates from Interceptors and Decorators. And personally I think
this would work better with the InvocationHandler approach than with an
approach that is very similar to interceptors.
So +1 for an approach like this:
@HandlesInvocationsOn(MyInterface.class)
public class MyInvocationHandler implements InvocationHandler {
...
}
Technically we would register a custom Bean for every found
InvocationHandler with that annotation and take over the
interceptor-bindings from the interfaceŠ
So the invocation stack would be clear, too:
First Interceptors,
Second Decorators,
Third InvocationHandler
Wdyt?
Arne
Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
<rm...@gmail.com>:
>+1
>
>that's a need, DS targets CDI 1.0 for now so just make this solder
>part portable ans it should be fine
>
>Romain Manni-Bucau
>Twitter: @rmannibucau
>Blog: http://rmannibucau.wordpress.com/
>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>Github: https://github.com/rmannibucau
>
>
>
>2012/12/20 Jason Porter <li...@gmail.com>:
>> At this point, I'd say just do it as is in solder.
>>
>>
>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>><jo...@gmail.com>wrote:
>>
>>> Hi All,
>>>
>>> Regarding the two open questions:
>>>
>>> 1) the approach (including the name/s) we agree on will be used also
>>>for
>>> cdi 1.1 (the only difference is the package)
>>> 2) the eg has a different opinion about it ->
>>>
>>> It looks like the JSR's answer
>>>(https://issues.jboss.org/browse/CDI-110 )
>>> is still unresolved - I'm not sure if we can get any further answer at
>>>this
>>> time. The last posts on the subject seem to discuss using something
>>>along
>>> the lines of an invocation handler, which I think would work well.
>>>Since
>>> we have some features coming up that are interested in having service
>>> handlers available, do we
>>>
>>> 1. Implement as is, or similar to, what is currently in Solder?
>>> 2. Push EG on a resolution
>>> 3. Do it using invocation handlers.
>>> 4. Do it some other way?
>>>
>>> John
>>>
>>>
>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>> gerhard.petracek@gmail.com
>>> > wrote:
>>>
>>> > hi john,
>>> >
>>> > as mentioned before we need the answers to the existing questions.
>>> >
>>> > regards,
>>> > gerhard
>>> >
>>> >
>>> >
>>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>>> >
>>> > > All,
>>> > >
>>> > > I kind of let this one and the other drop off my radar, I
>>>apologize.
>>> it
>>> > > looks like where we last left off, Gerhard was still requesting
>>> > additional
>>> > > comments from everyone. Any other feedback?
>>> > >
>>> > > John
>>> > >
>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>> > > gerhard.petracek@gmail.com> wrote:
>>> > >
>>> > > > hi george,
>>> > > >
>>> > > > thx for the information. i thought there might be at least some
>>> > > additional
>>> > > > answers/clarifications, since pete asked for them in several
>>> comments.
>>> > > > -> imo we should continue with them.
>>> > > >
>>> > > > regards,
>>> > > > gerhard
>>> > > >
>>> > > >
>>> > > >
>>> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
>>> > > >
>>> > > > > Hello Gerhard,
>>> > > > >
>>> > > > > Yeah, it´s the last state. I know it´s quite old, but I
>>>haven´t had
>>> > > time
>>> > > > > to work on it after that.
>>> > > > > Regards,
>>> > > > >
>>> > > > > George
>>> > > > >
>>> > > > >
>>> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>>> > > > >
>>> > > > >> hi george,
>>> > > > >>
>>> > > > >> thx for the link.
>>> > > > >> i'm not sure if it is the latest state of your discussion
>>>and/or
>>> > draft
>>> > > > >> (at least it's quite old already).
>>> > > > >>
>>> > > > >> regards,
>>> > > > >> gerhard
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>> > > > >>
>>> > > > >>> Hi !
>>> > > > >>>
>>> > > > >>> +1 to #1. I also agree that the term "Service Handler" might
>>>not
>>> be
>>> > > so
>>> > > > >>> appropriate, so it should be discussed as well.
>>> > > > >>> Here is the latest pull request with some comments from Pete
>>>yet
>>> to
>>> > > be
>>> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
>>> > > > >>>
>>> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>> > > > >>>
>>> > > > >>> > Agreed :-)
>>> > > > >>> >
>>> > > > >>> > George is working on it for CDI 1.1. George, can you share
>>>your
>>> > > > >>> proposal
>>> > > > >>> > so far?
>>> > > > >>> >
>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>> > > > >>> >
>>> > > > >>> > > hi pete,
>>> > > > >>> > >
>>> > > > >>> > > independent of my opinion about the feature (which is
>>>still
>>> > +0):
>>> > > > >>> > > if it should be part of cdi 1.1, we have the following
>>> options
>>> > > imo:
>>> > > > >>> > >
>>> > > > >>> > > 1) the approach (including the name/s) we agree on will
>>>be
>>> used
>>> > > > also
>>> > > > >>> for
>>> > > > >>> > > cdi 1.1 (the only difference is the package)
>>> > > > >>> > > 2) the eg has a different opinion about it ->
>>> > > > >>> > > 2a) the rest of the eg joins this discussion
>>> > > > >>> > > 2b) we wait for the final version and just allow the same
>>> with
>>> > > cdi
>>> > > > >>> 1.0
>>> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
>>> re-visited
>>> > > for
>>> > > > >>> > > deltaspike (if we really need it)
>>> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
>>> > > > >>> > >
>>> > > > >>> > > 1-3 is ok for me but -1 for #4
>>> > > > >>> > >
>>> > > > >>> > > regards,
>>> > > > >>> > > gerhard
>>> > > > >>> > >
>>> > > > >>> > >
>>> > > > >>> > >
>>> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>>> > > > >>> > >
>>> > > > >>> > >> I'm not sure what you mean by a "super interceptor",
>>>but if
>>> > you
>>> > > > >>> mean it
>>> > > > >>> > as
>>> > > > >>> > >> in "super man" (something better than an interceptor),
>>>then
>>> I
>>> > > > would
>>> > > > >>> > >> disagree, it's actually a specialised form of
>>>interceptor.
>>> > > > >>> > >>
>>> > > > >>> > >> The best use case I know of is the one John mentions -
>>> > creating
>>> > > > type
>>> > > > >>> > safe
>>> > > > >>> > >> references to queries:
>>> > > > >>> > >>
>>> > > > >>> > >> @QueryService
>>> > > > >>> > >> interface UserQuery {
>>> > > > >>> > >>
>>> > > > >>> > >> @Query("select u from User u")
>>> > > > >>> > >> public List<User> getAllUsers();
>>> > > > >>> > >>
>>> > > > >>> > >> @Query("select u from User u order by u.name")
>>> > > > >>> > >> public List<User> getAllUsersSortedByName();
>>> > > > >>> > >>
>>> > > > >>> > >> }
>>> > > > >>> > >>
>>> > > > >>> > >> Now, it may be the case that there aren't any other use
>>> cases
>>> > > for
>>> > > > >>> > service
>>> > > > >>> > >> handlers, in which case we should perhaps just offer
>>>this
>>> > > > particular
>>> > > > >>> > >> service handler - references to type safe queries - as I
>>> think
>>> > > > this
>>> > > > >>> is
>>> > > > >>> > an
>>> > > > >>> > >> extremely powerful idea.
>>> > > > >>> > >>
>>> > > > >>> > >> Note, that at the moment service handlers are scheduled
>>>for
>>> > CDI
>>> > > > 1.1.
>>> > > > >>> > >>
>>> > > > >>> > >>
>>> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>> > > > >>> > >>
>>> > > > >>> > >>> Somewhat. I wouldn't really think of them as overrides,
>>> they,
>>> > > to
>>> > > > >>> me,
>>> > > > >>> > >> seem more like items to do in addition to whatever the
>>> > original
>>> > > > impl
>>> > > > >>> > does.
>>> > > > >>> > >>>
>>> > > > >>> > >>> ServiceHandlers to me seem more like super
>>>interceptors.
>>> > > > >>> > >>>
>>> > > > >>> > >>> Sent from my iPhone
>>> > > > >>> > >>>
>>> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>>> > > > john.d.ament@gmail.com>
>>> > > > >>> > >> wrote:
>>> > > > >>> > >>>
>>> > > > >>> > >>>> @jason
>>> > > > >>> > >>>>
>>> > > > >>> > >>>> I think the concepts are very dissimilar.
>>>servicehandlers
>>> > > > create
>>> > > > >>> the
>>> > > > >>> > >>>> implementation. delegates are more like overrides and
>>> need
>>> > to
>>> > > > >>> know
>>> > > > >>> > >> about
>>> > > > >>> > >>>> the method signature.
>>> > > > >>> > >>>>
>>> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>> > > > >>> lightguard.jp@gmail.com
>>> > > > >>> > >>> wrote:
>>> > > > >>> > >>>>
>>> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but,
>>>could
>>> we
>>> > > not
>>> > > > >>> do
>>> > > > >>> > this
>>> > > > >>> > >>>>> with delegates?
>>> > > > >>> > >>>>>
>>> > > > >>> > >>>>> Sent from my iPhone
>>> > > > >>> > >>>>>
>>> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>> > > > >>> john.d.ament@gmail.com>
>>> > > > >>> > >> wrote:
>>> > > > >>> > >>>>>
>>> > > > >>> > >>>>>> @mark
>>> > > > >>> > >>>>>>
>>> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be
>>>on an
>>> > > > >>> interface.
>>> > > > >>> > >>>>>>
>>> > > > >>> > >>>>>> One of the best use-cases we built at my job is
>>>using it
>>> > for
>>> > > > >>> calling
>>> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty.
>>> we
>>> > were
>>> > > > >>> able to
>>> > > > >>> > >>>>> create
>>> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for
>>>binding
>>> > > in/out
>>> > > > >>> > >> parameters.
>>> > > > >>> > >>>>>>
>>> > > > >>> > >>>>>> JOhn
>>> > > > >>> > >>>>>>
>>> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>> > > > >>> struberg@yahoo.de>
>>> > > > >>> > >>>>> wrote:
>>> > > > >>> > >>>>>>
>>> > > > >>> > >>>>>>> actually I don't really see a real benefit. I just
>>> don't
>>> > > yet
>>> > > > >>> grok
>>> > > > >>> > the
>>> > > > >>> > >>>>> use
>>> > > > >>> > >>>>>>> case for real world projects.
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate
>>>the
>>> > calls
>>> > > > to
>>> > > > >>> a
>>> > > > >>> > >> method
>>> > > > >>> > >>>>>>> handler?
>>> > > > >>> > >>>>>>> This could be neat for mocking, but there are
>>>better
>>> > > > >>> frameworks for
>>> > > > >>> > >>>>> that.
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>> thus
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>> -0.2
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>> LieGrue,
>>> > > > >>> > >>>>>>> strub
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>>> ----- Original Message -----
>>> > > > >>> > >>>>>>>> From: Gerhard Petracek
>>><ge...@gmail.com>
>>> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>>> > > > >>> > >>>>>>>> Cc:
>>> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>> > Discuss
>>> > > > >>> > >>>>> ServiceHandler
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>> if you have a lot of shared code, you can extract
>>>it
>>> in
>>> > > 1-n
>>> > > > >>> > >> method/s or
>>> > > > >>> > >>>>>>> an
>>> > > > >>> > >>>>>>>> abstract class which is still easier than a new
>>> concept.
>>> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
>>> needed
>>> > > it.
>>> > > > >>> that
>>> > > > >>> > was
>>> > > > >>> > >>>>> the
>>> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok
>>>with
>>> > adding
>>> > > > >>> it).
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>> regards,
>>> > > > >>> > >>>>>>>> gerhard
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
>>> boilerplate
>>> > > > code
>>> > > > >>> in
>>> > > > >>> > it?
>>> > > > >>> > >>>>>>>>>
>>> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>> > > > >>> > >>>>>>>>>
>>> > > > >>> > >>>>>>>>>> hi pete,
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>> instead of the interface you can just implement
>>>a
>>> bean
>>> > > > which
>>> > > > >>> > does
>>> > > > >>> > >> the
>>> > > > >>> > >>>>>>>>> same.
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>> regards,
>>> > > > >>> > >>>>>>>>>> gerhard
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>> > > > >>> > >>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>>> > > > >>> > >>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek
>>>wrote:
>>> > > > >>> > >>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>> +0
>>> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>>> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms
>>> > instead.
>>> > > > >>> > >>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>> regards,
>>> > > > >>> > >>>>>>>>>>>> gerhard
>>> > > > >>> > >>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>> > gerhard.petracek@gmail.com
>>> > > >
>>> > > > >>> > >>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>> hi john,
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>> regards,
>>> > > > >>> > >>>>>>>>>>>>> gerhard
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament
>>><jo...@gmail.com>
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>> Hi All
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
>>> > ServiceHandler.
>>> > > I
>>> > > > >>> > >>>>>>>> added 113 as a
>>> > > > >>> > >>>>>>>>>>>>>> child
>>> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not
>>>100%
>>> > > sure
>>> > > > >>> > >>>>>>>> (so please let
>>> > > > >>> > >>>>>>>>> me
>>> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
>>> > > > >>> > >>>>>>>> child). ServiceHandler
>>> > > > >>> > >>>>>>>>> is
>>> > > > >>> > >>>>>>>>>>> a
>>> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define
>>>an
>>> > > > >>> > >>>>>>>> interceptor that
>>> > > > >>> > >>>>>>>>> manages
>>> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected interface.
>>> The
>>> > > API
>>> > > > >>> > >>>>>>>> is as follows:
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) -
>>>placed
>>> > > > >>> > >>>>>>>> on an annotation that
>>> > > > >>> > >>>>>>>>>>> would
>>> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
>>> > > > >>> > >>>>>>>> interceptor would be
>>> > > > >>> > >>>>>>>>>>> invoked
>>> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
>>> > > > >>> > >>>>>>>> developer/framework author to define
>>> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as
>>>the
>>> > > > >>> > >>>>>>>> interceptor itself
>>> > > > >>> > >>>>>>>>> that
>>> > > > >>> > >>>>>>>>>>>>>> will
>>> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler
>>> would
>>> > be
>>> > > > >>> > >>>>>>>> to provide the
>>> > > > >>> > >>>>>>>>>>> API of
>>> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure
>>>required to
>>> > > make
>>> > > > >>> > >>>>>>>> the interceptor
>>> > > > >>> > >>>>>>>>>>> be
>>> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the
>>>feature:
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>
>>> > > > >>> > >>
>>> > > > >>> >
>>> > > > >>>
>>> > > >
>>> > >
>>> >
>>>
>>>http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-ser
>>>vicehandler.html
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>> Regards,
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>> john
>>> > > > >>> > >>>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>>>
>>> > > > >>> > >>>>>>>>>
>>> > > > >>> > >>>>>>>>>
>>> > > > >>> > >>>>>>>>
>>> > > > >>> > >>>>>>>
>>> > > > >>> > >>>>>
>>> > > > >>> > >>
>>> > > > >>> > >>
>>> > > > >>> >
>>> > > > >>> >
>>> > > > >>>
>>> > > > >>
>>> > > > >>
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
that's a need, DS targets CDI 1.0 for now so just make this solder
part portable ans it should be fine
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/20 Jason Porter <li...@gmail.com>:
> At this point, I'd say just do it as is in solder.
>
>
> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament <jo...@gmail.com>wrote:
>
>> Hi All,
>>
>> Regarding the two open questions:
>>
>> 1) the approach (including the name/s) we agree on will be used also for
>> cdi 1.1 (the only difference is the package)
>> 2) the eg has a different opinion about it ->
>>
>> It looks like the JSR's answer (https://issues.jboss.org/browse/CDI-110 )
>> is still unresolved - I'm not sure if we can get any further answer at this
>> time. The last posts on the subject seem to discuss using something along
>> the lines of an invocation handler, which I think would work well. Since
>> we have some features coming up that are interested in having service
>> handlers available, do we
>>
>> 1. Implement as is, or similar to, what is currently in Solder?
>> 2. Push EG on a resolution
>> 3. Do it using invocation handlers.
>> 4. Do it some other way?
>>
>> John
>>
>>
>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>> gerhard.petracek@gmail.com
>> > wrote:
>>
>> > hi john,
>> >
>> > as mentioned before we need the answers to the existing questions.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2012/4/4 John D. Ament <jo...@gmail.com>
>> >
>> > > All,
>> > >
>> > > I kind of let this one and the other drop off my radar, I apologize.
>> it
>> > > looks like where we last left off, Gerhard was still requesting
>> > additional
>> > > comments from everyone. Any other feedback?
>> > >
>> > > John
>> > >
>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>> > > gerhard.petracek@gmail.com> wrote:
>> > >
>> > > > hi george,
>> > > >
>> > > > thx for the information. i thought there might be at least some
>> > > additional
>> > > > answers/clarifications, since pete asked for them in several
>> comments.
>> > > > -> imo we should continue with them.
>> > > >
>> > > > regards,
>> > > > gerhard
>> > > >
>> > > >
>> > > >
>> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
>> > > >
>> > > > > Hello Gerhard,
>> > > > >
>> > > > > Yeah, it´s the last state. I know it´s quite old, but I haven´t had
>> > > time
>> > > > > to work on it after that.
>> > > > > Regards,
>> > > > >
>> > > > > George
>> > > > >
>> > > > >
>> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>> > > > >
>> > > > >> hi george,
>> > > > >>
>> > > > >> thx for the link.
>> > > > >> i'm not sure if it is the latest state of your discussion and/or
>> > draft
>> > > > >> (at least it's quite old already).
>> > > > >>
>> > > > >> regards,
>> > > > >> gerhard
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
>> > > > >>
>> > > > >>> Hi !
>> > > > >>>
>> > > > >>> +1 to #1. I also agree that the term "Service Handler" might not
>> be
>> > > so
>> > > > >>> appropriate, so it should be discussed as well.
>> > > > >>> Here is the latest pull request with some comments from Pete yet
>> to
>> > > be
>> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
>> > > > >>>
>> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
>> > > > >>>
>> > > > >>> > Agreed :-)
>> > > > >>> >
>> > > > >>> > George is working on it for CDI 1.1. George, can you share your
>> > > > >>> proposal
>> > > > >>> > so far?
>> > > > >>> >
>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>> > > > >>> >
>> > > > >>> > > hi pete,
>> > > > >>> > >
>> > > > >>> > > independent of my opinion about the feature (which is still
>> > +0):
>> > > > >>> > > if it should be part of cdi 1.1, we have the following
>> options
>> > > imo:
>> > > > >>> > >
>> > > > >>> > > 1) the approach (including the name/s) we agree on will be
>> used
>> > > > also
>> > > > >>> for
>> > > > >>> > > cdi 1.1 (the only difference is the package)
>> > > > >>> > > 2) the eg has a different opinion about it ->
>> > > > >>> > > 2a) the rest of the eg joins this discussion
>> > > > >>> > > 2b) we wait for the final version and just allow the same
>> with
>> > > cdi
>> > > > >>> 1.0
>> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
>> re-visited
>> > > for
>> > > > >>> > > deltaspike (if we really need it)
>> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
>> > > > >>> > >
>> > > > >>> > > 1-3 is ok for me but -1 for #4
>> > > > >>> > >
>> > > > >>> > > regards,
>> > > > >>> > > gerhard
>> > > > >>> > >
>> > > > >>> > >
>> > > > >>> > >
>> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>> > > > >>> > >
>> > > > >>> > >> I'm not sure what you mean by a "super interceptor", but if
>> > you
>> > > > >>> mean it
>> > > > >>> > as
>> > > > >>> > >> in "super man" (something better than an interceptor), then
>> I
>> > > > would
>> > > > >>> > >> disagree, it's actually a specialised form of interceptor.
>> > > > >>> > >>
>> > > > >>> > >> The best use case I know of is the one John mentions -
>> > creating
>> > > > type
>> > > > >>> > safe
>> > > > >>> > >> references to queries:
>> > > > >>> > >>
>> > > > >>> > >> @QueryService
>> > > > >>> > >> interface UserQuery {
>> > > > >>> > >>
>> > > > >>> > >> @Query("select u from User u")
>> > > > >>> > >> public List<User> getAllUsers();
>> > > > >>> > >>
>> > > > >>> > >> @Query("select u from User u order by u.name")
>> > > > >>> > >> public List<User> getAllUsersSortedByName();
>> > > > >>> > >>
>> > > > >>> > >> }
>> > > > >>> > >>
>> > > > >>> > >> Now, it may be the case that there aren't any other use
>> cases
>> > > for
>> > > > >>> > service
>> > > > >>> > >> handlers, in which case we should perhaps just offer this
>> > > > particular
>> > > > >>> > >> service handler - references to type safe queries - as I
>> think
>> > > > this
>> > > > >>> is
>> > > > >>> > an
>> > > > >>> > >> extremely powerful idea.
>> > > > >>> > >>
>> > > > >>> > >> Note, that at the moment service handlers are scheduled for
>> > CDI
>> > > > 1.1.
>> > > > >>> > >>
>> > > > >>> > >>
>> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>> > > > >>> > >>
>> > > > >>> > >>> Somewhat. I wouldn't really think of them as overrides,
>> they,
>> > > to
>> > > > >>> me,
>> > > > >>> > >> seem more like items to do in addition to whatever the
>> > original
>> > > > impl
>> > > > >>> > does.
>> > > > >>> > >>>
>> > > > >>> > >>> ServiceHandlers to me seem more like super interceptors.
>> > > > >>> > >>>
>> > > > >>> > >>> Sent from my iPhone
>> > > > >>> > >>>
>> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
>> > > > john.d.ament@gmail.com>
>> > > > >>> > >> wrote:
>> > > > >>> > >>>
>> > > > >>> > >>>> @jason
>> > > > >>> > >>>>
>> > > > >>> > >>>> I think the concepts are very dissimilar. servicehandlers
>> > > > create
>> > > > >>> the
>> > > > >>> > >>>> implementation. delegates are more like overrides and
>> need
>> > to
>> > > > >>> know
>> > > > >>> > >> about
>> > > > >>> > >>>> the method signature.
>> > > > >>> > >>>>
>> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>> > > > >>> lightguard.jp@gmail.com
>> > > > >>> > >>> wrote:
>> > > > >>> > >>>>
>> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but, could
>> we
>> > > not
>> > > > >>> do
>> > > > >>> > this
>> > > > >>> > >>>>> with delegates?
>> > > > >>> > >>>>>
>> > > > >>> > >>>>> Sent from my iPhone
>> > > > >>> > >>>>>
>> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>> > > > >>> john.d.ament@gmail.com>
>> > > > >>> > >> wrote:
>> > > > >>> > >>>>>
>> > > > >>> > >>>>>> @mark
>> > > > >>> > >>>>>>
>> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be on an
>> > > > >>> interface.
>> > > > >>> > >>>>>>
>> > > > >>> > >>>>>> One of the best use-cases we built at my job is using it
>> > for
>> > > > >>> calling
>> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we
>> > were
>> > > > >>> able to
>> > > > >>> > >>>>> create
>> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for binding
>> > > in/out
>> > > > >>> > >> parameters.
>> > > > >>> > >>>>>>
>> > > > >>> > >>>>>> JOhn
>> > > > >>> > >>>>>>
>> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>> > > > >>> struberg@yahoo.de>
>> > > > >>> > >>>>> wrote:
>> > > > >>> > >>>>>>
>> > > > >>> > >>>>>>> actually I don't really see a real benefit. I just
>> don't
>> > > yet
>> > > > >>> grok
>> > > > >>> > the
>> > > > >>> > >>>>> use
>> > > > >>> > >>>>>>> case for real world projects.
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate the
>> > calls
>> > > > to
>> > > > >>> a
>> > > > >>> > >> method
>> > > > >>> > >>>>>>> handler?
>> > > > >>> > >>>>>>> This could be neat for mocking, but there are better
>> > > > >>> frameworks for
>> > > > >>> > >>>>> that.
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>> thus
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>> -0.2
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>> LieGrue,
>> > > > >>> > >>>>>>> strub
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>>> ----- Original Message -----
>> > > > >>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
>> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>> > > > >>> > >>>>>>>> Cc:
>> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>> > Discuss
>> > > > >>> > >>>>> ServiceHandler
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>> if you have a lot of shared code, you can extract it
>> in
>> > > 1-n
>> > > > >>> > >> method/s or
>> > > > >>> > >>>>>>> an
>> > > > >>> > >>>>>>>> abstract class which is still easier than a new
>> concept.
>> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
>> needed
>> > > it.
>> > > > >>> that
>> > > > >>> > was
>> > > > >>> > >>>>> the
>> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok with
>> > adding
>> > > > >>> it).
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>> regards,
>> > > > >>> > >>>>>>>> gerhard
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
>> boilerplate
>> > > > code
>> > > > >>> in
>> > > > >>> > it?
>> > > > >>> > >>>>>>>>>
>> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>> > > > >>> > >>>>>>>>>
>> > > > >>> > >>>>>>>>>> hi pete,
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>> instead of the interface you can just implement a
>> bean
>> > > > which
>> > > > >>> > does
>> > > > >>> > >> the
>> > > > >>> > >>>>>>>>> same.
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>> regards,
>> > > > >>> > >>>>>>>>>> gerhard
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>> > > > >>> > >>>>>>>>>>
>> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>> > > > >>> > >>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>> > > > >>> > >>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>> +0
>> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms
>> > instead.
>> > > > >>> > >>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>> regards,
>> > > > >>> > >>>>>>>>>>>> gerhard
>> > > > >>> > >>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>> > gerhard.petracek@gmail.com
>> > > >
>> > > > >>> > >>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>> hi john,
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>> regards,
>> > > > >>> > >>>>>>>>>>>>> gerhard
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>> Hi All
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
>> > ServiceHandler.
>> > > I
>> > > > >>> > >>>>>>>> added 113 as a
>> > > > >>> > >>>>>>>>>>>>>> child
>> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100%
>> > > sure
>> > > > >>> > >>>>>>>> (so please let
>> > > > >>> > >>>>>>>>> me
>> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
>> > > > >>> > >>>>>>>> child). ServiceHandler
>> > > > >>> > >>>>>>>>> is
>> > > > >>> > >>>>>>>>>>> a
>> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
>> > > > >>> > >>>>>>>> interceptor that
>> > > > >>> > >>>>>>>>> manages
>> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected interface.
>> The
>> > > API
>> > > > >>> > >>>>>>>> is as follows:
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>> > > > >>> > >>>>>>>> on an annotation that
>> > > > >>> > >>>>>>>>>>> would
>> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
>> > > > >>> > >>>>>>>> interceptor would be
>> > > > >>> > >>>>>>>>>>> invoked
>> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
>> > > > >>> > >>>>>>>> developer/framework author to define
>> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
>> > > > >>> > >>>>>>>> interceptor itself
>> > > > >>> > >>>>>>>>> that
>> > > > >>> > >>>>>>>>>>>>>> will
>> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler
>> would
>> > be
>> > > > >>> > >>>>>>>> to provide the
>> > > > >>> > >>>>>>>>>>> API of
>> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure required to
>> > > make
>> > > > >>> > >>>>>>>> the interceptor
>> > > > >>> > >>>>>>>>>>> be
>> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>
>> > > > >>> > >>>>>>>>>
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>
>> > > > >>> > >>
>> > > > >>> >
>> > > > >>>
>> > > >
>> > >
>> >
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>> Regards,
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>> john
>> > > > >>> > >>>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>
>> > > > >>> > >>>>>>>>>>>
>> > > > >>> > >>>>>>>>>
>> > > > >>> > >>>>>>>>>
>> > > > >>> > >>>>>>>>
>> > > > >>> > >>>>>>>
>> > > > >>> > >>>>>
>> > > > >>> > >>
>> > > > >>> > >>
>> > > > >>> >
>> > > > >>> >
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Jason Porter <li...@gmail.com>.
At this point, I'd say just do it as is in solder.
On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament <jo...@gmail.com>wrote:
> Hi All,
>
> Regarding the two open questions:
>
> 1) the approach (including the name/s) we agree on will be used also for
> cdi 1.1 (the only difference is the package)
> 2) the eg has a different opinion about it ->
>
> It looks like the JSR's answer (https://issues.jboss.org/browse/CDI-110 )
> is still unresolved - I'm not sure if we can get any further answer at this
> time. The last posts on the subject seem to discuss using something along
> the lines of an invocation handler, which I think would work well. Since
> we have some features coming up that are interested in having service
> handlers available, do we
>
> 1. Implement as is, or similar to, what is currently in Solder?
> 2. Push EG on a resolution
> 3. Do it using invocation handlers.
> 4. Do it some other way?
>
> John
>
>
> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> gerhard.petracek@gmail.com
> > wrote:
>
> > hi john,
> >
> > as mentioned before we need the answers to the existing questions.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/4/4 John D. Ament <jo...@gmail.com>
> >
> > > All,
> > >
> > > I kind of let this one and the other drop off my radar, I apologize.
> it
> > > looks like where we last left off, Gerhard was still requesting
> > additional
> > > comments from everyone. Any other feedback?
> > >
> > > John
> > >
> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > > gerhard.petracek@gmail.com> wrote:
> > >
> > > > hi george,
> > > >
> > > > thx for the information. i thought there might be at least some
> > > additional
> > > > answers/clarifications, since pete asked for them in several
> comments.
> > > > -> imo we should continue with them.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2012/3/12 George Gastaldi <ge...@gmail.com>
> > > >
> > > > > Hello Gerhard,
> > > > >
> > > > > Yeah, it´s the last state. I know it´s quite old, but I haven´t had
> > > time
> > > > > to work on it after that.
> > > > > Regards,
> > > > >
> > > > > George
> > > > >
> > > > >
> > > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
> > > > >
> > > > >> hi george,
> > > > >>
> > > > >> thx for the link.
> > > > >> i'm not sure if it is the latest state of your discussion and/or
> > draft
> > > > >> (at least it's quite old already).
> > > > >>
> > > > >> regards,
> > > > >> gerhard
> > > > >>
> > > > >>
> > > > >>
> > > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
> > > > >>
> > > > >>> Hi !
> > > > >>>
> > > > >>> +1 to #1. I also agree that the term "Service Handler" might not
> be
> > > so
> > > > >>> appropriate, so it should be discussed as well.
> > > > >>> Here is the latest pull request with some comments from Pete yet
> to
> > > be
> > > > >>> reviewed: https://github.com/jboss/cdi/pull/28
> > > > >>>
> > > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
> > > > >>>
> > > > >>> > Agreed :-)
> > > > >>> >
> > > > >>> > George is working on it for CDI 1.1. George, can you share your
> > > > >>> proposal
> > > > >>> > so far?
> > > > >>> >
> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> > > > >>> >
> > > > >>> > > hi pete,
> > > > >>> > >
> > > > >>> > > independent of my opinion about the feature (which is still
> > +0):
> > > > >>> > > if it should be part of cdi 1.1, we have the following
> options
> > > imo:
> > > > >>> > >
> > > > >>> > > 1) the approach (including the name/s) we agree on will be
> used
> > > > also
> > > > >>> for
> > > > >>> > > cdi 1.1 (the only difference is the package)
> > > > >>> > > 2) the eg has a different opinion about it ->
> > > > >>> > > 2a) the rest of the eg joins this discussion
> > > > >>> > > 2b) we wait for the final version and just allow the same
> with
> > > cdi
> > > > >>> 1.0
> > > > >>> > > 3) if the eg doesn't agree on the idea, it should be
> re-visited
> > > for
> > > > >>> > > deltaspike (if we really need it)
> > > > >>> > > 4) we agree on it independent of the result in cdi 1.1
> > > > >>> > >
> > > > >>> > > 1-3 is ok for me but -1 for #4
> > > > >>> > >
> > > > >>> > > regards,
> > > > >>> > > gerhard
> > > > >>> > >
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
> > > > >>> > >
> > > > >>> > >> I'm not sure what you mean by a "super interceptor", but if
> > you
> > > > >>> mean it
> > > > >>> > as
> > > > >>> > >> in "super man" (something better than an interceptor), then
> I
> > > > would
> > > > >>> > >> disagree, it's actually a specialised form of interceptor.
> > > > >>> > >>
> > > > >>> > >> The best use case I know of is the one John mentions -
> > creating
> > > > type
> > > > >>> > safe
> > > > >>> > >> references to queries:
> > > > >>> > >>
> > > > >>> > >> @QueryService
> > > > >>> > >> interface UserQuery {
> > > > >>> > >>
> > > > >>> > >> @Query("select u from User u")
> > > > >>> > >> public List<User> getAllUsers();
> > > > >>> > >>
> > > > >>> > >> @Query("select u from User u order by u.name")
> > > > >>> > >> public List<User> getAllUsersSortedByName();
> > > > >>> > >>
> > > > >>> > >> }
> > > > >>> > >>
> > > > >>> > >> Now, it may be the case that there aren't any other use
> cases
> > > for
> > > > >>> > service
> > > > >>> > >> handlers, in which case we should perhaps just offer this
> > > > particular
> > > > >>> > >> service handler - references to type safe queries - as I
> think
> > > > this
> > > > >>> is
> > > > >>> > an
> > > > >>> > >> extremely powerful idea.
> > > > >>> > >>
> > > > >>> > >> Note, that at the moment service handlers are scheduled for
> > CDI
> > > > 1.1.
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> > > > >>> > >>
> > > > >>> > >>> Somewhat. I wouldn't really think of them as overrides,
> they,
> > > to
> > > > >>> me,
> > > > >>> > >> seem more like items to do in addition to whatever the
> > original
> > > > impl
> > > > >>> > does.
> > > > >>> > >>>
> > > > >>> > >>> ServiceHandlers to me seem more like super interceptors.
> > > > >>> > >>>
> > > > >>> > >>> Sent from my iPhone
> > > > >>> > >>>
> > > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
> > > > john.d.ament@gmail.com>
> > > > >>> > >> wrote:
> > > > >>> > >>>
> > > > >>> > >>>> @jason
> > > > >>> > >>>>
> > > > >>> > >>>> I think the concepts are very dissimilar. servicehandlers
> > > > create
> > > > >>> the
> > > > >>> > >>>> implementation. delegates are more like overrides and
> need
> > to
> > > > >>> know
> > > > >>> > >> about
> > > > >>> > >>>> the method signature.
> > > > >>> > >>>>
> > > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
> > > > >>> lightguard.jp@gmail.com
> > > > >>> > >>> wrote:
> > > > >>> > >>>>
> > > > >>> > >>>>> I think the idea of ServiceHandlers are good, but, could
> we
> > > not
> > > > >>> do
> > > > >>> > this
> > > > >>> > >>>>> with delegates?
> > > > >>> > >>>>>
> > > > >>> > >>>>> Sent from my iPhone
> > > > >>> > >>>>>
> > > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
> > > > >>> john.d.ament@gmail.com>
> > > > >>> > >> wrote:
> > > > >>> > >>>>>
> > > > >>> > >>>>>> @mark
> > > > >>> > >>>>>>
> > > > >>> > >>>>>> I don't think it's a hard requirement for it to be on an
> > > > >>> interface.
> > > > >>> > >>>>>>
> > > > >>> > >>>>>> One of the best use-cases we built at my job is using it
> > for
> > > > >>> calling
> > > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we
> > were
> > > > >>> able to
> > > > >>> > >>>>> create
> > > > >>> > >>>>>> a fairly clean wrapper API, generic enough for binding
> > > in/out
> > > > >>> > >> parameters.
> > > > >>> > >>>>>>
> > > > >>> > >>>>>> JOhn
> > > > >>> > >>>>>>
> > > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
> > > > >>> struberg@yahoo.de>
> > > > >>> > >>>>> wrote:
> > > > >>> > >>>>>>
> > > > >>> > >>>>>>> actually I don't really see a real benefit. I just
> don't
> > > yet
> > > > >>> grok
> > > > >>> > the
> > > > >>> > >>>>> use
> > > > >>> > >>>>>>> case for real world projects.
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>> Why would one intercept an Interface and delegate the
> > calls
> > > > to
> > > > >>> a
> > > > >>> > >> method
> > > > >>> > >>>>>>> handler?
> > > > >>> > >>>>>>> This could be neat for mocking, but there are better
> > > > >>> frameworks for
> > > > >>> > >>>>> that.
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>> thus
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>> -0.2
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>> LieGrue,
> > > > >>> > >>>>>>> strub
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>>> ----- Original Message -----
> > > > >>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> > > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
> > > > >>> > >>>>>>>> Cc:
> > > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> > Discuss
> > > > >>> > >>>>> ServiceHandler
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>> if you have a lot of shared code, you can extract it
> in
> > > 1-n
> > > > >>> > >> method/s or
> > > > >>> > >>>>>>> an
> > > > >>> > >>>>>>>> abstract class which is still easier than a new
> concept.
> > > > >>> > >>>>>>>> at least i haven't seen an use-case which really
> needed
> > > it.
> > > > >>> that
> > > > >>> > was
> > > > >>> > >>>>> the
> > > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok with
> > adding
> > > > >>> it).
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>> regards,
> > > > >>> > >>>>>>>> gerhard
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>>> So, you mean just write a bean with all the
> boilerplate
> > > > code
> > > > >>> in
> > > > >>> > it?
> > > > >>> > >>>>>>>>>
> > > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> > > > >>> > >>>>>>>>>
> > > > >>> > >>>>>>>>>> hi pete,
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>> instead of the interface you can just implement a
> bean
> > > > which
> > > > >>> > does
> > > > >>> > >> the
> > > > >>> > >>>>>>>>> same.
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>> regards,
> > > > >>> > >>>>>>>>>> gerhard
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > > > >>> > >>>>>>>>>>
> > > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
> > > > >>> > >>>>>>>>>>>
> > > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> > > > >>> > >>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>> +0
> > > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
> > > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms
> > instead.
> > > > >>> > >>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>> regards,
> > > > >>> > >>>>>>>>>>>> gerhard
> > > > >>> > >>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> > gerhard.petracek@gmail.com
> > > >
> > > > >>> > >>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>> hi john,
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>> regards,
> > > > >>> > >>>>>>>>>>>>> gerhard
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>> Hi All
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
> > ServiceHandler.
> > > I
> > > > >>> > >>>>>>>> added 113 as a
> > > > >>> > >>>>>>>>>>>>>> child
> > > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100%
> > > sure
> > > > >>> > >>>>>>>> (so please let
> > > > >>> > >>>>>>>>> me
> > > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
> > > > >>> > >>>>>>>> child). ServiceHandler
> > > > >>> > >>>>>>>>> is
> > > > >>> > >>>>>>>>>>> a
> > > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
> > > > >>> > >>>>>>>> interceptor that
> > > > >>> > >>>>>>>>> manages
> > > > >>> > >>>>>>>>>>>>>> generic calls against an injected interface.
> The
> > > API
> > > > >>> > >>>>>>>> is as follows:
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> > > > >>> > >>>>>>>> on an annotation that
> > > > >>> > >>>>>>>>>>> would
> > > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
> > > > >>> > >>>>>>>> interceptor would be
> > > > >>> > >>>>>>>>>>> invoked
> > > > >>> > >>>>>>>>>>>>>> for calls against this interface.
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>> It's then up to the application
> > > > >>> > >>>>>>>> developer/framework author to define
> > > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
> > > > >>> > >>>>>>>> interceptor itself
> > > > >>> > >>>>>>>>> that
> > > > >>> > >>>>>>>>>>>>>> will
> > > > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler
> would
> > be
> > > > >>> > >>>>>>>> to provide the
> > > > >>> > >>>>>>>>>>> API of
> > > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure required to
> > > make
> > > > >>> > >>>>>>>> the interceptor
> > > > >>> > >>>>>>>>>>> be
> > > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>
> > > > >>> > >>>>>>>>>
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>
> > > > >>> > >>
> > > > >>> >
> > > > >>>
> > > >
> > >
> >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>> Regards,
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>> john
> > > > >>> > >>>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>
> > > > >>> > >>>>>>>>>>>
> > > > >>> > >>>>>>>>>
> > > > >>> > >>>>>>>>>
> > > > >>> > >>>>>>>>
> > > > >>> > >>>>>>>
> > > > >>> > >>>>>
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
Hi All,
Regarding the two open questions:
1) the approach (including the name/s) we agree on will be used also for
cdi 1.1 (the only difference is the package)
2) the eg has a different opinion about it ->
It looks like the JSR's answer (https://issues.jboss.org/browse/CDI-110 )
is still unresolved - I'm not sure if we can get any further answer at this
time. The last posts on the subject seem to discuss using something along
the lines of an invocation handler, which I think would work well. Since
we have some features coming up that are interested in having service
handlers available, do we
1. Implement as is, or similar to, what is currently in Solder?
2. Push EG on a resolution
3. Do it using invocation handlers.
4. Do it some other way?
John
On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <gerhard.petracek@gmail.com
> wrote:
> hi john,
>
> as mentioned before we need the answers to the existing questions.
>
> regards,
> gerhard
>
>
>
> 2012/4/4 John D. Ament <jo...@gmail.com>
>
> > All,
> >
> > I kind of let this one and the other drop off my radar, I apologize. it
> > looks like where we last left off, Gerhard was still requesting
> additional
> > comments from everyone. Any other feedback?
> >
> > John
> >
> > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> > gerhard.petracek@gmail.com> wrote:
> >
> > > hi george,
> > >
> > > thx for the information. i thought there might be at least some
> > additional
> > > answers/clarifications, since pete asked for them in several comments.
> > > -> imo we should continue with them.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2012/3/12 George Gastaldi <ge...@gmail.com>
> > >
> > > > Hello Gerhard,
> > > >
> > > > Yeah, it´s the last state. I know it´s quite old, but I haven´t had
> > time
> > > > to work on it after that.
> > > > Regards,
> > > >
> > > > George
> > > >
> > > >
> > > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
> > > >
> > > >> hi george,
> > > >>
> > > >> thx for the link.
> > > >> i'm not sure if it is the latest state of your discussion and/or
> draft
> > > >> (at least it's quite old already).
> > > >>
> > > >> regards,
> > > >> gerhard
> > > >>
> > > >>
> > > >>
> > > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
> > > >>
> > > >>> Hi !
> > > >>>
> > > >>> +1 to #1. I also agree that the term "Service Handler" might not be
> > so
> > > >>> appropriate, so it should be discussed as well.
> > > >>> Here is the latest pull request with some comments from Pete yet to
> > be
> > > >>> reviewed: https://github.com/jboss/cdi/pull/28
> > > >>>
> > > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
> > > >>>
> > > >>> > Agreed :-)
> > > >>> >
> > > >>> > George is working on it for CDI 1.1. George, can you share your
> > > >>> proposal
> > > >>> > so far?
> > > >>> >
> > > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> > > >>> >
> > > >>> > > hi pete,
> > > >>> > >
> > > >>> > > independent of my opinion about the feature (which is still
> +0):
> > > >>> > > if it should be part of cdi 1.1, we have the following options
> > imo:
> > > >>> > >
> > > >>> > > 1) the approach (including the name/s) we agree on will be used
> > > also
> > > >>> for
> > > >>> > > cdi 1.1 (the only difference is the package)
> > > >>> > > 2) the eg has a different opinion about it ->
> > > >>> > > 2a) the rest of the eg joins this discussion
> > > >>> > > 2b) we wait for the final version and just allow the same with
> > cdi
> > > >>> 1.0
> > > >>> > > 3) if the eg doesn't agree on the idea, it should be re-visited
> > for
> > > >>> > > deltaspike (if we really need it)
> > > >>> > > 4) we agree on it independent of the result in cdi 1.1
> > > >>> > >
> > > >>> > > 1-3 is ok for me but -1 for #4
> > > >>> > >
> > > >>> > > regards,
> > > >>> > > gerhard
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
> > > >>> > >
> > > >>> > >> I'm not sure what you mean by a "super interceptor", but if
> you
> > > >>> mean it
> > > >>> > as
> > > >>> > >> in "super man" (something better than an interceptor), then I
> > > would
> > > >>> > >> disagree, it's actually a specialised form of interceptor.
> > > >>> > >>
> > > >>> > >> The best use case I know of is the one John mentions -
> creating
> > > type
> > > >>> > safe
> > > >>> > >> references to queries:
> > > >>> > >>
> > > >>> > >> @QueryService
> > > >>> > >> interface UserQuery {
> > > >>> > >>
> > > >>> > >> @Query("select u from User u")
> > > >>> > >> public List<User> getAllUsers();
> > > >>> > >>
> > > >>> > >> @Query("select u from User u order by u.name")
> > > >>> > >> public List<User> getAllUsersSortedByName();
> > > >>> > >>
> > > >>> > >> }
> > > >>> > >>
> > > >>> > >> Now, it may be the case that there aren't any other use cases
> > for
> > > >>> > service
> > > >>> > >> handlers, in which case we should perhaps just offer this
> > > particular
> > > >>> > >> service handler - references to type safe queries - as I think
> > > this
> > > >>> is
> > > >>> > an
> > > >>> > >> extremely powerful idea.
> > > >>> > >>
> > > >>> > >> Note, that at the moment service handlers are scheduled for
> CDI
> > > 1.1.
> > > >>> > >>
> > > >>> > >>
> > > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> > > >>> > >>
> > > >>> > >>> Somewhat. I wouldn't really think of them as overrides, they,
> > to
> > > >>> me,
> > > >>> > >> seem more like items to do in addition to whatever the
> original
> > > impl
> > > >>> > does.
> > > >>> > >>>
> > > >>> > >>> ServiceHandlers to me seem more like super interceptors.
> > > >>> > >>>
> > > >>> > >>> Sent from my iPhone
> > > >>> > >>>
> > > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
> > > john.d.ament@gmail.com>
> > > >>> > >> wrote:
> > > >>> > >>>
> > > >>> > >>>> @jason
> > > >>> > >>>>
> > > >>> > >>>> I think the concepts are very dissimilar. servicehandlers
> > > create
> > > >>> the
> > > >>> > >>>> implementation. delegates are more like overrides and need
> to
> > > >>> know
> > > >>> > >> about
> > > >>> > >>>> the method signature.
> > > >>> > >>>>
> > > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
> > > >>> lightguard.jp@gmail.com
> > > >>> > >>> wrote:
> > > >>> > >>>>
> > > >>> > >>>>> I think the idea of ServiceHandlers are good, but, could we
> > not
> > > >>> do
> > > >>> > this
> > > >>> > >>>>> with delegates?
> > > >>> > >>>>>
> > > >>> > >>>>> Sent from my iPhone
> > > >>> > >>>>>
> > > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
> > > >>> john.d.ament@gmail.com>
> > > >>> > >> wrote:
> > > >>> > >>>>>
> > > >>> > >>>>>> @mark
> > > >>> > >>>>>>
> > > >>> > >>>>>> I don't think it's a hard requirement for it to be on an
> > > >>> interface.
> > > >>> > >>>>>>
> > > >>> > >>>>>> One of the best use-cases we built at my job is using it
> for
> > > >>> calling
> > > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we
> were
> > > >>> able to
> > > >>> > >>>>> create
> > > >>> > >>>>>> a fairly clean wrapper API, generic enough for binding
> > in/out
> > > >>> > >> parameters.
> > > >>> > >>>>>>
> > > >>> > >>>>>> JOhn
> > > >>> > >>>>>>
> > > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
> > > >>> struberg@yahoo.de>
> > > >>> > >>>>> wrote:
> > > >>> > >>>>>>
> > > >>> > >>>>>>> actually I don't really see a real benefit. I just don't
> > yet
> > > >>> grok
> > > >>> > the
> > > >>> > >>>>> use
> > > >>> > >>>>>>> case for real world projects.
> > > >>> > >>>>>>>
> > > >>> > >>>>>>> Why would one intercept an Interface and delegate the
> calls
> > > to
> > > >>> a
> > > >>> > >> method
> > > >>> > >>>>>>> handler?
> > > >>> > >>>>>>> This could be neat for mocking, but there are better
> > > >>> frameworks for
> > > >>> > >>>>> that.
> > > >>> > >>>>>>>
> > > >>> > >>>>>>> thus
> > > >>> > >>>>>>>
> > > >>> > >>>>>>> -0.2
> > > >>> > >>>>>>>
> > > >>> > >>>>>>> LieGrue,
> > > >>> > >>>>>>> strub
> > > >>> > >>>>>>>
> > > >>> > >>>>>>>
> > > >>> > >>>>>>>
> > > >>> > >>>>>>> ----- Original Message -----
> > > >>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> > > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
> > > >>> > >>>>>>>> Cc:
> > > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> Discuss
> > > >>> > >>>>> ServiceHandler
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>> if you have a lot of shared code, you can extract it in
> > 1-n
> > > >>> > >> method/s or
> > > >>> > >>>>>>> an
> > > >>> > >>>>>>>> abstract class which is still easier than a new concept.
> > > >>> > >>>>>>>> at least i haven't seen an use-case which really needed
> > it.
> > > >>> that
> > > >>> > was
> > > >>> > >>>>> the
> > > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok with
> adding
> > > >>> it).
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>> regards,
> > > >>> > >>>>>>>> gerhard
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>>> So, you mean just write a bean with all the boilerplate
> > > code
> > > >>> in
> > > >>> > it?
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>>> hi pete,
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>> instead of the interface you can just implement a bean
> > > which
> > > >>> > does
> > > >>> > >> the
> > > >>> > >>>>>>>>> same.
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>> regards,
> > > >>> > >>>>>>>>>> gerhard
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > > >>> > >>>>>>>>>>
> > > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>>>> +0
> > > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
> > > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms
> instead.
> > > >>> > >>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>> regards,
> > > >>> > >>>>>>>>>>>> gerhard
> > > >>> > >>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> gerhard.petracek@gmail.com
> > >
> > > >>> > >>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>> hi john,
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>> regards,
> > > >>> > >>>>>>>>>>>>> gerhard
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>> Hi All
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of
> ServiceHandler.
> > I
> > > >>> > >>>>>>>> added 113 as a
> > > >>> > >>>>>>>>>>>>>> child
> > > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100%
> > sure
> > > >>> > >>>>>>>> (so please let
> > > >>> > >>>>>>>>> me
> > > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
> > > >>> > >>>>>>>> child). ServiceHandler
> > > >>> > >>>>>>>>> is
> > > >>> > >>>>>>>>>>> a
> > > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
> > > >>> > >>>>>>>> interceptor that
> > > >>> > >>>>>>>>> manages
> > > >>> > >>>>>>>>>>>>>> generic calls against an injected interface. The
> > API
> > > >>> > >>>>>>>> is as follows:
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> > > >>> > >>>>>>>> on an annotation that
> > > >>> > >>>>>>>>>>> would
> > > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
> > > >>> > >>>>>>>> interceptor would be
> > > >>> > >>>>>>>>>>> invoked
> > > >>> > >>>>>>>>>>>>>> for calls against this interface.
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>> It's then up to the application
> > > >>> > >>>>>>>> developer/framework author to define
> > > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
> > > >>> > >>>>>>>> interceptor itself
> > > >>> > >>>>>>>>> that
> > > >>> > >>>>>>>>>>>>>> will
> > > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would
> be
> > > >>> > >>>>>>>> to provide the
> > > >>> > >>>>>>>>>>> API of
> > > >>> > >>>>>>>>>>>>>> the type and then the infrastructure required to
> > make
> > > >>> > >>>>>>>> the interceptor
> > > >>> > >>>>>>>>>>> be
> > > >>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>
> > > >>> > >>>>>
> > > >>> > >>
> > > >>> >
> > > >>>
> > >
> >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>> Regards,
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>> john
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>
> > > >>> > >>>>>
> > > >>> > >>
> > > >>> > >>
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
as mentioned before we need the answers to the existing questions.
regards,
gerhard
2012/4/4 John D. Ament <jo...@gmail.com>
> All,
>
> I kind of let this one and the other drop off my radar, I apologize. it
> looks like where we last left off, Gerhard was still requesting additional
> comments from everyone. Any other feedback?
>
> John
>
> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> gerhard.petracek@gmail.com> wrote:
>
> > hi george,
> >
> > thx for the information. i thought there might be at least some
> additional
> > answers/clarifications, since pete asked for them in several comments.
> > -> imo we should continue with them.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/3/12 George Gastaldi <ge...@gmail.com>
> >
> > > Hello Gerhard,
> > >
> > > Yeah, it´s the last state. I know it´s quite old, but I haven´t had
> time
> > > to work on it after that.
> > > Regards,
> > >
> > > George
> > >
> > >
> > > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
> > >
> > >> hi george,
> > >>
> > >> thx for the link.
> > >> i'm not sure if it is the latest state of your discussion and/or draft
> > >> (at least it's quite old already).
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >>
> > >>
> > >> 2012/3/7 George Gastaldi <ge...@gmail.com>
> > >>
> > >>> Hi !
> > >>>
> > >>> +1 to #1. I also agree that the term "Service Handler" might not be
> so
> > >>> appropriate, so it should be discussed as well.
> > >>> Here is the latest pull request with some comments from Pete yet to
> be
> > >>> reviewed: https://github.com/jboss/cdi/pull/28
> > >>>
> > >>> 2012/3/7 Pete Muir <pm...@redhat.com>
> > >>>
> > >>> > Agreed :-)
> > >>> >
> > >>> > George is working on it for CDI 1.1. George, can you share your
> > >>> proposal
> > >>> > so far?
> > >>> >
> > >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> > >>> >
> > >>> > > hi pete,
> > >>> > >
> > >>> > > independent of my opinion about the feature (which is still +0):
> > >>> > > if it should be part of cdi 1.1, we have the following options
> imo:
> > >>> > >
> > >>> > > 1) the approach (including the name/s) we agree on will be used
> > also
> > >>> for
> > >>> > > cdi 1.1 (the only difference is the package)
> > >>> > > 2) the eg has a different opinion about it ->
> > >>> > > 2a) the rest of the eg joins this discussion
> > >>> > > 2b) we wait for the final version and just allow the same with
> cdi
> > >>> 1.0
> > >>> > > 3) if the eg doesn't agree on the idea, it should be re-visited
> for
> > >>> > > deltaspike (if we really need it)
> > >>> > > 4) we agree on it independent of the result in cdi 1.1
> > >>> > >
> > >>> > > 1-3 is ok for me but -1 for #4
> > >>> > >
> > >>> > > regards,
> > >>> > > gerhard
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
> > >>> > >
> > >>> > >> I'm not sure what you mean by a "super interceptor", but if you
> > >>> mean it
> > >>> > as
> > >>> > >> in "super man" (something better than an interceptor), then I
> > would
> > >>> > >> disagree, it's actually a specialised form of interceptor.
> > >>> > >>
> > >>> > >> The best use case I know of is the one John mentions - creating
> > type
> > >>> > safe
> > >>> > >> references to queries:
> > >>> > >>
> > >>> > >> @QueryService
> > >>> > >> interface UserQuery {
> > >>> > >>
> > >>> > >> @Query("select u from User u")
> > >>> > >> public List<User> getAllUsers();
> > >>> > >>
> > >>> > >> @Query("select u from User u order by u.name")
> > >>> > >> public List<User> getAllUsersSortedByName();
> > >>> > >>
> > >>> > >> }
> > >>> > >>
> > >>> > >> Now, it may be the case that there aren't any other use cases
> for
> > >>> > service
> > >>> > >> handlers, in which case we should perhaps just offer this
> > particular
> > >>> > >> service handler - references to type safe queries - as I think
> > this
> > >>> is
> > >>> > an
> > >>> > >> extremely powerful idea.
> > >>> > >>
> > >>> > >> Note, that at the moment service handlers are scheduled for CDI
> > 1.1.
> > >>> > >>
> > >>> > >>
> > >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> > >>> > >>
> > >>> > >>> Somewhat. I wouldn't really think of them as overrides, they,
> to
> > >>> me,
> > >>> > >> seem more like items to do in addition to whatever the original
> > impl
> > >>> > does.
> > >>> > >>>
> > >>> > >>> ServiceHandlers to me seem more like super interceptors.
> > >>> > >>>
> > >>> > >>> Sent from my iPhone
> > >>> > >>>
> > >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
> > john.d.ament@gmail.com>
> > >>> > >> wrote:
> > >>> > >>>
> > >>> > >>>> @jason
> > >>> > >>>>
> > >>> > >>>> I think the concepts are very dissimilar. servicehandlers
> > create
> > >>> the
> > >>> > >>>> implementation. delegates are more like overrides and need to
> > >>> know
> > >>> > >> about
> > >>> > >>>> the method signature.
> > >>> > >>>>
> > >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
> > >>> lightguard.jp@gmail.com
> > >>> > >>> wrote:
> > >>> > >>>>
> > >>> > >>>>> I think the idea of ServiceHandlers are good, but, could we
> not
> > >>> do
> > >>> > this
> > >>> > >>>>> with delegates?
> > >>> > >>>>>
> > >>> > >>>>> Sent from my iPhone
> > >>> > >>>>>
> > >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
> > >>> john.d.ament@gmail.com>
> > >>> > >> wrote:
> > >>> > >>>>>
> > >>> > >>>>>> @mark
> > >>> > >>>>>>
> > >>> > >>>>>> I don't think it's a hard requirement for it to be on an
> > >>> interface.
> > >>> > >>>>>>
> > >>> > >>>>>> One of the best use-cases we built at my job is using it for
> > >>> calling
> > >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were
> > >>> able to
> > >>> > >>>>> create
> > >>> > >>>>>> a fairly clean wrapper API, generic enough for binding
> in/out
> > >>> > >> parameters.
> > >>> > >>>>>>
> > >>> > >>>>>> JOhn
> > >>> > >>>>>>
> > >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
> > >>> struberg@yahoo.de>
> > >>> > >>>>> wrote:
> > >>> > >>>>>>
> > >>> > >>>>>>> actually I don't really see a real benefit. I just don't
> yet
> > >>> grok
> > >>> > the
> > >>> > >>>>> use
> > >>> > >>>>>>> case for real world projects.
> > >>> > >>>>>>>
> > >>> > >>>>>>> Why would one intercept an Interface and delegate the calls
> > to
> > >>> a
> > >>> > >> method
> > >>> > >>>>>>> handler?
> > >>> > >>>>>>> This could be neat for mocking, but there are better
> > >>> frameworks for
> > >>> > >>>>> that.
> > >>> > >>>>>>>
> > >>> > >>>>>>> thus
> > >>> > >>>>>>>
> > >>> > >>>>>>> -0.2
> > >>> > >>>>>>>
> > >>> > >>>>>>> LieGrue,
> > >>> > >>>>>>> strub
> > >>> > >>>>>>>
> > >>> > >>>>>>>
> > >>> > >>>>>>>
> > >>> > >>>>>>> ----- Original Message -----
> > >>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> > >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
> > >>> > >>>>>>>> Cc:
> > >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > >>> > >>>>> ServiceHandler
> > >>> > >>>>>>>>
> > >>> > >>>>>>>> if you have a lot of shared code, you can extract it in
> 1-n
> > >>> > >> method/s or
> > >>> > >>>>>>> an
> > >>> > >>>>>>>> abstract class which is still easier than a new concept.
> > >>> > >>>>>>>> at least i haven't seen an use-case which really needed
> it.
> > >>> that
> > >>> > was
> > >>> > >>>>> the
> > >>> > >>>>>>>> reason for a +0 (which still means that i'm ok with adding
> > >>> it).
> > >>> > >>>>>>>>
> > >>> > >>>>>>>> regards,
> > >>> > >>>>>>>> gerhard
> > >>> > >>>>>>>>
> > >>> > >>>>>>>>
> > >>> > >>>>>>>>
> > >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > >>> > >>>>>>>>
> > >>> > >>>>>>>>> So, you mean just write a bean with all the boilerplate
> > code
> > >>> in
> > >>> > it?
> > >>> > >>>>>>>>>
> > >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> > >>> > >>>>>>>>>
> > >>> > >>>>>>>>>> hi pete,
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>> instead of the interface you can just implement a bean
> > which
> > >>> > does
> > >>> > >> the
> > >>> > >>>>>>>>> same.
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>> regards,
> > >>> > >>>>>>>>>> gerhard
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > >>> > >>>>>>>>>>
> > >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
> > >>> > >>>>>>>>>>>
> > >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> > >>> > >>>>>>>>>>>
> > >>> > >>>>>>>>>>>> +0
> > >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
> > >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
> > >>> > >>>>>>>>>>>>
> > >>> > >>>>>>>>>>>> regards,
> > >>> > >>>>>>>>>>>> gerhard
> > >>> > >>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>
> > >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <gerhard.petracek@gmail.com
> >
> > >>> > >>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>> hi john,
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>> regards,
> > >>> > >>>>>>>>>>>>> gerhard
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>> Hi All
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler.
> I
> > >>> > >>>>>>>> added 113 as a
> > >>> > >>>>>>>>>>>>>> child
> > >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100%
> sure
> > >>> > >>>>>>>> (so please let
> > >>> > >>>>>>>>> me
> > >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
> > >>> > >>>>>>>> child). ServiceHandler
> > >>> > >>>>>>>>> is
> > >>> > >>>>>>>>>>> a
> > >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
> > >>> > >>>>>>>> interceptor that
> > >>> > >>>>>>>>> manages
> > >>> > >>>>>>>>>>>>>> generic calls against an injected interface. The
> API
> > >>> > >>>>>>>> is as follows:
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> > >>> > >>>>>>>> on an annotation that
> > >>> > >>>>>>>>>>> would
> > >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
> > >>> > >>>>>>>> interceptor would be
> > >>> > >>>>>>>>>>> invoked
> > >>> > >>>>>>>>>>>>>> for calls against this interface.
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>> It's then up to the application
> > >>> > >>>>>>>> developer/framework author to define
> > >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
> > >>> > >>>>>>>> interceptor itself
> > >>> > >>>>>>>>> that
> > >>> > >>>>>>>>>>>>>> will
> > >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
> > >>> > >>>>>>>> to provide the
> > >>> > >>>>>>>>>>> API of
> > >>> > >>>>>>>>>>>>>> the type and then the infrastructure required to
> make
> > >>> > >>>>>>>> the interceptor
> > >>> > >>>>>>>>>>> be
> > >>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>
> > >>> > >>>>>>>>>
> > >>> > >>>>>>>>
> > >>> > >>>>>>>
> > >>> > >>>>>
> > >>> > >>
> > >>> >
> > >>>
> >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>> Regards,
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>> john
> > >>> > >>>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>>>
> > >>> > >>>>>>>>>>>
> > >>> > >>>>>>>>>>>
> > >>> > >>>>>>>>>
> > >>> > >>>>>>>>>
> > >>> > >>>>>>>>
> > >>> > >>>>>>>
> > >>> > >>>>>
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
All,
I kind of let this one and the other drop off my radar, I apologize. it
looks like where we last left off, Gerhard was still requesting additional
comments from everyone. Any other feedback?
John
On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:
> hi george,
>
> thx for the information. i thought there might be at least some additional
> answers/clarifications, since pete asked for them in several comments.
> -> imo we should continue with them.
>
> regards,
> gerhard
>
>
>
> 2012/3/12 George Gastaldi <ge...@gmail.com>
>
> > Hello Gerhard,
> >
> > Yeah, it´s the last state. I know it´s quite old, but I haven´t had time
> > to work on it after that.
> > Regards,
> >
> > George
> >
> >
> > 2012/3/12 Gerhard Petracek <ge...@gmail.com>
> >
> >> hi george,
> >>
> >> thx for the link.
> >> i'm not sure if it is the latest state of your discussion and/or draft
> >> (at least it's quite old already).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/3/7 George Gastaldi <ge...@gmail.com>
> >>
> >>> Hi !
> >>>
> >>> +1 to #1. I also agree that the term "Service Handler" might not be so
> >>> appropriate, so it should be discussed as well.
> >>> Here is the latest pull request with some comments from Pete yet to be
> >>> reviewed: https://github.com/jboss/cdi/pull/28
> >>>
> >>> 2012/3/7 Pete Muir <pm...@redhat.com>
> >>>
> >>> > Agreed :-)
> >>> >
> >>> > George is working on it for CDI 1.1. George, can you share your
> >>> proposal
> >>> > so far?
> >>> >
> >>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> >>> >
> >>> > > hi pete,
> >>> > >
> >>> > > independent of my opinion about the feature (which is still +0):
> >>> > > if it should be part of cdi 1.1, we have the following options imo:
> >>> > >
> >>> > > 1) the approach (including the name/s) we agree on will be used
> also
> >>> for
> >>> > > cdi 1.1 (the only difference is the package)
> >>> > > 2) the eg has a different opinion about it ->
> >>> > > 2a) the rest of the eg joins this discussion
> >>> > > 2b) we wait for the final version and just allow the same with cdi
> >>> 1.0
> >>> > > 3) if the eg doesn't agree on the idea, it should be re-visited for
> >>> > > deltaspike (if we really need it)
> >>> > > 4) we agree on it independent of the result in cdi 1.1
> >>> > >
> >>> > > 1-3 is ok for me but -1 for #4
> >>> > >
> >>> > > regards,
> >>> > > gerhard
> >>> > >
> >>> > >
> >>> > >
> >>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
> >>> > >
> >>> > >> I'm not sure what you mean by a "super interceptor", but if you
> >>> mean it
> >>> > as
> >>> > >> in "super man" (something better than an interceptor), then I
> would
> >>> > >> disagree, it's actually a specialised form of interceptor.
> >>> > >>
> >>> > >> The best use case I know of is the one John mentions - creating
> type
> >>> > safe
> >>> > >> references to queries:
> >>> > >>
> >>> > >> @QueryService
> >>> > >> interface UserQuery {
> >>> > >>
> >>> > >> @Query("select u from User u")
> >>> > >> public List<User> getAllUsers();
> >>> > >>
> >>> > >> @Query("select u from User u order by u.name")
> >>> > >> public List<User> getAllUsersSortedByName();
> >>> > >>
> >>> > >> }
> >>> > >>
> >>> > >> Now, it may be the case that there aren't any other use cases for
> >>> > service
> >>> > >> handlers, in which case we should perhaps just offer this
> particular
> >>> > >> service handler - references to type safe queries - as I think
> this
> >>> is
> >>> > an
> >>> > >> extremely powerful idea.
> >>> > >>
> >>> > >> Note, that at the moment service handlers are scheduled for CDI
> 1.1.
> >>> > >>
> >>> > >>
> >>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> >>> > >>
> >>> > >>> Somewhat. I wouldn't really think of them as overrides, they, to
> >>> me,
> >>> > >> seem more like items to do in addition to whatever the original
> impl
> >>> > does.
> >>> > >>>
> >>> > >>> ServiceHandlers to me seem more like super interceptors.
> >>> > >>>
> >>> > >>> Sent from my iPhone
> >>> > >>>
> >>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <
> john.d.ament@gmail.com>
> >>> > >> wrote:
> >>> > >>>
> >>> > >>>> @jason
> >>> > >>>>
> >>> > >>>> I think the concepts are very dissimilar. servicehandlers
> create
> >>> the
> >>> > >>>> implementation. delegates are more like overrides and need to
> >>> know
> >>> > >> about
> >>> > >>>> the method signature.
> >>> > >>>>
> >>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
> >>> lightguard.jp@gmail.com
> >>> > >>> wrote:
> >>> > >>>>
> >>> > >>>>> I think the idea of ServiceHandlers are good, but, could we not
> >>> do
> >>> > this
> >>> > >>>>> with delegates?
> >>> > >>>>>
> >>> > >>>>> Sent from my iPhone
> >>> > >>>>>
> >>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
> >>> john.d.ament@gmail.com>
> >>> > >> wrote:
> >>> > >>>>>
> >>> > >>>>>> @mark
> >>> > >>>>>>
> >>> > >>>>>> I don't think it's a hard requirement for it to be on an
> >>> interface.
> >>> > >>>>>>
> >>> > >>>>>> One of the best use-cases we built at my job is using it for
> >>> calling
> >>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were
> >>> able to
> >>> > >>>>> create
> >>> > >>>>>> a fairly clean wrapper API, generic enough for binding in/out
> >>> > >> parameters.
> >>> > >>>>>>
> >>> > >>>>>> JOhn
> >>> > >>>>>>
> >>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>> struberg@yahoo.de>
> >>> > >>>>> wrote:
> >>> > >>>>>>
> >>> > >>>>>>> actually I don't really see a real benefit. I just don't yet
> >>> grok
> >>> > the
> >>> > >>>>> use
> >>> > >>>>>>> case for real world projects.
> >>> > >>>>>>>
> >>> > >>>>>>> Why would one intercept an Interface and delegate the calls
> to
> >>> a
> >>> > >> method
> >>> > >>>>>>> handler?
> >>> > >>>>>>> This could be neat for mocking, but there are better
> >>> frameworks for
> >>> > >>>>> that.
> >>> > >>>>>>>
> >>> > >>>>>>> thus
> >>> > >>>>>>>
> >>> > >>>>>>> -0.2
> >>> > >>>>>>>
> >>> > >>>>>>> LieGrue,
> >>> > >>>>>>> strub
> >>> > >>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>>> ----- Original Message -----
> >>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> >>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
> >>> > >>>>>>>> Cc:
> >>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>> > >>>>> ServiceHandler
> >>> > >>>>>>>>
> >>> > >>>>>>>> if you have a lot of shared code, you can extract it in 1-n
> >>> > >> method/s or
> >>> > >>>>>>> an
> >>> > >>>>>>>> abstract class which is still easier than a new concept.
> >>> > >>>>>>>> at least i haven't seen an use-case which really needed it.
> >>> that
> >>> > was
> >>> > >>>>> the
> >>> > >>>>>>>> reason for a +0 (which still means that i'm ok with adding
> >>> it).
> >>> > >>>>>>>>
> >>> > >>>>>>>> regards,
> >>> > >>>>>>>> gerhard
> >>> > >>>>>>>>
> >>> > >>>>>>>>
> >>> > >>>>>>>>
> >>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>> > >>>>>>>>
> >>> > >>>>>>>>> So, you mean just write a bean with all the boilerplate
> code
> >>> in
> >>> > it?
> >>> > >>>>>>>>>
> >>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> >>> > >>>>>>>>>
> >>> > >>>>>>>>>> hi pete,
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>> instead of the interface you can just implement a bean
> which
> >>> > does
> >>> > >> the
> >>> > >>>>>>>>> same.
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>> regards,
> >>> > >>>>>>>>>> gerhard
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>> > >>>>>>>>>>
> >>> > >>>>>>>>>>> What CDI mechanism would you use instead?
> >>> > >>>>>>>>>>>
> >>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >>> > >>>>>>>>>>>
> >>> > >>>>>>>>>>>> +0
> >>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
> >>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
> >>> > >>>>>>>>>>>>
> >>> > >>>>>>>>>>>> regards,
> >>> > >>>>>>>>>>>> gerhard
> >>> > >>>>>>>>>>>>
> >>> > >>>>>>>>>>>>
> >>> > >>>>>>>>>>>>
> >>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >>> > >>>>>>>>>>>>
> >>> > >>>>>>>>>>>>> hi john,
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>> regards,
> >>> > >>>>>>>>>>>>> gerhard
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>> Hi All
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
> >>> > >>>>>>>> added 113 as a
> >>> > >>>>>>>>>>>>>> child
> >>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> >>> > >>>>>>>> (so please let
> >>> > >>>>>>>>> me
> >>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
> >>> > >>>>>>>> child). ServiceHandler
> >>> > >>>>>>>>> is
> >>> > >>>>>>>>>>> a
> >>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
> >>> > >>>>>>>> interceptor that
> >>> > >>>>>>>>> manages
> >>> > >>>>>>>>>>>>>> generic calls against an injected interface. The API
> >>> > >>>>>>>> is as follows:
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> >>> > >>>>>>>> on an annotation that
> >>> > >>>>>>>>>>> would
> >>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
> >>> > >>>>>>>> interceptor would be
> >>> > >>>>>>>>>>> invoked
> >>> > >>>>>>>>>>>>>> for calls against this interface.
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>> It's then up to the application
> >>> > >>>>>>>> developer/framework author to define
> >>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
> >>> > >>>>>>>> interceptor itself
> >>> > >>>>>>>>> that
> >>> > >>>>>>>>>>>>>> will
> >>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
> >>> > >>>>>>>> to provide the
> >>> > >>>>>>>>>>> API of
> >>> > >>>>>>>>>>>>>> the type and then the infrastructure required to make
> >>> > >>>>>>>> the interceptor
> >>> > >>>>>>>>>>> be
> >>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>
> >>> > >>>>>>>>>
> >>> > >>>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>
> >>> > >>
> >>> >
> >>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>> Regards,
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>> john
> >>> > >>>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>>>
> >>> > >>>>>>>>>>>
> >>> > >>>>>>>>>>>
> >>> > >>>>>>>>>
> >>> > >>>>>>>>>
> >>> > >>>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>
> >>> > >>
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi george,
thx for the information. i thought there might be at least some additional
answers/clarifications, since pete asked for them in several comments.
-> imo we should continue with them.
regards,
gerhard
2012/3/12 George Gastaldi <ge...@gmail.com>
> Hello Gerhard,
>
> Yeah, it´s the last state. I know it´s quite old, but I haven´t had time
> to work on it after that.
> Regards,
>
> George
>
>
> 2012/3/12 Gerhard Petracek <ge...@gmail.com>
>
>> hi george,
>>
>> thx for the link.
>> i'm not sure if it is the latest state of your discussion and/or draft
>> (at least it's quite old already).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/3/7 George Gastaldi <ge...@gmail.com>
>>
>>> Hi !
>>>
>>> +1 to #1. I also agree that the term "Service Handler" might not be so
>>> appropriate, so it should be discussed as well.
>>> Here is the latest pull request with some comments from Pete yet to be
>>> reviewed: https://github.com/jboss/cdi/pull/28
>>>
>>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>>
>>> > Agreed :-)
>>> >
>>> > George is working on it for CDI 1.1. George, can you share your
>>> proposal
>>> > so far?
>>> >
>>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>>> >
>>> > > hi pete,
>>> > >
>>> > > independent of my opinion about the feature (which is still +0):
>>> > > if it should be part of cdi 1.1, we have the following options imo:
>>> > >
>>> > > 1) the approach (including the name/s) we agree on will be used also
>>> for
>>> > > cdi 1.1 (the only difference is the package)
>>> > > 2) the eg has a different opinion about it ->
>>> > > 2a) the rest of the eg joins this discussion
>>> > > 2b) we wait for the final version and just allow the same with cdi
>>> 1.0
>>> > > 3) if the eg doesn't agree on the idea, it should be re-visited for
>>> > > deltaspike (if we really need it)
>>> > > 4) we agree on it independent of the result in cdi 1.1
>>> > >
>>> > > 1-3 is ok for me but -1 for #4
>>> > >
>>> > > regards,
>>> > > gerhard
>>> > >
>>> > >
>>> > >
>>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>>> > >
>>> > >> I'm not sure what you mean by a "super interceptor", but if you
>>> mean it
>>> > as
>>> > >> in "super man" (something better than an interceptor), then I would
>>> > >> disagree, it's actually a specialised form of interceptor.
>>> > >>
>>> > >> The best use case I know of is the one John mentions - creating type
>>> > safe
>>> > >> references to queries:
>>> > >>
>>> > >> @QueryService
>>> > >> interface UserQuery {
>>> > >>
>>> > >> @Query("select u from User u")
>>> > >> public List<User> getAllUsers();
>>> > >>
>>> > >> @Query("select u from User u order by u.name")
>>> > >> public List<User> getAllUsersSortedByName();
>>> > >>
>>> > >> }
>>> > >>
>>> > >> Now, it may be the case that there aren't any other use cases for
>>> > service
>>> > >> handlers, in which case we should perhaps just offer this particular
>>> > >> service handler - references to type safe queries - as I think this
>>> is
>>> > an
>>> > >> extremely powerful idea.
>>> > >>
>>> > >> Note, that at the moment service handlers are scheduled for CDI 1.1.
>>> > >>
>>> > >>
>>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>> > >>
>>> > >>> Somewhat. I wouldn't really think of them as overrides, they, to
>>> me,
>>> > >> seem more like items to do in addition to whatever the original impl
>>> > does.
>>> > >>>
>>> > >>> ServiceHandlers to me seem more like super interceptors.
>>> > >>>
>>> > >>> Sent from my iPhone
>>> > >>>
>>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
>>> > >> wrote:
>>> > >>>
>>> > >>>> @jason
>>> > >>>>
>>> > >>>> I think the concepts are very dissimilar. servicehandlers create
>>> the
>>> > >>>> implementation. delegates are more like overrides and need to
>>> know
>>> > >> about
>>> > >>>> the method signature.
>>> > >>>>
>>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>>> lightguard.jp@gmail.com
>>> > >>> wrote:
>>> > >>>>
>>> > >>>>> I think the idea of ServiceHandlers are good, but, could we not
>>> do
>>> > this
>>> > >>>>> with delegates?
>>> > >>>>>
>>> > >>>>> Sent from my iPhone
>>> > >>>>>
>>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <
>>> john.d.ament@gmail.com>
>>> > >> wrote:
>>> > >>>>>
>>> > >>>>>> @mark
>>> > >>>>>>
>>> > >>>>>> I don't think it's a hard requirement for it to be on an
>>> interface.
>>> > >>>>>>
>>> > >>>>>> One of the best use-cases we built at my job is using it for
>>> calling
>>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were
>>> able to
>>> > >>>>> create
>>> > >>>>>> a fairly clean wrapper API, generic enough for binding in/out
>>> > >> parameters.
>>> > >>>>>>
>>> > >>>>>> JOhn
>>> > >>>>>>
>>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>> struberg@yahoo.de>
>>> > >>>>> wrote:
>>> > >>>>>>
>>> > >>>>>>> actually I don't really see a real benefit. I just don't yet
>>> grok
>>> > the
>>> > >>>>> use
>>> > >>>>>>> case for real world projects.
>>> > >>>>>>>
>>> > >>>>>>> Why would one intercept an Interface and delegate the calls to
>>> a
>>> > >> method
>>> > >>>>>>> handler?
>>> > >>>>>>> This could be neat for mocking, but there are better
>>> frameworks for
>>> > >>>>> that.
>>> > >>>>>>>
>>> > >>>>>>> thus
>>> > >>>>>>>
>>> > >>>>>>> -0.2
>>> > >>>>>>>
>>> > >>>>>>> LieGrue,
>>> > >>>>>>> strub
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>> ----- Original Message -----
>>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
>>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>>> > >>>>>>>> Cc:
>>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>> > >>>>> ServiceHandler
>>> > >>>>>>>>
>>> > >>>>>>>> if you have a lot of shared code, you can extract it in 1-n
>>> > >> method/s or
>>> > >>>>>>> an
>>> > >>>>>>>> abstract class which is still easier than a new concept.
>>> > >>>>>>>> at least i haven't seen an use-case which really needed it.
>>> that
>>> > was
>>> > >>>>> the
>>> > >>>>>>>> reason for a +0 (which still means that i'm ok with adding
>>> it).
>>> > >>>>>>>>
>>> > >>>>>>>> regards,
>>> > >>>>>>>> gerhard
>>> > >>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>> > >>>>>>>>
>>> > >>>>>>>>> So, you mean just write a bean with all the boilerplate code
>>> in
>>> > it?
>>> > >>>>>>>>>
>>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>> > >>>>>>>>>
>>> > >>>>>>>>>> hi pete,
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> instead of the interface you can just implement a bean which
>>> > does
>>> > >> the
>>> > >>>>>>>>> same.
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> regards,
>>> > >>>>>>>>>> gerhard
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>>> +0
>>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> regards,
>>> > >>>>>>>>>>>> gerhard
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>> hi john,
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> regards,
>>> > >>>>>>>>>>>>> gerhard
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> Hi All
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>> > >>>>>>>> added 113 as a
>>> > >>>>>>>>>>>>>> child
>>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>> > >>>>>>>> (so please let
>>> > >>>>>>>>> me
>>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
>>> > >>>>>>>> child). ServiceHandler
>>> > >>>>>>>>> is
>>> > >>>>>>>>>>> a
>>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
>>> > >>>>>>>> interceptor that
>>> > >>>>>>>>> manages
>>> > >>>>>>>>>>>>>> generic calls against an injected interface. The API
>>> > >>>>>>>> is as follows:
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>> > >>>>>>>> on an annotation that
>>> > >>>>>>>>>>> would
>>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
>>> > >>>>>>>> interceptor would be
>>> > >>>>>>>>>>> invoked
>>> > >>>>>>>>>>>>>> for calls against this interface.
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> It's then up to the application
>>> > >>>>>>>> developer/framework author to define
>>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
>>> > >>>>>>>> interceptor itself
>>> > >>>>>>>>> that
>>> > >>>>>>>>>>>>>> will
>>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>> > >>>>>>>> to provide the
>>> > >>>>>>>>>>> API of
>>> > >>>>>>>>>>>>>> the type and then the infrastructure required to make
>>> > >>>>>>>> the interceptor
>>> > >>>>>>>>>>> be
>>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>
>>> > >>>>>
>>> > >>
>>> >
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> Regards,
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> john
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>
>>> > >>>>>
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by George Gastaldi <ge...@gmail.com>.
Hello Gerhard,
Yeah, it´s the last state. I know it´s quite old, but I haven´t had time to
work on it after that.
Regards,
George
2012/3/12 Gerhard Petracek <ge...@gmail.com>
> hi george,
>
> thx for the link.
> i'm not sure if it is the latest state of your discussion and/or draft (at
> least it's quite old already).
>
> regards,
> gerhard
>
>
>
> 2012/3/7 George Gastaldi <ge...@gmail.com>
>
>> Hi !
>>
>> +1 to #1. I also agree that the term "Service Handler" might not be so
>> appropriate, so it should be discussed as well.
>> Here is the latest pull request with some comments from Pete yet to be
>> reviewed: https://github.com/jboss/cdi/pull/28
>>
>> 2012/3/7 Pete Muir <pm...@redhat.com>
>>
>> > Agreed :-)
>> >
>> > George is working on it for CDI 1.1. George, can you share your proposal
>> > so far?
>> >
>> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>> >
>> > > hi pete,
>> > >
>> > > independent of my opinion about the feature (which is still +0):
>> > > if it should be part of cdi 1.1, we have the following options imo:
>> > >
>> > > 1) the approach (including the name/s) we agree on will be used also
>> for
>> > > cdi 1.1 (the only difference is the package)
>> > > 2) the eg has a different opinion about it ->
>> > > 2a) the rest of the eg joins this discussion
>> > > 2b) we wait for the final version and just allow the same with cdi 1.0
>> > > 3) if the eg doesn't agree on the idea, it should be re-visited for
>> > > deltaspike (if we really need it)
>> > > 4) we agree on it independent of the result in cdi 1.1
>> > >
>> > > 1-3 is ok for me but -1 for #4
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > >
>> > >
>> > > 2012/3/7 Pete Muir <pm...@redhat.com>
>> > >
>> > >> I'm not sure what you mean by a "super interceptor", but if you mean
>> it
>> > as
>> > >> in "super man" (something better than an interceptor), then I would
>> > >> disagree, it's actually a specialised form of interceptor.
>> > >>
>> > >> The best use case I know of is the one John mentions - creating type
>> > safe
>> > >> references to queries:
>> > >>
>> > >> @QueryService
>> > >> interface UserQuery {
>> > >>
>> > >> @Query("select u from User u")
>> > >> public List<User> getAllUsers();
>> > >>
>> > >> @Query("select u from User u order by u.name")
>> > >> public List<User> getAllUsersSortedByName();
>> > >>
>> > >> }
>> > >>
>> > >> Now, it may be the case that there aren't any other use cases for
>> > service
>> > >> handlers, in which case we should perhaps just offer this particular
>> > >> service handler - references to type safe queries - as I think this
>> is
>> > an
>> > >> extremely powerful idea.
>> > >>
>> > >> Note, that at the moment service handlers are scheduled for CDI 1.1.
>> > >>
>> > >>
>> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>> > >>
>> > >>> Somewhat. I wouldn't really think of them as overrides, they, to me,
>> > >> seem more like items to do in addition to whatever the original impl
>> > does.
>> > >>>
>> > >>> ServiceHandlers to me seem more like super interceptors.
>> > >>>
>> > >>> Sent from my iPhone
>> > >>>
>> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
>> > >> wrote:
>> > >>>
>> > >>>> @jason
>> > >>>>
>> > >>>> I think the concepts are very dissimilar. servicehandlers create
>> the
>> > >>>> implementation. delegates are more like overrides and need to know
>> > >> about
>> > >>>> the method signature.
>> > >>>>
>> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
>> lightguard.jp@gmail.com
>> > >>> wrote:
>> > >>>>
>> > >>>>> I think the idea of ServiceHandlers are good, but, could we not do
>> > this
>> > >>>>> with delegates?
>> > >>>>>
>> > >>>>> Sent from my iPhone
>> > >>>>>
>> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <john.d.ament@gmail.com
>> >
>> > >> wrote:
>> > >>>>>
>> > >>>>>> @mark
>> > >>>>>>
>> > >>>>>> I don't think it's a hard requirement for it to be on an
>> interface.
>> > >>>>>>
>> > >>>>>> One of the best use-cases we built at my job is using it for
>> calling
>> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were
>> able to
>> > >>>>> create
>> > >>>>>> a fairly clean wrapper API, generic enough for binding in/out
>> > >> parameters.
>> > >>>>>>
>> > >>>>>> JOhn
>> > >>>>>>
>> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <
>> struberg@yahoo.de>
>> > >>>>> wrote:
>> > >>>>>>
>> > >>>>>>> actually I don't really see a real benefit. I just don't yet
>> grok
>> > the
>> > >>>>> use
>> > >>>>>>> case for real world projects.
>> > >>>>>>>
>> > >>>>>>> Why would one intercept an Interface and delegate the calls to a
>> > >> method
>> > >>>>>>> handler?
>> > >>>>>>> This could be neat for mocking, but there are better frameworks
>> for
>> > >>>>> that.
>> > >>>>>>>
>> > >>>>>>> thus
>> > >>>>>>>
>> > >>>>>>> -0.2
>> > >>>>>>>
>> > >>>>>>> LieGrue,
>> > >>>>>>> strub
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> ----- Original Message -----
>> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
>> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
>> > >>>>>>>> Cc:
>> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>> > >>>>> ServiceHandler
>> > >>>>>>>>
>> > >>>>>>>> if you have a lot of shared code, you can extract it in 1-n
>> > >> method/s or
>> > >>>>>>> an
>> > >>>>>>>> abstract class which is still easier than a new concept.
>> > >>>>>>>> at least i haven't seen an use-case which really needed it.
>> that
>> > was
>> > >>>>> the
>> > >>>>>>>> reason for a +0 (which still means that i'm ok with adding it).
>> > >>>>>>>>
>> > >>>>>>>> regards,
>> > >>>>>>>> gerhard
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>> > >>>>>>>>
>> > >>>>>>>>> So, you mean just write a bean with all the boilerplate code
>> in
>> > it?
>> > >>>>>>>>>
>> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>> hi pete,
>> > >>>>>>>>>>
>> > >>>>>>>>>> instead of the interface you can just implement a bean which
>> > does
>> > >> the
>> > >>>>>>>>> same.
>> > >>>>>>>>>>
>> > >>>>>>>>>> regards,
>> > >>>>>>>>>> gerhard
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> What CDI mechanism would you use instead?
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> +0
>> > >>>>>>>>>>>> no -1 because there are use-cases for it.
>> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> regards,
>> > >>>>>>>>>>>> gerhard
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>> hi john,
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> regards,
>> > >>>>>>>>>>>>> gerhard
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> Hi All
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>> > >>>>>>>> added 113 as a
>> > >>>>>>>>>>>>>> child
>> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>> > >>>>>>>> (so please let
>> > >>>>>>>>> me
>> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
>> > >>>>>>>> child). ServiceHandler
>> > >>>>>>>>> is
>> > >>>>>>>>>>> a
>> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
>> > >>>>>>>> interceptor that
>> > >>>>>>>>> manages
>> > >>>>>>>>>>>>>> generic calls against an injected interface. The API
>> > >>>>>>>> is as follows:
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>> > >>>>>>>> on an annotation that
>> > >>>>>>>>>>> would
>> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
>> > >>>>>>>> interceptor would be
>> > >>>>>>>>>>> invoked
>> > >>>>>>>>>>>>>> for calls against this interface.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> It's then up to the application
>> > >>>>>>>> developer/framework author to define
>> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
>> > >>>>>>>> interceptor itself
>> > >>>>>>>>> that
>> > >>>>>>>>>>>>>> will
>> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>> > >>>>>>>> to provide the
>> > >>>>>>>>>>> API of
>> > >>>>>>>>>>>>>> the type and then the infrastructure required to make
>> > >>>>>>>> the interceptor
>> > >>>>>>>>>>> be
>> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>
>> > >>
>> >
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Regards,
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> john
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>
>> > >>
>> > >>
>> >
>> >
>>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi george,
thx for the link.
i'm not sure if it is the latest state of your discussion and/or draft (at
least it's quite old already).
regards,
gerhard
2012/3/7 George Gastaldi <ge...@gmail.com>
> Hi !
>
> +1 to #1. I also agree that the term "Service Handler" might not be so
> appropriate, so it should be discussed as well.
> Here is the latest pull request with some comments from Pete yet to be
> reviewed: https://github.com/jboss/cdi/pull/28
>
> 2012/3/7 Pete Muir <pm...@redhat.com>
>
> > Agreed :-)
> >
> > George is working on it for CDI 1.1. George, can you share your proposal
> > so far?
> >
> > On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> >
> > > hi pete,
> > >
> > > independent of my opinion about the feature (which is still +0):
> > > if it should be part of cdi 1.1, we have the following options imo:
> > >
> > > 1) the approach (including the name/s) we agree on will be used also
> for
> > > cdi 1.1 (the only difference is the package)
> > > 2) the eg has a different opinion about it ->
> > > 2a) the rest of the eg joins this discussion
> > > 2b) we wait for the final version and just allow the same with cdi 1.0
> > > 3) if the eg doesn't agree on the idea, it should be re-visited for
> > > deltaspike (if we really need it)
> > > 4) we agree on it independent of the result in cdi 1.1
> > >
> > > 1-3 is ok for me but -1 for #4
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2012/3/7 Pete Muir <pm...@redhat.com>
> > >
> > >> I'm not sure what you mean by a "super interceptor", but if you mean
> it
> > as
> > >> in "super man" (something better than an interceptor), then I would
> > >> disagree, it's actually a specialised form of interceptor.
> > >>
> > >> The best use case I know of is the one John mentions - creating type
> > safe
> > >> references to queries:
> > >>
> > >> @QueryService
> > >> interface UserQuery {
> > >>
> > >> @Query("select u from User u")
> > >> public List<User> getAllUsers();
> > >>
> > >> @Query("select u from User u order by u.name")
> > >> public List<User> getAllUsersSortedByName();
> > >>
> > >> }
> > >>
> > >> Now, it may be the case that there aren't any other use cases for
> > service
> > >> handlers, in which case we should perhaps just offer this particular
> > >> service handler - references to type safe queries - as I think this is
> > an
> > >> extremely powerful idea.
> > >>
> > >> Note, that at the moment service handlers are scheduled for CDI 1.1.
> > >>
> > >>
> > >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> > >>
> > >>> Somewhat. I wouldn't really think of them as overrides, they, to me,
> > >> seem more like items to do in addition to whatever the original impl
> > does.
> > >>>
> > >>> ServiceHandlers to me seem more like super interceptors.
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> @jason
> > >>>>
> > >>>> I think the concepts are very dissimilar. servicehandlers create
> the
> > >>>> implementation. delegates are more like overrides and need to know
> > >> about
> > >>>> the method signature.
> > >>>>
> > >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <
> lightguard.jp@gmail.com
> > >>> wrote:
> > >>>>
> > >>>>> I think the idea of ServiceHandlers are good, but, could we not do
> > this
> > >>>>> with delegates?
> > >>>>>
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com>
> > >> wrote:
> > >>>>>
> > >>>>>> @mark
> > >>>>>>
> > >>>>>> I don't think it's a hard requirement for it to be on an
> interface.
> > >>>>>>
> > >>>>>> One of the best use-cases we built at my job is using it for
> calling
> > >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able
> to
> > >>>>> create
> > >>>>>> a fairly clean wrapper API, generic enough for binding in/out
> > >> parameters.
> > >>>>>>
> > >>>>>> JOhn
> > >>>>>>
> > >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <struberg@yahoo.de
> >
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> actually I don't really see a real benefit. I just don't yet grok
> > the
> > >>>>> use
> > >>>>>>> case for real world projects.
> > >>>>>>>
> > >>>>>>> Why would one intercept an Interface and delegate the calls to a
> > >> method
> > >>>>>>> handler?
> > >>>>>>> This could be neat for mocking, but there are better frameworks
> for
> > >>>>> that.
> > >>>>>>>
> > >>>>>>> thus
> > >>>>>>>
> > >>>>>>> -0.2
> > >>>>>>>
> > >>>>>>> LieGrue,
> > >>>>>>> strub
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> > >>>>>>>> To: deltaspike-dev@incubator.apache.org
> > >>>>>>>> Cc:
> > >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> > >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> > >>>>> ServiceHandler
> > >>>>>>>>
> > >>>>>>>> if you have a lot of shared code, you can extract it in 1-n
> > >> method/s or
> > >>>>>>> an
> > >>>>>>>> abstract class which is still easier than a new concept.
> > >>>>>>>> at least i haven't seen an use-case which really needed it. that
> > was
> > >>>>> the
> > >>>>>>>> reason for a +0 (which still means that i'm ok with adding it).
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>> gerhard
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > >>>>>>>>
> > >>>>>>>>> So, you mean just write a bean with all the boilerplate code in
> > it?
> > >>>>>>>>>
> > >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> > >>>>>>>>>
> > >>>>>>>>>> hi pete,
> > >>>>>>>>>>
> > >>>>>>>>>> instead of the interface you can just implement a bean which
> > does
> > >> the
> > >>>>>>>>> same.
> > >>>>>>>>>>
> > >>>>>>>>>> regards,
> > >>>>>>>>>> gerhard
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> > >>>>>>>>>>
> > >>>>>>>>>>> What CDI mechanism would you use instead?
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> +0
> > >>>>>>>>>>>> no -1 because there are use-cases for it.
> > >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> regards,
> > >>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> hi john,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Hi All
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
> > >>>>>>>> added 113 as a
> > >>>>>>>>>>>>>> child
> > >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> > >>>>>>>> (so please let
> > >>>>>>>>> me
> > >>>>>>>>>>>>>> know if you think it's not appropriate as a
> > >>>>>>>> child). ServiceHandler
> > >>>>>>>>> is
> > >>>>>>>>>>> a
> > >>>>>>>>>>>>>> feature in Solder that allows you to define an
> > >>>>>>>> interceptor that
> > >>>>>>>>> manages
> > >>>>>>>>>>>>>> generic calls against an injected interface. The API
> > >>>>>>>> is as follows:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> > >>>>>>>> on an annotation that
> > >>>>>>>>>>> would
> > >>>>>>>>>>>>>> be placed on the interface. Indicates what
> > >>>>>>>> interceptor would be
> > >>>>>>>>>>> invoked
> > >>>>>>>>>>>>>> for calls against this interface.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> It's then up to the application
> > >>>>>>>> developer/framework author to define
> > >>>>>>>>>>>>>> annotations that go on methods, as well as the
> > >>>>>>>> interceptor itself
> > >>>>>>>>> that
> > >>>>>>>>>>>>>> will
> > >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
> > >>>>>>>> to provide the
> > >>>>>>>>>>> API of
> > >>>>>>>>>>>>>> the type and then the infrastructure required to make
> > >>>>>>>> the interceptor
> > >>>>>>>>>>> be
> > >>>>>>>>>>>>>> called. Existing documentation of the feature:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>
> >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> john
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>
> > >>
> >
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by George Gastaldi <ge...@gmail.com>.
Hi !
+1 to #1. I also agree that the term "Service Handler" might not be so
appropriate, so it should be discussed as well.
Here is the latest pull request with some comments from Pete yet to be
reviewed: https://github.com/jboss/cdi/pull/28
2012/3/7 Pete Muir <pm...@redhat.com>
> Agreed :-)
>
> George is working on it for CDI 1.1. George, can you share your proposal
> so far?
>
> On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
>
> > hi pete,
> >
> > independent of my opinion about the feature (which is still +0):
> > if it should be part of cdi 1.1, we have the following options imo:
> >
> > 1) the approach (including the name/s) we agree on will be used also for
> > cdi 1.1 (the only difference is the package)
> > 2) the eg has a different opinion about it ->
> > 2a) the rest of the eg joins this discussion
> > 2b) we wait for the final version and just allow the same with cdi 1.0
> > 3) if the eg doesn't agree on the idea, it should be re-visited for
> > deltaspike (if we really need it)
> > 4) we agree on it independent of the result in cdi 1.1
> >
> > 1-3 is ok for me but -1 for #4
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/3/7 Pete Muir <pm...@redhat.com>
> >
> >> I'm not sure what you mean by a "super interceptor", but if you mean it
> as
> >> in "super man" (something better than an interceptor), then I would
> >> disagree, it's actually a specialised form of interceptor.
> >>
> >> The best use case I know of is the one John mentions - creating type
> safe
> >> references to queries:
> >>
> >> @QueryService
> >> interface UserQuery {
> >>
> >> @Query("select u from User u")
> >> public List<User> getAllUsers();
> >>
> >> @Query("select u from User u order by u.name")
> >> public List<User> getAllUsersSortedByName();
> >>
> >> }
> >>
> >> Now, it may be the case that there aren't any other use cases for
> service
> >> handlers, in which case we should perhaps just offer this particular
> >> service handler - references to type safe queries - as I think this is
> an
> >> extremely powerful idea.
> >>
> >> Note, that at the moment service handlers are scheduled for CDI 1.1.
> >>
> >>
> >> On 7 Mar 2012, at 02:35, Jason Porter wrote:
> >>
> >>> Somewhat. I wouldn't really think of them as overrides, they, to me,
> >> seem more like items to do in addition to whatever the original impl
> does.
> >>>
> >>> ServiceHandlers to me seem more like super interceptors.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
> >> wrote:
> >>>
> >>>> @jason
> >>>>
> >>>> I think the concepts are very dissimilar. servicehandlers create the
> >>>> implementation. delegates are more like overrides and need to know
> >> about
> >>>> the method signature.
> >>>>
> >>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <lightguard.jp@gmail.com
> >>> wrote:
> >>>>
> >>>>> I think the idea of ServiceHandlers are good, but, could we not do
> this
> >>>>> with delegates?
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> @mark
> >>>>>>
> >>>>>> I don't think it's a hard requirement for it to be on an interface.
> >>>>>>
> >>>>>> One of the best use-cases we built at my job is using it for calling
> >>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
> >>>>> create
> >>>>>> a fairly clean wrapper API, generic enough for binding in/out
> >> parameters.
> >>>>>>
> >>>>>> JOhn
> >>>>>>
> >>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
> >>>>> wrote:
> >>>>>>
> >>>>>>> actually I don't really see a real benefit. I just don't yet grok
> the
> >>>>> use
> >>>>>>> case for real world projects.
> >>>>>>>
> >>>>>>> Why would one intercept an Interface and delegate the calls to a
> >> method
> >>>>>>> handler?
> >>>>>>> This could be neat for mocking, but there are better frameworks for
> >>>>> that.
> >>>>>>>
> >>>>>>> thus
> >>>>>>>
> >>>>>>> -0.2
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
> >>>>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>>> Cc:
> >>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>> ServiceHandler
> >>>>>>>>
> >>>>>>>> if you have a lot of shared code, you can extract it in 1-n
> >> method/s or
> >>>>>>> an
> >>>>>>>> abstract class which is still easier than a new concept.
> >>>>>>>> at least i haven't seen an use-case which really needed it. that
> was
> >>>>> the
> >>>>>>>> reason for a +0 (which still means that i'm ok with adding it).
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>> gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>
> >>>>>>>>> So, you mean just write a bean with all the boilerplate code in
> it?
> >>>>>>>>>
> >>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> >>>>>>>>>
> >>>>>>>>>> hi pete,
> >>>>>>>>>>
> >>>>>>>>>> instead of the interface you can just implement a bean which
> does
> >> the
> >>>>>>>>> same.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>> gerhard
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>>>
> >>>>>>>>>>> What CDI mechanism would you use instead?
> >>>>>>>>>>>
> >>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> +0
> >>>>>>>>>>>> no -1 because there are use-cases for it.
> >>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
> >>>>>>>>>>>>
> >>>>>>>>>>>> regards,
> >>>>>>>>>>>> gerhard
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> regards,
> >>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi All
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
> >>>>>>>> added 113 as a
> >>>>>>>>>>>>>> child
> >>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> >>>>>>>> (so please let
> >>>>>>>>> me
> >>>>>>>>>>>>>> know if you think it's not appropriate as a
> >>>>>>>> child). ServiceHandler
> >>>>>>>>> is
> >>>>>>>>>>> a
> >>>>>>>>>>>>>> feature in Solder that allows you to define an
> >>>>>>>> interceptor that
> >>>>>>>>> manages
> >>>>>>>>>>>>>> generic calls against an injected interface. The API
> >>>>>>>> is as follows:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> >>>>>>>> on an annotation that
> >>>>>>>>>>> would
> >>>>>>>>>>>>>> be placed on the interface. Indicates what
> >>>>>>>> interceptor would be
> >>>>>>>>>>> invoked
> >>>>>>>>>>>>>> for calls against this interface.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's then up to the application
> >>>>>>>> developer/framework author to define
> >>>>>>>>>>>>>> annotations that go on methods, as well as the
> >>>>>>>> interceptor itself
> >>>>>>>>> that
> >>>>>>>>>>>>>> will
> >>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
> >>>>>>>> to provide the
> >>>>>>>>>>> API of
> >>>>>>>>>>>>>> the type and then the infrastructure required to make
> >>>>>>>> the interceptor
> >>>>>>>>>>> be
> >>>>>>>>>>>>>> called. Existing documentation of the feature:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> john
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
Agreed :-)
George is working on it for CDI 1.1. George, can you share your proposal so far?
On 7 Mar 2012, at 17:05, Gerhard Petracek wrote:
> hi pete,
>
> independent of my opinion about the feature (which is still +0):
> if it should be part of cdi 1.1, we have the following options imo:
>
> 1) the approach (including the name/s) we agree on will be used also for
> cdi 1.1 (the only difference is the package)
> 2) the eg has a different opinion about it ->
> 2a) the rest of the eg joins this discussion
> 2b) we wait for the final version and just allow the same with cdi 1.0
> 3) if the eg doesn't agree on the idea, it should be re-visited for
> deltaspike (if we really need it)
> 4) we agree on it independent of the result in cdi 1.1
>
> 1-3 is ok for me but -1 for #4
>
> regards,
> gerhard
>
>
>
> 2012/3/7 Pete Muir <pm...@redhat.com>
>
>> I'm not sure what you mean by a "super interceptor", but if you mean it as
>> in "super man" (something better than an interceptor), then I would
>> disagree, it's actually a specialised form of interceptor.
>>
>> The best use case I know of is the one John mentions - creating type safe
>> references to queries:
>>
>> @QueryService
>> interface UserQuery {
>>
>> @Query("select u from User u")
>> public List<User> getAllUsers();
>>
>> @Query("select u from User u order by u.name")
>> public List<User> getAllUsersSortedByName();
>>
>> }
>>
>> Now, it may be the case that there aren't any other use cases for service
>> handlers, in which case we should perhaps just offer this particular
>> service handler - references to type safe queries - as I think this is an
>> extremely powerful idea.
>>
>> Note, that at the moment service handlers are scheduled for CDI 1.1.
>>
>>
>> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>>
>>> Somewhat. I wouldn't really think of them as overrides, they, to me,
>> seem more like items to do in addition to whatever the original impl does.
>>>
>>> ServiceHandlers to me seem more like super interceptors.
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
>> wrote:
>>>
>>>> @jason
>>>>
>>>> I think the concepts are very dissimilar. servicehandlers create the
>>>> implementation. delegates are more like overrides and need to know
>> about
>>>> the method signature.
>>>>
>>>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <lightguard.jp@gmail.com
>>> wrote:
>>>>
>>>>> I think the idea of ServiceHandlers are good, but, could we not do this
>>>>> with delegates?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com>
>> wrote:
>>>>>
>>>>>> @mark
>>>>>>
>>>>>> I don't think it's a hard requirement for it to be on an interface.
>>>>>>
>>>>>> One of the best use-cases we built at my job is using it for calling
>>>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
>>>>> create
>>>>>> a fairly clean wrapper API, generic enough for binding in/out
>> parameters.
>>>>>>
>>>>>> JOhn
>>>>>>
>>>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
>>>>> wrote:
>>>>>>
>>>>>>> actually I don't really see a real benefit. I just don't yet grok the
>>>>> use
>>>>>>> case for real world projects.
>>>>>>>
>>>>>>> Why would one intercept an Interface and delegate the calls to a
>> method
>>>>>>> handler?
>>>>>>> This could be neat for mocking, but there are better frameworks for
>>>>> that.
>>>>>>>
>>>>>>> thus
>>>>>>>
>>>>>>> -0.2
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: Gerhard Petracek <ge...@gmail.com>
>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>> Cc:
>>>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>> ServiceHandler
>>>>>>>>
>>>>>>>> if you have a lot of shared code, you can extract it in 1-n
>> method/s or
>>>>>>> an
>>>>>>>> abstract class which is still easier than a new concept.
>>>>>>>> at least i haven't seen an use-case which really needed it. that was
>>>>> the
>>>>>>>> reason for a +0 (which still means that i'm ok with adding it).
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>
>>>>>>>>> So, you mean just write a bean with all the boilerplate code in it?
>>>>>>>>>
>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>>>>>>>
>>>>>>>>>> hi pete,
>>>>>>>>>>
>>>>>>>>>> instead of the interface you can just implement a bean which does
>> the
>>>>>>>>> same.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>
>>>>>>>>>>> What CDI mechanism would you use instead?
>>>>>>>>>>>
>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +0
>>>>>>>>>>>> no -1 because there are use-cases for it.
>>>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>
>>>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>>>>>>> added 113 as a
>>>>>>>>>>>>>> child
>>>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>>>>>>> (so please let
>>>>>>>>> me
>>>>>>>>>>>>>> know if you think it's not appropriate as a
>>>>>>>> child). ServiceHandler
>>>>>>>>> is
>>>>>>>>>>> a
>>>>>>>>>>>>>> feature in Solder that allows you to define an
>>>>>>>> interceptor that
>>>>>>>>> manages
>>>>>>>>>>>>>> generic calls against an injected interface. The API
>>>>>>>> is as follows:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>>>>>>> on an annotation that
>>>>>>>>>>> would
>>>>>>>>>>>>>> be placed on the interface. Indicates what
>>>>>>>> interceptor would be
>>>>>>>>>>> invoked
>>>>>>>>>>>>>> for calls against this interface.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's then up to the application
>>>>>>>> developer/framework author to define
>>>>>>>>>>>>>> annotations that go on methods, as well as the
>>>>>>>> interceptor itself
>>>>>>>>> that
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>>>>>>> to provide the
>>>>>>>>>>> API of
>>>>>>>>>>>>>> the type and then the infrastructure required to make
>>>>>>>> the interceptor
>>>>>>>>>>> be
>>>>>>>>>>>>>> called. Existing documentation of the feature:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi pete,
independent of my opinion about the feature (which is still +0):
if it should be part of cdi 1.1, we have the following options imo:
1) the approach (including the name/s) we agree on will be used also for
cdi 1.1 (the only difference is the package)
2) the eg has a different opinion about it ->
2a) the rest of the eg joins this discussion
2b) we wait for the final version and just allow the same with cdi 1.0
3) if the eg doesn't agree on the idea, it should be re-visited for
deltaspike (if we really need it)
4) we agree on it independent of the result in cdi 1.1
1-3 is ok for me but -1 for #4
regards,
gerhard
2012/3/7 Pete Muir <pm...@redhat.com>
> I'm not sure what you mean by a "super interceptor", but if you mean it as
> in "super man" (something better than an interceptor), then I would
> disagree, it's actually a specialised form of interceptor.
>
> The best use case I know of is the one John mentions - creating type safe
> references to queries:
>
> @QueryService
> interface UserQuery {
>
> @Query("select u from User u")
> public List<User> getAllUsers();
>
> @Query("select u from User u order by u.name")
> public List<User> getAllUsersSortedByName();
>
> }
>
> Now, it may be the case that there aren't any other use cases for service
> handlers, in which case we should perhaps just offer this particular
> service handler - references to type safe queries - as I think this is an
> extremely powerful idea.
>
> Note, that at the moment service handlers are scheduled for CDI 1.1.
>
>
> On 7 Mar 2012, at 02:35, Jason Porter wrote:
>
> > Somewhat. I wouldn't really think of them as overrides, they, to me,
> seem more like items to do in addition to whatever the original impl does.
> >
> > ServiceHandlers to me seem more like super interceptors.
> >
> > Sent from my iPhone
> >
> > On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com>
> wrote:
> >
> >> @jason
> >>
> >> I think the concepts are very dissimilar. servicehandlers create the
> >> implementation. delegates are more like overrides and need to know
> about
> >> the method signature.
> >>
> >> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <lightguard.jp@gmail.com
> >wrote:
> >>
> >>> I think the idea of ServiceHandlers are good, but, could we not do this
> >>> with delegates?
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com>
> wrote:
> >>>
> >>>> @mark
> >>>>
> >>>> I don't think it's a hard requirement for it to be on an interface.
> >>>>
> >>>> One of the best use-cases we built at my job is using it for calling
> >>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
> >>> create
> >>>> a fairly clean wrapper API, generic enough for binding in/out
> parameters.
> >>>>
> >>>> JOhn
> >>>>
> >>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
> >>> wrote:
> >>>>
> >>>>> actually I don't really see a real benefit. I just don't yet grok the
> >>> use
> >>>>> case for real world projects.
> >>>>>
> >>>>> Why would one intercept an Interface and delegate the calls to a
> method
> >>>>> handler?
> >>>>> This could be neat for mocking, but there are better frameworks for
> >>> that.
> >>>>>
> >>>>> thus
> >>>>>
> >>>>> -0.2
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: Gerhard Petracek <ge...@gmail.com>
> >>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>> Cc:
> >>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>> ServiceHandler
> >>>>>>
> >>>>>> if you have a lot of shared code, you can extract it in 1-n
> method/s or
> >>>>> an
> >>>>>> abstract class which is still easier than a new concept.
> >>>>>> at least i haven't seen an use-case which really needed it. that was
> >>> the
> >>>>>> reason for a +0 (which still means that i'm ok with adding it).
> >>>>>>
> >>>>>> regards,
> >>>>>> gerhard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>
> >>>>>>> So, you mean just write a bean with all the boilerplate code in it?
> >>>>>>>
> >>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> >>>>>>>
> >>>>>>>> hi pete,
> >>>>>>>>
> >>>>>>>> instead of the interface you can just implement a bean which does
> the
> >>>>>>> same.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>> gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>>>>
> >>>>>>>>> What CDI mechanism would you use instead?
> >>>>>>>>>
> >>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >>>>>>>>>
> >>>>>>>>>> +0
> >>>>>>>>>> no -1 because there are use-cases for it.
> >>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>> gerhard
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>>> hi john,
> >>>>>>>>>>>
> >>>>>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>>>>
> >>>>>>>>>>> regards,
> >>>>>>>>>>> gerhard
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>> Hi All
> >>>>>>>>>>>>
> >>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
> >>>>>> added 113 as a
> >>>>>>>>>>>> child
> >>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> >>>>>> (so please let
> >>>>>>> me
> >>>>>>>>>>>> know if you think it's not appropriate as a
> >>>>>> child). ServiceHandler
> >>>>>>> is
> >>>>>>>>> a
> >>>>>>>>>>>> feature in Solder that allows you to define an
> >>>>>> interceptor that
> >>>>>>> manages
> >>>>>>>>>>>> generic calls against an injected interface. The API
> >>>>>> is as follows:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> >>>>>> on an annotation that
> >>>>>>>>> would
> >>>>>>>>>>>> be placed on the interface. Indicates what
> >>>>>> interceptor would be
> >>>>>>>>> invoked
> >>>>>>>>>>>> for calls against this interface.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's then up to the application
> >>>>>> developer/framework author to define
> >>>>>>>>>>>> annotations that go on methods, as well as the
> >>>>>> interceptor itself
> >>>>>>> that
> >>>>>>>>>>>> will
> >>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
> >>>>>> to provide the
> >>>>>>>>> API of
> >>>>>>>>>>>> the type and then the infrastructure required to make
> >>>>>> the interceptor
> >>>>>>>>> be
> >>>>>>>>>>>> called. Existing documentation of the feature:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>>
> >>>>>>>>>>>> john
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
I'm not sure what you mean by a "super interceptor", but if you mean it as in "super man" (something better than an interceptor), then I would disagree, it's actually a specialised form of interceptor.
The best use case I know of is the one John mentions - creating type safe references to queries:
@QueryService
interface UserQuery {
@Query("select u from User u")
public List<User> getAllUsers();
@Query("select u from User u order by u.name")
public List<User> getAllUsersSortedByName();
}
Now, it may be the case that there aren't any other use cases for service handlers, in which case we should perhaps just offer this particular service handler - references to type safe queries - as I think this is an extremely powerful idea.
Note, that at the moment service handlers are scheduled for CDI 1.1.
On 7 Mar 2012, at 02:35, Jason Porter wrote:
> Somewhat. I wouldn't really think of them as overrides, they, to me, seem more like items to do in addition to whatever the original impl does.
>
> ServiceHandlers to me seem more like super interceptors.
>
> Sent from my iPhone
>
> On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com> wrote:
>
>> @jason
>>
>> I think the concepts are very dissimilar. servicehandlers create the
>> implementation. delegates are more like overrides and need to know about
>> the method signature.
>>
>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <li...@gmail.com>wrote:
>>
>>> I think the idea of ServiceHandlers are good, but, could we not do this
>>> with delegates?
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com> wrote:
>>>
>>>> @mark
>>>>
>>>> I don't think it's a hard requirement for it to be on an interface.
>>>>
>>>> One of the best use-cases we built at my job is using it for calling
>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
>>> create
>>>> a fairly clean wrapper API, generic enough for binding in/out parameters.
>>>>
>>>> JOhn
>>>>
>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
>>> wrote:
>>>>
>>>>> actually I don't really see a real benefit. I just don't yet grok the
>>> use
>>>>> case for real world projects.
>>>>>
>>>>> Why would one intercept an Interface and delegate the calls to a method
>>>>> handler?
>>>>> This could be neat for mocking, but there are better frameworks for
>>> that.
>>>>>
>>>>> thus
>>>>>
>>>>> -0.2
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Gerhard Petracek <ge...@gmail.com>
>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>> Cc:
>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>> ServiceHandler
>>>>>>
>>>>>> if you have a lot of shared code, you can extract it in 1-n method/s or
>>>>> an
>>>>>> abstract class which is still easier than a new concept.
>>>>>> at least i haven't seen an use-case which really needed it. that was
>>> the
>>>>>> reason for a +0 (which still means that i'm ok with adding it).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>
>>>>>>> So, you mean just write a bean with all the boilerplate code in it?
>>>>>>>
>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>>>>>
>>>>>>>> hi pete,
>>>>>>>>
>>>>>>>> instead of the interface you can just implement a bean which does the
>>>>>>> same.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>
>>>>>>>>> What CDI mechanism would you use instead?
>>>>>>>>>
>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>>>>>>>>
>>>>>>>>>> +0
>>>>>>>>>> no -1 because there are use-cases for it.
>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> hi john,
>>>>>>>>>>>
>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> Hi All
>>>>>>>>>>>>
>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>>>>> added 113 as a
>>>>>>>>>>>> child
>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>>>>> (so please let
>>>>>>> me
>>>>>>>>>>>> know if you think it's not appropriate as a
>>>>>> child). ServiceHandler
>>>>>>> is
>>>>>>>>> a
>>>>>>>>>>>> feature in Solder that allows you to define an
>>>>>> interceptor that
>>>>>>> manages
>>>>>>>>>>>> generic calls against an injected interface. The API
>>>>>> is as follows:
>>>>>>>>>>>>
>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>>>>> on an annotation that
>>>>>>>>> would
>>>>>>>>>>>> be placed on the interface. Indicates what
>>>>>> interceptor would be
>>>>>>>>> invoked
>>>>>>>>>>>> for calls against this interface.
>>>>>>>>>>>>
>>>>>>>>>>>> It's then up to the application
>>>>>> developer/framework author to define
>>>>>>>>>>>> annotations that go on methods, as well as the
>>>>>> interceptor itself
>>>>>>> that
>>>>>>>>>>>> will
>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>>>>> to provide the
>>>>>>>>> API of
>>>>>>>>>>>> the type and then the infrastructure required to make
>>>>>> the interceptor
>>>>>>>>> be
>>>>>>>>>>>> called. Existing documentation of the feature:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> john
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Marius Bogoevici <ma...@gmail.com>.
On 12-03-06 9:35 PM, Jason Porter wrote:
> Somewhat. I wouldn't really think of them as overrides, they, to me, seem more like items to do in addition to whatever the original impl does.
>
> ServiceHandlers to me seem more like super interceptors.
I'd rather think of mixins.
>
> Sent from my iPhone
>
> On Mar 6, 2012, at 19:23, "John D. Ament"<jo...@gmail.com> wrote:
>
>> @jason
>>
>> I think the concepts are very dissimilar. servicehandlers create the
>> implementation. delegates are more like overrides and need to know about
>> the method signature.
>>
>> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter<li...@gmail.com>wrote:
>>
>>> I think the idea of ServiceHandlers are good, but, could we not do this
>>> with delegates?
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 6, 2012, at 19:05, "John D. Ament"<jo...@gmail.com> wrote:
>>>
>>>> @mark
>>>>
>>>> I don't think it's a hard requirement for it to be on an interface.
>>>>
>>>> One of the best use-cases we built at my job is using it for calling
>>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
>>> create
>>>> a fairly clean wrapper API, generic enough for binding in/out parameters.
>>>>
>>>> JOhn
>>>>
>>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg<st...@yahoo.de>
>>> wrote:
>>>>> actually I don't really see a real benefit. I just don't yet grok the
>>> use
>>>>> case for real world projects.
>>>>>
>>>>> Why would one intercept an Interface and delegate the calls to a method
>>>>> handler?
>>>>> This could be neat for mocking, but there are better frameworks for
>>> that.
>>>>> thus
>>>>>
>>>>> -0.2
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Gerhard Petracek<ge...@gmail.com>
>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>> Cc:
>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>> ServiceHandler
>>>>>> if you have a lot of shared code, you can extract it in 1-n method/s or
>>>>> an
>>>>>> abstract class which is still easier than a new concept.
>>>>>> at least i haven't seen an use-case which really needed it. that was
>>> the
>>>>>> reason for a +0 (which still means that i'm ok with adding it).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/3/6 Pete Muir<pm...@redhat.com>
>>>>>>
>>>>>>> So, you mean just write a bean with all the boilerplate code in it?
>>>>>>>
>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>>>>>
>>>>>>>> hi pete,
>>>>>>>>
>>>>>>>> instead of the interface you can just implement a bean which does the
>>>>>>> same.
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/6 Pete Muir<pm...@redhat.com>
>>>>>>>>
>>>>>>>>> What CDI mechanism would you use instead?
>>>>>>>>>
>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>>>>>>>>
>>>>>>>>>> +0
>>>>>>>>>> no -1 because there are use-cases for it.
>>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/4 Gerhard Petracek<ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> hi john,
>>>>>>>>>>>
>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/4 John D. Ament<jo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> Hi All
>>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>>>>> added 113 as a
>>>>>>>>>>>> child
>>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>>>>> (so please let
>>>>>>> me
>>>>>>>>>>>> know if you think it's not appropriate as a
>>>>>> child). ServiceHandler
>>>>>>> is
>>>>>>>>> a
>>>>>>>>>>>> feature in Solder that allows you to define an
>>>>>> interceptor that
>>>>>>> manages
>>>>>>>>>>>> generic calls against an injected interface. The API
>>>>>> is as follows:
>>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>>>>> on an annotation that
>>>>>>>>> would
>>>>>>>>>>>> be placed on the interface. Indicates what
>>>>>> interceptor would be
>>>>>>>>> invoked
>>>>>>>>>>>> for calls against this interface.
>>>>>>>>>>>>
>>>>>>>>>>>> It's then up to the application
>>>>>> developer/framework author to define
>>>>>>>>>>>> annotations that go on methods, as well as the
>>>>>> interceptor itself
>>>>>>> that
>>>>>>>>>>>> will
>>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>>>>> to provide the
>>>>>>>>> API of
>>>>>>>>>>>> the type and then the infrastructure required to make
>>>>>> the interceptor
>>>>>>>>> be
>>>>>>>>>>>> called. Existing documentation of the feature:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> john
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Jason Porter <li...@gmail.com>.
Somewhat. I wouldn't really think of them as overrides, they, to me, seem more like items to do in addition to whatever the original impl does.
ServiceHandlers to me seem more like super interceptors.
Sent from my iPhone
On Mar 6, 2012, at 19:23, "John D. Ament" <jo...@gmail.com> wrote:
> @jason
>
> I think the concepts are very dissimilar. servicehandlers create the
> implementation. delegates are more like overrides and need to know about
> the method signature.
>
> On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <li...@gmail.com>wrote:
>
>> I think the idea of ServiceHandlers are good, but, could we not do this
>> with delegates?
>>
>> Sent from my iPhone
>>
>> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com> wrote:
>>
>>> @mark
>>>
>>> I don't think it's a hard requirement for it to be on an interface.
>>>
>>> One of the best use-cases we built at my job is using it for calling
>>> PL/SQL. The JDBC bindings do work, but not pretty. we were able to
>> create
>>> a fairly clean wrapper API, generic enough for binding in/out parameters.
>>>
>>> JOhn
>>>
>>> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
>> wrote:
>>>
>>>> actually I don't really see a real benefit. I just don't yet grok the
>> use
>>>> case for real world projects.
>>>>
>>>> Why would one intercept an Interface and delegate the calls to a method
>>>> handler?
>>>> This could be neat for mocking, but there are better frameworks for
>> that.
>>>>
>>>> thus
>>>>
>>>> -0.2
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Gerhard Petracek <ge...@gmail.com>
>>>>> To: deltaspike-dev@incubator.apache.org
>>>>> Cc:
>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>> ServiceHandler
>>>>>
>>>>> if you have a lot of shared code, you can extract it in 1-n method/s or
>>>> an
>>>>> abstract class which is still easier than a new concept.
>>>>> at least i haven't seen an use-case which really needed it. that was
>> the
>>>>> reason for a +0 (which still means that i'm ok with adding it).
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>
>>>>>> So, you mean just write a bean with all the boilerplate code in it?
>>>>>>
>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>>>>
>>>>>>> hi pete,
>>>>>>>
>>>>>>> instead of the interface you can just implement a bean which does the
>>>>>> same.
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>
>>>>>>>> What CDI mechanism would you use instead?
>>>>>>>>
>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>>>>>>>
>>>>>>>>> +0
>>>>>>>>> no -1 because there are use-cases for it.
>>>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> gerhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>>>>>>>>
>>>>>>>>>> hi john,
>>>>>>>>>>
>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> Hi All
>>>>>>>>>>>
>>>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>>>> added 113 as a
>>>>>>>>>>> child
>>>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>>>> (so please let
>>>>>> me
>>>>>>>>>>> know if you think it's not appropriate as a
>>>>> child). ServiceHandler
>>>>>> is
>>>>>>>> a
>>>>>>>>>>> feature in Solder that allows you to define an
>>>>> interceptor that
>>>>>> manages
>>>>>>>>>>> generic calls against an injected interface. The API
>>>>> is as follows:
>>>>>>>>>>>
>>>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>>>> on an annotation that
>>>>>>>> would
>>>>>>>>>>> be placed on the interface. Indicates what
>>>>> interceptor would be
>>>>>>>> invoked
>>>>>>>>>>> for calls against this interface.
>>>>>>>>>>>
>>>>>>>>>>> It's then up to the application
>>>>> developer/framework author to define
>>>>>>>>>>> annotations that go on methods, as well as the
>>>>> interceptor itself
>>>>>> that
>>>>>>>>>>> will
>>>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>>>> to provide the
>>>>>>>> API of
>>>>>>>>>>> the type and then the infrastructure required to make
>>>>> the interceptor
>>>>>>>> be
>>>>>>>>>>> called. Existing documentation of the feature:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> john
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
@jason
I think the concepts are very dissimilar. servicehandlers create the
implementation. delegates are more like overrides and need to know about
the method signature.
On Tue, Mar 6, 2012 at 9:17 PM, Jason Porter <li...@gmail.com>wrote:
> I think the idea of ServiceHandlers are good, but, could we not do this
> with delegates?
>
> Sent from my iPhone
>
> On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com> wrote:
>
> > @mark
> >
> > I don't think it's a hard requirement for it to be on an interface.
> >
> > One of the best use-cases we built at my job is using it for calling
> > PL/SQL. The JDBC bindings do work, but not pretty. we were able to
> create
> > a fairly clean wrapper API, generic enough for binding in/out parameters.
> >
> > JOhn
> >
> > On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >> actually I don't really see a real benefit. I just don't yet grok the
> use
> >> case for real world projects.
> >>
> >> Why would one intercept an Interface and delegate the calls to a method
> >> handler?
> >> This could be neat for mocking, but there are better frameworks for
> that.
> >>
> >> thus
> >>
> >> -0.2
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: Gerhard Petracek <ge...@gmail.com>
> >>> To: deltaspike-dev@incubator.apache.org
> >>> Cc:
> >>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> ServiceHandler
> >>>
> >>> if you have a lot of shared code, you can extract it in 1-n method/s or
> >> an
> >>> abstract class which is still easier than a new concept.
> >>> at least i haven't seen an use-case which really needed it. that was
> the
> >>> reason for a +0 (which still means that i'm ok with adding it).
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>
> >>>> So, you mean just write a bean with all the boilerplate code in it?
> >>>>
> >>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> >>>>
> >>>>> hi pete,
> >>>>>
> >>>>> instead of the interface you can just implement a bean which does the
> >>>> same.
> >>>>>
> >>>>> regards,
> >>>>> gerhard
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
> >>>>>
> >>>>>> What CDI mechanism would you use instead?
> >>>>>>
> >>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >>>>>>
> >>>>>>> +0
> >>>>>>> no -1 because there are use-cases for it.
> >>>>>>> no +1 because i would use std. cdi mechanisms instead.
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> gerhard
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >>>>>>>
> >>>>>>>> hi john,
> >>>>>>>>
> >>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>> gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>>>>>>>
> >>>>>>>> Hi All
> >>>>>>>>>
> >>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
> >>> added 113 as a
> >>>>>>>>> child
> >>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> >>> (so please let
> >>>> me
> >>>>>>>>> know if you think it's not appropriate as a
> >>> child). ServiceHandler
> >>>> is
> >>>>>> a
> >>>>>>>>> feature in Solder that allows you to define an
> >>> interceptor that
> >>>> manages
> >>>>>>>>> generic calls against an injected interface. The API
> >>> is as follows:
> >>>>>>>>>
> >>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> >>> on an annotation that
> >>>>>> would
> >>>>>>>>> be placed on the interface. Indicates what
> >>> interceptor would be
> >>>>>> invoked
> >>>>>>>>> for calls against this interface.
> >>>>>>>>>
> >>>>>>>>> It's then up to the application
> >>> developer/framework author to define
> >>>>>>>>> annotations that go on methods, as well as the
> >>> interceptor itself
> >>>> that
> >>>>>>>>> will
> >>>>>>>>> be invoked. The feature for ServiceHandler would be
> >>> to provide the
> >>>>>> API of
> >>>>>>>>> the type and then the infrastructure required to make
> >>> the interceptor
> >>>>>> be
> >>>>>>>>> called. Existing documentation of the feature:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> john
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Jason Porter <li...@gmail.com>.
I think the idea of ServiceHandlers are good, but, could we not do this with delegates?
Sent from my iPhone
On Mar 6, 2012, at 19:05, "John D. Ament" <jo...@gmail.com> wrote:
> @mark
>
> I don't think it's a hard requirement for it to be on an interface.
>
> One of the best use-cases we built at my job is using it for calling
> PL/SQL. The JDBC bindings do work, but not pretty. we were able to create
> a fairly clean wrapper API, generic enough for binding in/out parameters.
>
> JOhn
>
> On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> actually I don't really see a real benefit. I just don't yet grok the use
>> case for real world projects.
>>
>> Why would one intercept an Interface and delegate the calls to a method
>> handler?
>> This could be neat for mocking, but there are better frameworks for that.
>>
>> thus
>>
>> -0.2
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Gerhard Petracek <ge...@gmail.com>
>>> To: deltaspike-dev@incubator.apache.org
>>> Cc:
>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>>>
>>> if you have a lot of shared code, you can extract it in 1-n method/s or
>> an
>>> abstract class which is still easier than a new concept.
>>> at least i haven't seen an use-case which really needed it. that was the
>>> reason for a +0 (which still means that i'm ok with adding it).
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>
>>>> So, you mean just write a bean with all the boilerplate code in it?
>>>>
>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>>>
>>>>> hi pete,
>>>>>
>>>>> instead of the interface you can just implement a bean which does the
>>>> same.
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>
>>>>>> What CDI mechanism would you use instead?
>>>>>>
>>>>>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>>>>>
>>>>>>> +0
>>>>>>> no -1 because there are use-cases for it.
>>>>>>> no +1 because i would use std. cdi mechanisms instead.
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>>>>>>
>>>>>>>> hi john,
>>>>>>>>
>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>>>>>>>
>>>>>>>> Hi All
>>>>>>>>>
>>>>>>>>> I wanted to bring up the subject of ServiceHandler. I
>>> added 113 as a
>>>>>>>>> child
>>>>>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
>>> (so please let
>>>> me
>>>>>>>>> know if you think it's not appropriate as a
>>> child). ServiceHandler
>>>> is
>>>>>> a
>>>>>>>>> feature in Solder that allows you to define an
>>> interceptor that
>>>> manages
>>>>>>>>> generic calls against an injected interface. The API
>>> is as follows:
>>>>>>>>>
>>>>>>>>> - @ServiceHandlerType(Class<?> clazz) - placed
>>> on an annotation that
>>>>>> would
>>>>>>>>> be placed on the interface. Indicates what
>>> interceptor would be
>>>>>> invoked
>>>>>>>>> for calls against this interface.
>>>>>>>>>
>>>>>>>>> It's then up to the application
>>> developer/framework author to define
>>>>>>>>> annotations that go on methods, as well as the
>>> interceptor itself
>>>> that
>>>>>>>>> will
>>>>>>>>> be invoked. The feature for ServiceHandler would be
>>> to provide the
>>>>>> API of
>>>>>>>>> the type and then the infrastructure required to make
>>> the interceptor
>>>>>> be
>>>>>>>>> called. Existing documentation of the feature:
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> john
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by "John D. Ament" <jo...@gmail.com>.
@mark
I don't think it's a hard requirement for it to be on an interface.
One of the best use-cases we built at my job is using it for calling
PL/SQL. The JDBC bindings do work, but not pretty. we were able to create
a fairly clean wrapper API, generic enough for binding in/out parameters.
JOhn
On Tue, Mar 6, 2012 at 12:58 PM, Mark Struberg <st...@yahoo.de> wrote:
> actually I don't really see a real benefit. I just don't yet grok the use
> case for real world projects.
>
> Why would one intercept an Interface and delegate the calls to a method
> handler?
> This could be neat for mocking, but there are better frameworks for that.
>
> thus
>
> -0.2
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Gerhard Petracek <ge...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Tuesday, March 6, 2012 5:15 PM
> > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
> >
> > if you have a lot of shared code, you can extract it in 1-n method/s or
> an
> > abstract class which is still easier than a new concept.
> > at least i haven't seen an use-case which really needed it. that was the
> > reason for a +0 (which still means that i'm ok with adding it).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/3/6 Pete Muir <pm...@redhat.com>
> >
> >> So, you mean just write a bean with all the boilerplate code in it?
> >>
> >> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> >>
> >> > hi pete,
> >> >
> >> > instead of the interface you can just implement a bean which does the
> >> same.
> >> >
> >> > regards,
> >> > gerhard
> >> >
> >> >
> >> >
> >> > 2012/3/6 Pete Muir <pm...@redhat.com>
> >> >
> >> >> What CDI mechanism would you use instead?
> >> >>
> >> >> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >> >>
> >> >>> +0
> >> >>> no -1 because there are use-cases for it.
> >> >>> no +1 because i would use std. cdi mechanisms instead.
> >> >>>
> >> >>> regards,
> >> >>> gerhard
> >> >>>
> >> >>>
> >> >>>
> >> >>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >> >>>
> >> >>>> hi john,
> >> >>>>
> >> >>>> the sub-task is perfectly fine.
> >> >>>>
> >> >>>> regards,
> >> >>>> gerhard
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >> >>>>
> >> >>>> Hi All
> >> >>>>>
> >> >>>>> I wanted to bring up the subject of ServiceHandler. I
> > added 113 as a
> >> >>>>> child
> >> >>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> > (so please let
> >> me
> >> >>>>> know if you think it's not appropriate as a
> > child). ServiceHandler
> >> is
> >> >> a
> >> >>>>> feature in Solder that allows you to define an
> > interceptor that
> >> manages
> >> >>>>> generic calls against an injected interface. The API
> > is as follows:
> >> >>>>>
> >> >>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> > on an annotation that
> >> >> would
> >> >>>>> be placed on the interface. Indicates what
> > interceptor would be
> >> >> invoked
> >> >>>>> for calls against this interface.
> >> >>>>>
> >> >>>>> It's then up to the application
> > developer/framework author to define
> >> >>>>> annotations that go on methods, as well as the
> > interceptor itself
> >> that
> >> >>>>> will
> >> >>>>> be invoked. The feature for ServiceHandler would be
> > to provide the
> >> >> API of
> >> >>>>> the type and then the infrastructure required to make
> > the interceptor
> >> >> be
> >> >>>>> called. Existing documentation of the feature:
> >> >>>>>
> >> >>>>>
> >> >>
> >>
> >
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >> >>>>>
> >> >>>>> Regards,
> >> >>>>>
> >> >>>>> john
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
> >
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Mark Struberg <st...@yahoo.de>.
actually I don't really see a real benefit. I just don't yet grok the use case for real world projects.
Why would one intercept an Interface and delegate the calls to a method handler?
This could be neat for mocking, but there are better frameworks for that.
thus
-0.2
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Tuesday, March 6, 2012 5:15 PM
> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
>
> if you have a lot of shared code, you can extract it in 1-n method/s or an
> abstract class which is still easier than a new concept.
> at least i haven't seen an use-case which really needed it. that was the
> reason for a +0 (which still means that i'm ok with adding it).
>
> regards,
> gerhard
>
>
>
> 2012/3/6 Pete Muir <pm...@redhat.com>
>
>> So, you mean just write a bean with all the boilerplate code in it?
>>
>> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>>
>> > hi pete,
>> >
>> > instead of the interface you can just implement a bean which does the
>> same.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2012/3/6 Pete Muir <pm...@redhat.com>
>> >
>> >> What CDI mechanism would you use instead?
>> >>
>> >> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>> >>
>> >>> +0
>> >>> no -1 because there are use-cases for it.
>> >>> no +1 because i would use std. cdi mechanisms instead.
>> >>>
>> >>> regards,
>> >>> gerhard
>> >>>
>> >>>
>> >>>
>> >>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>> >>>
>> >>>> hi john,
>> >>>>
>> >>>> the sub-task is perfectly fine.
>> >>>>
>> >>>> regards,
>> >>>> gerhard
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>> >>>>
>> >>>> Hi All
>> >>>>>
>> >>>>> I wanted to bring up the subject of ServiceHandler. I
> added 113 as a
>> >>>>> child
>> >>>>> of DELTASPIKE-2, looked appropriate but not 100% sure
> (so please let
>> me
>> >>>>> know if you think it's not appropriate as a
> child). ServiceHandler
>> is
>> >> a
>> >>>>> feature in Solder that allows you to define an
> interceptor that
>> manages
>> >>>>> generic calls against an injected interface. The API
> is as follows:
>> >>>>>
>> >>>>> - @ServiceHandlerType(Class<?> clazz) - placed
> on an annotation that
>> >> would
>> >>>>> be placed on the interface. Indicates what
> interceptor would be
>> >> invoked
>> >>>>> for calls against this interface.
>> >>>>>
>> >>>>> It's then up to the application
> developer/framework author to define
>> >>>>> annotations that go on methods, as well as the
> interceptor itself
>> that
>> >>>>> will
>> >>>>> be invoked. The feature for ServiceHandler would be
> to provide the
>> >> API of
>> >>>>> the type and then the infrastructure required to make
> the interceptor
>> >> be
>> >>>>> called. Existing documentation of the feature:
>> >>>>>
>> >>>>>
>> >>
>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> john
>> >>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
if you have a lot of shared code, you can extract it in 1-n method/s or an
abstract class which is still easier than a new concept.
at least i haven't seen an use-case which really needed it. that was the
reason for a +0 (which still means that i'm ok with adding it).
regards,
gerhard
2012/3/6 Pete Muir <pm...@redhat.com>
> So, you mean just write a bean with all the boilerplate code in it?
>
> On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
>
> > hi pete,
> >
> > instead of the interface you can just implement a bean which does the
> same.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/3/6 Pete Muir <pm...@redhat.com>
> >
> >> What CDI mechanism would you use instead?
> >>
> >> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> >>
> >>> +0
> >>> no -1 because there are use-cases for it.
> >>> no +1 because i would use std. cdi mechanisms instead.
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >>>
> >>>> hi john,
> >>>>
> >>>> the sub-task is perfectly fine.
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>>>
> >>>> Hi All
> >>>>>
> >>>>> I wanted to bring up the subject of ServiceHandler. I added 113 as a
> >>>>> child
> >>>>> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let
> me
> >>>>> know if you think it's not appropriate as a child). ServiceHandler
> is
> >> a
> >>>>> feature in Solder that allows you to define an interceptor that
> manages
> >>>>> generic calls against an injected interface. The API is as follows:
> >>>>>
> >>>>> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that
> >> would
> >>>>> be placed on the interface. Indicates what interceptor would be
> >> invoked
> >>>>> for calls against this interface.
> >>>>>
> >>>>> It's then up to the application developer/framework author to define
> >>>>> annotations that go on methods, as well as the interceptor itself
> that
> >>>>> will
> >>>>> be invoked. The feature for ServiceHandler would be to provide the
> >> API of
> >>>>> the type and then the infrastructure required to make the interceptor
> >> be
> >>>>> called. Existing documentation of the feature:
> >>>>>
> >>>>>
> >>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> john
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
So, you mean just write a bean with all the boilerplate code in it?
On 6 Mar 2012, at 15:58, Gerhard Petracek wrote:
> hi pete,
>
> instead of the interface you can just implement a bean which does the same.
>
> regards,
> gerhard
>
>
>
> 2012/3/6 Pete Muir <pm...@redhat.com>
>
>> What CDI mechanism would you use instead?
>>
>> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>>
>>> +0
>>> no -1 because there are use-cases for it.
>>> no +1 because i would use std. cdi mechanisms instead.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>>>
>>>> hi john,
>>>>
>>>> the sub-task is perfectly fine.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>>>
>>>> Hi All
>>>>>
>>>>> I wanted to bring up the subject of ServiceHandler. I added 113 as a
>>>>> child
>>>>> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
>>>>> know if you think it's not appropriate as a child). ServiceHandler is
>> a
>>>>> feature in Solder that allows you to define an interceptor that manages
>>>>> generic calls against an injected interface. The API is as follows:
>>>>>
>>>>> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that
>> would
>>>>> be placed on the interface. Indicates what interceptor would be
>> invoked
>>>>> for calls against this interface.
>>>>>
>>>>> It's then up to the application developer/framework author to define
>>>>> annotations that go on methods, as well as the interceptor itself that
>>>>> will
>>>>> be invoked. The feature for ServiceHandler would be to provide the
>> API of
>>>>> the type and then the infrastructure required to make the interceptor
>> be
>>>>> called. Existing documentation of the feature:
>>>>>
>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>>>
>>>>> Regards,
>>>>>
>>>>> john
>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi pete,
instead of the interface you can just implement a bean which does the same.
regards,
gerhard
2012/3/6 Pete Muir <pm...@redhat.com>
> What CDI mechanism would you use instead?
>
> On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
>
> > +0
> > no -1 because there are use-cases for it.
> > no +1 because i would use std. cdi mechanisms instead.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/3/4 Gerhard Petracek <ge...@gmail.com>
> >
> >> hi john,
> >>
> >> the sub-task is perfectly fine.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/3/4 John D. Ament <jo...@gmail.com>
> >>
> >> Hi All
> >>>
> >>> I wanted to bring up the subject of ServiceHandler. I added 113 as a
> >>> child
> >>> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
> >>> know if you think it's not appropriate as a child). ServiceHandler is
> a
> >>> feature in Solder that allows you to define an interceptor that manages
> >>> generic calls against an injected interface. The API is as follows:
> >>>
> >>> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that
> would
> >>> be placed on the interface. Indicates what interceptor would be
> invoked
> >>> for calls against this interface.
> >>>
> >>> It's then up to the application developer/framework author to define
> >>> annotations that go on methods, as well as the interceptor itself that
> >>> will
> >>> be invoked. The feature for ServiceHandler would be to provide the
> API of
> >>> the type and then the infrastructure required to make the interceptor
> be
> >>> called. Existing documentation of the feature:
> >>>
> >>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
> >>>
> >>> Regards,
> >>>
> >>> john
> >>>
> >>
> >>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Pete Muir <pm...@redhat.com>.
What CDI mechanism would you use instead?
On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
> +0
> no -1 because there are use-cases for it.
> no +1 because i would use std. cdi mechanisms instead.
>
> regards,
> gerhard
>
>
>
> 2012/3/4 Gerhard Petracek <ge...@gmail.com>
>
>> hi john,
>>
>> the sub-task is perfectly fine.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/3/4 John D. Ament <jo...@gmail.com>
>>
>> Hi All
>>>
>>> I wanted to bring up the subject of ServiceHandler. I added 113 as a
>>> child
>>> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
>>> know if you think it's not appropriate as a child). ServiceHandler is a
>>> feature in Solder that allows you to define an interceptor that manages
>>> generic calls against an injected interface. The API is as follows:
>>>
>>> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that would
>>> be placed on the interface. Indicates what interceptor would be invoked
>>> for calls against this interface.
>>>
>>> It's then up to the application developer/framework author to define
>>> annotations that go on methods, as well as the interceptor itself that
>>> will
>>> be invoked. The feature for ServiceHandler would be to provide the API of
>>> the type and then the infrastructure required to make the interceptor be
>>> called. Existing documentation of the feature:
>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>>
>>> Regards,
>>>
>>> john
>>>
>>
>>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
+0
no -1 because there are use-cases for it.
no +1 because i would use std. cdi mechanisms instead.
regards,
gerhard
2012/3/4 Gerhard Petracek <ge...@gmail.com>
> hi john,
>
> the sub-task is perfectly fine.
>
> regards,
> gerhard
>
>
>
> 2012/3/4 John D. Ament <jo...@gmail.com>
>
> Hi All
>>
>> I wanted to bring up the subject of ServiceHandler. I added 113 as a
>> child
>> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
>> know if you think it's not appropriate as a child). ServiceHandler is a
>> feature in Solder that allows you to define an interceptor that manages
>> generic calls against an injected interface. The API is as follows:
>>
>> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that would
>> be placed on the interface. Indicates what interceptor would be invoked
>> for calls against this interface.
>>
>> It's then up to the application developer/framework author to define
>> annotations that go on methods, as well as the interceptor itself that
>> will
>> be invoked. The feature for ServiceHandler would be to provide the API of
>> the type and then the infrastructure required to make the interceptor be
>> called. Existing documentation of the feature:
>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>>
>> Regards,
>>
>> john
>>
>
>
Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
the sub-task is perfectly fine.
regards,
gerhard
2012/3/4 John D. Ament <jo...@gmail.com>
> Hi All
>
> I wanted to bring up the subject of ServiceHandler. I added 113 as a child
> of DELTASPIKE-2, looked appropriate but not 100% sure (so please let me
> know if you think it's not appropriate as a child). ServiceHandler is a
> feature in Solder that allows you to define an interceptor that manages
> generic calls against an injected interface. The API is as follows:
>
> - @ServiceHandlerType(Class<?> clazz) - placed on an annotation that would
> be placed on the interface. Indicates what interceptor would be invoked
> for calls against this interface.
>
> It's then up to the application developer/framework author to define
> annotations that go on methods, as well as the interceptor itself that will
> be invoked. The feature for ServiceHandler would be to provide the API of
> the type and then the infrastructure required to make the interceptor be
> called. Existing documentation of the feature:
>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-servicehandler.html
>
> Regards,
>
> john
>