Pete, Regarding interceptors - I think what I have is pretty close to the interceptor definition, except this should only end up working on a class/interface (I think?)
Also, why wouldn't we want the annotation to also be a qualifier? John On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <[email protected]> wrote: > > On 21 Dec 2012, at 02:21, John D. Ament wrote: > > > Hi all, > > > > So just to summarize the current proposal: > > > > - Create a new annotation @ServiceHandlerBinding (in core/api) which will > > be placed on on the interface that defines points of the > > - Create a new annotation @ServiceHandler (in core/api) (I think based on > > below this isn't needed since we have the interface now). > > - Create an extension that can generate object proxies that link calls to > > methods on the - org.apache.deltaspike.core.api.... > > > > Define the binding type annotation: > > > > @ServiceHandlerBinding > > @Qualifier > > public @interface QueryHandler { > > } > > I don't think we want @Qualifier here. > > > > > which will define the relationship between the interface/abstract class > > that will use the service handler and the class that will serve as the > > invocation handler. > > > > For example, we can use @QueryHandler on an interface: > > > > @QueryHandler > > public interface PersonDAO { > > //... > > } > > > > When the container finds this interface it will identify the appropriate > > InvocationHandler, based on the following matches: > > > > - Implements InvocationHandler > > Yes. > > > - Is annotated @QueryHandler > > Ish, this should follow standard CDI resolution rules, you can copy the > way interceptor bindings work here. > > > - Is annotated @ServiceHandler > > Yes > > > > > DeltaSpike will provide a proxied object where all abstract method calls > > are delegated to the InvocationHandler. The InvocationHandler will need > to > > have logic to handle all methods as defined within the class, as long as > > that method is invoked through the InvocationHandler. > > > > @QueryHandler @ServiceHandler > > public QueryHandlerInvoker implements InvocationHandler { > > > > public Object invoke(Object proxy, Method method, Object[] args) { > > if(method.getName().startsWith("find..."){ > > //... > > } > > return null; > > > > } > > } > > > > In addition, the ServiceHandlerBinding can be placed on an abstract > class. > > In this case, only abstract methods will be passed to the > > InvocationHandler. > > > > @QueryHandler > > public abstract interface PersonDAO { > > public String doSomethingConcrete() { > > return "concrete"; > > } > > > > public abstract Person find(int id); > > } > > > > Only the find method will be wrapped, the method doSomethingConcrete will > > be invoked directly. When interacting with an abstract class, the > > InvocationHandler can call methods on the proxied object. > > > > Finally, the app developer will be able to simply inject their > > interface/abstract class in to their beans to perform work: > > > > @Inject @QueryHandler PersonDAO dao; > > > > Questions: > > > > Should we provide a store (simple key/value map) to keep a history of > found > > object types and how they map? > > You mean like BeanManager.resolveInterceptors() ? I guess this is useful. > > > Should we depend on certain libraries for proxying (e.g. javassist, I > think > > both Weld & OWB use this still?) > > If you want to just cover interfaces, it's easy, you can use proxying from > the JDK. Otherwise yes you need to pick a lib. > > Weld doesn't use javassist for proxying, but does for other stuff. > > > Since we now use the interface InvocationHandler should we rename the > > binding to be InvocationHandlerBinding? > > Yes, this makes sense > > > I also think it's not necessary to > > have @ServiceHandler since the marker interface now exists. > > +1 > > > > > Comments welcome.. > > > > John > > > > > > > > > > On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter <[email protected] > >wrote: > > > >> +1 for @ServiceHandler > >> > >> > >> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <[email protected] > >>> wrote: > >> > >>> If we're still calling the feature "ServiceHandler" then why not > >>> @ServiceHandler? > >>> > >>> > >>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau > >>> <[email protected]>wrote: > >>> > >>>> if we don't need it perfect, if we need it we'll just use another name > >>>> @DSHandler, @Handler...whatever it is ;) > >>>> > >>>> 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 Pete Muir <[email protected]>: > >>>>> :-) Yes for sure. I suspect we dont' need @InvocationHandler at all. > >>>>> > >>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote: > >>>>> > >>>>>> The problem I have is that now InvocationHandler is both an > >> interface > >>>> and > >>>>>> an @interface which will make it impossible for imports. I don't > >>> think > >>>>>> they should have the same name. > >>>>>> > >>>>>> > >>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <[email protected]> > >> wrote: > >>>>>> > >>>>>>> > >>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote: > >>>>>>> > >>>>>>>> All, > >>>>>>>> > >>>>>>>> So mostly ok from my perspective. One thing to note: > >>>>>>>> > >>>>>>>> @InvocationHandlerBinding > >>>>>>>> public @interface Repository {} > >>>>>>>> > >>>>>>>> @Repository > >>>>>>>> public interface MyRepository { > >>>>>>>> ... > >>>>>>>> } > >>>>>>>> > >>>>>>>> @Repository @InvocationHandler > >>>>>>>> public class MyInvocationHandler implements InvocationHandler { > >>>>>>>> ... > >>>>>>>> } > >>>>>>>> > >>>>>>>> Why do we have a @InvocationHandler here? Is it supposed to be > >>>>>>>> @InvocationHandlerBinding instead? If so, is it really needed > >> here? > >>>>>>> > >>>>>>> No, it should be @InvocationHandler, it's analagous to > >> @Interceptor. > >>>> It's > >>>>>>> not 100% necessary as we already implement the interface, which is > >>>> enough > >>>>>>> of the marker. > >>>>>>> > >>>>>>>> > >>>>>>>> Thinking about the implementation for this, I think this actually > >>>> becomes > >>>>>>>> easier to use and easier to understand over the Solder solution. > >>> The > >>>>>>>> implementation of the InvocationHandler becomes a true CDI bean. > >>>>>>>> > >>>>>>>> Should DS support Interceptors and Decorators on > >>>>>>>> InvocationHandler beans? > >>>>>>>> > >>>>>>>> Do you mean the implementation class or the interface? > >>>>>>>> > >>>>>>>> John > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau > >>>>>>>> <[email protected]>wrote: > >>>>>>>> > >>>>>>>>> i'd rather say no because the idea is to ease "util" extension > >>>>>>>>> writing. that's clearly not intended to be full business beans > >> IMO > >>>> (at > >>>>>>>>> least for a first step) > >>>>>>>>> > >>>>>>>>> That's why i'd leave it as this for now > >>>>>>>>> > >>>>>>>>> wdyt? > >>>>>>>>> > >>>>>>>>> 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]>: > >>>>>>>>>> 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 > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >> > >> > >> > >> -- > >> 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 > >> > >
