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