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