I guess because it might overlap with other qualifiers added in some cases.
What do we gain for making it a qualifier? Another important difference to CDI interceptors is that they are always @Dependent to the intercepted instance. Whereas the ServiceHandler should be of NormalScope, isn't? LieGrue, strub ----- Original Message ----- > From: John D. Ament <[email protected]> > To: [email protected] > Cc: > Sent: Saturday, December 22, 2012 7:56 PM > Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler > > 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 >> >> >> >> >
