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 > >>>>>> > >>> > >> > >
