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
>

Reply via email to