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 <[email protected]>:
>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 <[email protected]>
>>> To: "[email protected]"
>>><[email protected]>
>>> 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
>>> <[email protected]>:
>>>
>>>> +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 <[email protected]>:
>>>>> 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
>>>>> <[email protected]>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 <
>>>>>> [email protected]
>>>>>>> wrote:
>>>>>>
>>>>>>> hi john,
>>>>>>>
>>>>>>> as mentioned before we need the answers to the existing
>>> questions.
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/4/4 John D. Ament <[email protected]>
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> [email protected]> 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
>>> <[email protected]>
>>>>>>>>>
>>>>>>>>>> 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
>>> <[email protected]>
>>>>>>>>>>
>>>>>>>>>>> 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
>>> <[email protected]>
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>> <[email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>> <[email protected]>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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" <
>>>>>>>>> [email protected]>
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>> 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" <
>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>>>>>>>> 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
>>>>>> <[email protected]>
>>>>>>>>>>>>>>>>>>>>>
>>> To: [email protected]
>>>>>>>>>>>>>>>>>>>>>
>>> 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 <[email protected]>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>> <[email protected]>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>> [email protected]
>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the sub-task is perfectly
>>> fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>> <[email protected]>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>
>
