deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 20 Dec 2012 09:36:54 GMT
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 <arne.limburg@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
> <rmannibucau@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 <arne.limburg@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
>>> <rmannibucau@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 <lightguard.jp@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
>>>>><john.d.ament@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 <john.d.ament@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 <gegastaldi@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 <gerhard.petracek@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 <gegastaldi@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 <pmuir@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 <pmuir@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
>>>>>><gerhard.petracek@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 <pmuir@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 <pmuir@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
>>>>>><john.d.ament@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
>>>
>

Mime
View raw message