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 11:11:51 GMT
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 <struberg@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 <arne.limburg@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@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
>> <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-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
>>

Mime
View raw message