+1 for doing it with bindings, I wish I had done it this way the first time around :-)
On 20 Dec 2012, at 09:36, Romain Manni-Bucau wrote: > 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 <[email protected]>: >> 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 >> <[email protected]>: >> >>> 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 <[email protected]>: >>>> 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 >>>> <[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-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 >>>> >>
