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 <[email protected]>: >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 <[email protected]>: >> 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 >>>
