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