I think it should work, adding a qualifier, but I don't think it's the "normal" way to do it.
On 23 Dec 2012, at 16:12, John D. Ament wrote: > Well, this object is used for a specific case. In my opinion, you should be > able to resolve it using > > @Inject @QueryHandler > private InvocationHandler queryHandler; > > Though why you may want to inject it in a client app is unknown to me; it > does make it easier from an implementation standpoint. > > Does the service handler need to have any specific scope? Can it inherit > the scope of what it's handling? I guess not, since it could be a handler > to n things. NormalScope would be appropriate then. > > > On Sat, Dec 22, 2012 at 2:50 PM, Mark Struberg <[email protected]> wrote: > >> I guess because it might overlap with other qualifiers added in some cases. >> >> What do we gain for making it a qualifier? >> >> Another important difference to CDI interceptors is that they are always >> @Dependent to the intercepted instance. >> Whereas the ServiceHandler should be of NormalScope, isn't? >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: John D. Ament <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Saturday, December 22, 2012 7:56 PM >>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler >>> >>> Pete, >>> >>> Regarding interceptors - I think what I have is pretty close to the >>> interceptor definition, except this should only end up working on a >>> class/interface (I think?) >>> >>> Also, why wouldn't we want the annotation to also be a qualifier? >>> >>> John >>> >>> >>> On Fri, Dec 21, 2012 at 5:21 AM, Pete Muir <[email protected]> wrote: >>> >>>> >>>> On 21 Dec 2012, at 02:21, John D. Ament wrote: >>>> >>>>> Hi all, >>>>> >>>>> So just to summarize the current proposal: >>>>> >>>>> - Create a new annotation @ServiceHandlerBinding (in core/api) which >>> will >>>>> be placed on on the interface that defines points of the >>>>> - Create a new annotation @ServiceHandler (in core/api) (I think >> based >>> on >>>>> below this isn't needed since we have the interface now). >>>>> - Create an extension that can generate object proxies that link >> calls >>> to >>>>> methods on the - org.apache.deltaspike.core.api.... >>>>> >>>>> Define the binding type annotation: >>>>> >>>>> @ServiceHandlerBinding >>>>> @Qualifier >>>>> public @interface QueryHandler { >>>>> } >>>> >>>> I don't think we want @Qualifier here. >>>> >>>>> >>>>> which will define the relationship between the interface/abstract >>> class >>>>> that will use the service handler and the class that will serve as >> the >>>>> invocation handler. >>>>> >>>>> For example, we can use @QueryHandler on an interface: >>>>> >>>>> @QueryHandler >>>>> public interface PersonDAO { >>>>> //... >>>>> } >>>>> >>>>> When the container finds this interface it will identify the >>> appropriate >>>>> InvocationHandler, based on the following matches: >>>>> >>>>> - Implements InvocationHandler >>>> >>>> Yes. >>>> >>>>> - Is annotated @QueryHandler >>>> >>>> Ish, this should follow standard CDI resolution rules, you can copy the >>>> way interceptor bindings work here. >>>> >>>>> - Is annotated @ServiceHandler >>>> >>>> Yes >>>> >>>>> >>>>> DeltaSpike will provide a proxied object where all abstract method >>> calls >>>>> are delegated to the InvocationHandler. The InvocationHandler will >>> need >>>> to >>>>> have logic to handle all methods as defined within the class, as long >>> as >>>>> that method is invoked through the InvocationHandler. >>>>> >>>>> @QueryHandler @ServiceHandler >>>>> public QueryHandlerInvoker implements InvocationHandler { >>>>> >>>>> public Object invoke(Object proxy, Method method, Object[] args) { >>>>> if(method.getName().startsWith("find..."){ >>>>> //... >>>>> } >>>>> return null; >>>>> >>>>> } >>>>> } >>>>> >>>>> In addition, the ServiceHandlerBinding can be placed on an abstract >>>> class. >>>>> In this case, only abstract methods will be passed to the >>>>> InvocationHandler. >>>>> >>>>> @QueryHandler >>>>> public abstract interface PersonDAO { >>>>> public String doSomethingConcrete() { >>>>> return "concrete"; >>>>> } >>>>> >>>>> public abstract Person find(int id); >>>>> } >>>>> >>>>> Only the find method will be wrapped, the method doSomethingConcrete >>> will >>>>> be invoked directly. When interacting with an abstract class, the >>>>> InvocationHandler can call methods on the proxied object. >>>>> >>>>> Finally, the app developer will be able to simply inject their >>>>> interface/abstract class in to their beans to perform work: >>>>> >>>>> @Inject @QueryHandler PersonDAO dao; >>>>> >>>>> Questions: >>>>> >>>>> Should we provide a store (simple key/value map) to keep a history of >>>> found >>>>> object types and how they map? >>>> >>>> You mean like BeanManager.resolveInterceptors() ? I guess this is >> useful. >>>> >>>>> Should we depend on certain libraries for proxying (e.g. javassist, I >>>> think >>>>> both Weld & OWB use this still?) >>>> >>>> If you want to just cover interfaces, it's easy, you can use proxying >>> from >>>> the JDK. Otherwise yes you need to pick a lib. >>>> >>>> Weld doesn't use javassist for proxying, but does for other stuff. >>>> >>>>> Since we now use the interface InvocationHandler should we rename the >>>>> binding to be InvocationHandlerBinding? >>>> >>>> Yes, this makes sense >>>> >>>>> I also think it's not necessary to >>>>> have @ServiceHandler since the marker interface now exists. >>>> >>>> +1 >>>> >>>>> >>>>> Comments welcome.. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter >>> <[email protected] >>>>> wrote: >>>>> >>>>>> +1 for @ServiceHandler >>>>>> >>>>>> >>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament >>> <[email protected] >>>>>>> wrote: >>>>>> >>>>>>> If we're still calling the feature >>> "ServiceHandler" then why not >>>>>>> @ServiceHandler? >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> if we don't need it perfect, if we need it we'll >>> just use another name >>>>>>>> @DSHandler, @Handler...whatever it is ;) >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> Twitter: @rmannibucau >>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>> Github: https://github.com/rmannibucau >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2012/12/20 Pete Muir <[email protected]>: >>>>>>>>> :-) Yes for sure. I suspect we dont' need >>> @InvocationHandler at all. >>>>>>>>> >>>>>>>>> On 20 Dec 2012, at 16:30, John D. Ament wrote: >>>>>>>>> >>>>>>>>>> The problem I have is that now InvocationHandler >>> is both an >>>>>> interface >>>>>>>> and >>>>>>>>>> an @interface which will make it impossible for >>> imports. I don't >>>>>>> think >>>>>>>>>> they should have the same name. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir >>> <[email protected]> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 20 Dec 2012, at 12:32, John D. Ament wrote: >>>>>>>>>>> >>>>>>>>>>>> All, >>>>>>>>>>>> >>>>>>>>>>>> So mostly ok from my perspective. One >>> thing to note: >>>>>>>>>>>> >>>>>>>>>>>> @InvocationHandlerBinding >>>>>>>>>>>> public @interface Repository {} >>>>>>>>>>>> >>>>>>>>>>>> @Repository >>>>>>>>>>>> public interface MyRepository { >>>>>>>>>>>> ... >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> @Repository @InvocationHandler >>>>>>>>>>>> public class MyInvocationHandler >>> implements InvocationHandler { >>>>>>>>>>>> ... >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Why do we have a @InvocationHandler here? >>> Is it supposed to be >>>>>>>>>>>> @InvocationHandlerBinding instead? If so, >>> is it really needed >>>>>> here? >>>>>>>>>>> >>>>>>>>>>> No, it should be @InvocationHandler, it's >>> analagous to >>>>>> @Interceptor. >>>>>>>> It's >>>>>>>>>>> not 100% necessary as we already implement the >>> interface, which is >>>>>>>> enough >>>>>>>>>>> of the marker. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thinking about the implementation for >>> this, I think this actually >>>>>>>> becomes >>>>>>>>>>>> easier to use and easier to understand >>> over the Solder solution. >>>>>>> The >>>>>>>>>>>> implementation of the InvocationHandler >>> becomes a true CDI bean. >>>>>>>>>>>> >>>>>>>>>>>> Should DS support Interceptors and >>> Decorators on >>>>>>>>>>>> InvocationHandler beans? >>>>>>>>>>>> >>>>>>>>>>>> Do you mean the implementation class or >>> the interface? >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 20, 2012 at 7:06 AM, Romain >>> Manni-Bucau >>>>>>>>>>>> <[email protected]>wrote: >>>>>>>>>>>> >>>>>>>>>>>>> i'd rather say no because the idea >>> is to ease "util" extension >>>>>>>>>>>>> writing. that's clearly not >>> intended to be full business beans >>>>>> IMO >>>>>>>> (at >>>>>>>>>>>>> least for a first step) >>>>>>>>>>>>> >>>>>>>>>>>>> That's why i'd leave it as >>> this for now >>>>>>>>>>>>> >>>>>>>>>>>>> wdyt? >>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>> Blog: >>> http://rmannibucau.wordpress.com/ >>>>>>>>>>>>> LinkedIn: >>> http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/12/20 Arne Limburg >>> <[email protected]>: >>>>>>>>>>>>>> Mark refers to my call stack. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Out of the box this call stack >>> would exist just in OWB, because >>>>>>> Weld >>>>>>>>>>>>> would >>>>>>>>>>>>>> not apply any Interceptors or >>> Decorators... >>>>>>>>>>>>>> >>>>>>>>>>>>>> The question is: Should DS support >>> Interceptors and Decorators >>>>>> on >>>>>>>>>>>>>> InvocationHandler beans? My answer >>> would be: yes, if our >>>>>>>> implementation >>>>>>>>>>>>>> shall be a preview of CDI-110. >>>>>>>>>>>>>> And that would make things >>> complicated in the implementation... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 20.12.12 12:11 schrieb >>> "Romain Manni-Bucau" unter >>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> is it an issue for >>> servicehandler? i don't think so >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> it is often used to get util >>> classes dynamically created, it is >>>>>>>> rarely >>>>>>>>>>>>>>> (i never saw it) decorated >>> directly >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>> Blog: >>> http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>> LinkedIn: >>> http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>> Github: >>> https://github.com/rmannibucau >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/12/20 Mark Struberg >>> <[email protected]>: >>>>>>>>>>>>>>>> we stumbled about this >>> lately. It seems CDI only forces >>>>>> support >>>>>>>> for >>>>>>>>>>>>>>>> interceptors and >>> decorators for CDI-annotated classes, but not >>>>>>> for >>>>>>>>>>>>>>>> Bean<T> which get >>> added via extensions nor even producer >>>>>> methods >>>>>>>> and >>>>>>>>>>>>>>>> fields :/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course OWB does it, but >>> it would be not portable... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>>>> strub >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ----- Original Message >>> ----- >>>>>>>>>>>>>>>>> From: Arne Limburg >>> <[email protected]> >>>>>>>>>>>>>>>>> To: >>> "[email protected]" >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>>>>>>>>>>>>>>> Cc: >>>>>>>>>>>>>>>>> Sent: Thursday, >>> December 20, 2012 10:18 AM >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS] >>> [DELTASPIKE-113] Review and Discuss >>>>>>>>>>>>>>>>> ServiceHandler >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> T wo things about >>> this: First: I don't like from the solder >>>>>>>>>>> approach, >>>>>>>>>>>>>>>>> because the interface >>> is annotated instead of the >>>>>>> implementation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Second, if we >>> implement this we should conceptually make >>>>>> clear >>>>>>>> how >>>>>>>>>>> it >>>>>>>>>>>>>>>>> differentiates from >>> Interceptors and Decorators. And >>>>>>> personally I >>>>>>>>>>>>> think >>>>>>>>>>>>>>>>> this would work better >>> with the InvocationHandler approach >>>>>> than >>>>>>>> with >>>>>>>>>>>>> an >>>>>>>>>>>>>>>>> approach that is very >>> similar to interceptors. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So +1 for an approach >>> like this: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>> @HandlesInvocationsOn(MyInterface.class) >>>>>>>>>>>>>>>>> public class >>> MyInvocationHandler implements >>>>>> InvocationHandler { >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Technically we would >>> register a custom Bean for every found >>>>>>>>>>>>>>>>> InvocationHandler with >>> that annotation and take over the >>>>>>>>>>>>>>>>> interceptor-bindings >>> from the interfaceŠ >>>>>>>>>>>>>>>>> So the invocation >>> stack would be clear, too: >>>>>>>>>>>>>>>>> First Interceptors, >>>>>>>>>>>>>>>>> Second Decorators, >>>>>>>>>>>>>>>>> Third >>> InvocationHandler >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Wdyt? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 20.12.12 01:53 >>> schrieb "Romain Manni-Bucau" unter >>>>>>>>>>>>>>>>> >>> <[email protected]>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that's a need, >>> DS targets CDI 1.0 for now so just make this >>>>>>>> solder >>>>>>>>>>>>>>>>>> part portable ans >>> it should be fine >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>> Twitter: >>> @rmannibucau >>>>>>>>>>>>>>>>>> Blog: >>> http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>>>> LinkedIn: >>> http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>>>> Github: >>> https://github.com/rmannibucau >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2012/12/20 Jason >>> Porter <[email protected]>: >>>>>>>>>>>>>>>>>>> At this point, >>> I'd say just do it as is in solder. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Dec >>> 19, 2012 at 5:25 PM, John D. Ament >>>>>>>>>>>>>>>>>>> >>> <[email protected]>wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regarding >>> the two open questions: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1) the >>> approach (including the name/s) we agree on will be >>>>>>>> used >>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> cdi 1.1 >>> (the only difference is the package) >>>>>>>>>>>>>>>>>>>> 2) the eg >>> has a different opinion about it -> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It looks >>> like the JSR's answer >>>>>>>>>>>>>>>>>>>> >>> (https://issues.jboss.org/browse/CDI-110 ) >>>>>>>>>>>>>>>>>>>> is still >>> unresolved - I'm not sure if we can get any >>>>>> further >>>>>>>>>>>>>>>>> answer at >>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> time. The >>> last posts on the subject seem to discuss using >>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>> along >>>>>>>>>>>>>>>>>>>> the lines >>> of an invocation handler, which I think would >>>>>> work >>>>>>>>>>> well. >>>>>>>>>>>>>>>>>>>> Since >>>>>>>>>>>>>>>>>>>> we have >>> some features coming up that are interested in >>>>>>> having >>>>>>>>>>>>>>>>> service >>>>>>>>>>>>>>>>>>>> handlers >>> available, do we >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1. >>> Implement as is, or similar to, what is currently in >>>>>>>> Solder? >>>>>>>>>>>>>>>>>>>> 2. Push EG >>> on a resolution >>>>>>>>>>>>>>>>>>>> 3. Do it >>> using invocation handlers. >>>>>>>>>>>>>>>>>>>> 4. Do it >>> some other way? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> John >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, >>> Apr 4, 2012 at 3:50 PM, Gerhard Petracek < >>>>>>>>>>>>>>>>>>>> >>> [email protected] >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> hi >>> john, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> as >>> mentioned before we need the answers to the existing >>>>>>>>>>>>>>>>> questions. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>> regards, >>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>> 2012/4/4 John D. Ament <[email protected]> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>> All, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I >>> kind of let this one and the other drop off my radar, >>>>>> I >>>>>>>>>>>>>>>>>>>> apologize. >>>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>> >>> looks like where we last left off, Gerhard was still >>>>>>>>>>>>>>>>> requesting >>>>>>>>>>>>>>>>>>>>> >>> additional >>>>>>>>>>>>>>>>>>>>>> >>> comments from everyone. Any other feedback? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>> John >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On >>> Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek < >>>>>>>>>>>>>>>>>>>>>> >>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> hi >>> george, >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> thx >>> for the information. i thought there might be at >>>>>>>>>>>>>>>>> least some >>>>>>>>>>>>>>>>>>>>>> >>> additional >>>> >>>>>>>>>>>>>>>>>>>>>> >>> answers/clarifications, since pete asked for them in >>>>>>>>>>>>>>>>> several >>>>>>>>>>>>>>>>>>>> comments. >>>> >>>>>>>>>>>>>>>>>>>>>> >>> -> imo we should continue with them. >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/12 George Gastaldi >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> Hello Gerhard, >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> Yeah, it´s the last state. I know it´s quite >>>>>>>>>>>>>>>>> old, but I >>>>>>>>>>>>>>>>>>>> haven´t >>> had >>>>>>>>>>>>>>>>>>>>>> >>> time >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> to work on it after that. >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> Regards, >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> George >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/12 Gerhard Petracek >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> hi george, >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> thx for the link. >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> i'm not sure if it is the latest state >>>>>>>>>>>>>>>>> of your discussion >>>>>>>>>>>>>>>>>>>> and/or >>>>>>>>>>>>>>>>>>>>> draft >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> (at least it's quite old already). >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/7 George Gastaldi >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Hi ! >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> +1 to #1. I also agree that the term >>>>>>>>>>>>>>>>> "Service >>> Handler" might >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>> so >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> appropriate, so it should be discussed >>>>>>>>>>>>>>>>> as well. >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Here is the latest pull request with >>>>>>>>>>>>>>>>> some comments from >>> Pete >>>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>> be >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> reviewed: >>>>>>>>>>>>>>>>> >>> https://github.com/jboss/cdi/pull/28 >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/7 Pete Muir >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> Agreed :-) >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> George is working on it for CDI >>>>>>>>>>>>>>>>> 1.1. George, can you >>> share >>>>>>>>>>>>>>>>>>>> your >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> proposal >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> so far? >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> On 7 Mar 2012, at 17:05, Gerhard >>>>>>>>>>>>>>>>> Petracek wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> hi pete, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> independent of my opinion >>>>>>>>>>>>>>>>> about the feature >>> (which is >>>>>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>>>>> +0): >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> if it should be part of cdi >>>>>>>>>>>>>>>>> 1.1, we have the >>> following >>>>>>>>>>>>>>>>>>>> options >>>>>>>>>>>>>>>>>>>>>> >>> imo: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 1) the approach (including >>>>>>>>>>>>>>>>> the name/s) we agree >>> on will >>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> used >>>> >>>>>>>>>>>>>>>>>>>>>> >>> also >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> for >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> cdi 1.1 (the only difference >>>>>>>>>>>>>>>>> is the package) >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2) the eg has a different >>>>>>>>>>>>>>>>> opinion about it -> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2a) the rest of the eg joins >>>>>>>>>>>>>>>>> this discussion >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2b) we wait for the final >>>>>>>>>>>>>>>>> version and just allow >>> the same >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> >>> cdi >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> 1.0 >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 3) if the eg doesn't >>>>>>>>>>>>>>>>> agree on the idea, it >>> should be >>>>>>>>>>>>>>>>>>>> re-visited >>>>>>>>>>>>>>>>>>>>>> >>> for >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> deltaspike (if we really need >>>>>>>>>>>>>>>>> it) >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 4) we agree on it independent >>>>>>>>>>>>>>>>> of the result in cdi >>> 1.1 >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 1-3 is ok for me but -1 for >>>>>>>>>>>>>>>>> #4 >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/7 Pete Muir >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> I'm not sure what you >>>>>>>>>>>>>>>>> mean by a "super >>> interceptor", >>>>>>>>>>>>>>>>>>>> but if >>>>>>>>>>>>>>>>>>>>> you >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> mean it >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> as >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> in "super man" >>>>>>>>>>>>>>>>> (something better than >>> an interceptor), >>>>>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>>>>> I >>>> >>>>>>>>>>>>>>>>>>>>>> >>> would >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> disagree, it's >>>>>>>>>>>>>>>>> actually a specialised >>> form of >>>>>>>>>>>>>>>>>>>> >>> interceptor. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> The best use case I know >>>>>>>>>>>>>>>>> of is the one John >>> mentions - >>>>>>>>>>>>>>>>>>>>> >>> creating >>>> >>>>>>>>>>>>>>>>>>>>>> >>> type >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> safe >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> references to queries: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> @QueryService >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> interface UserQuery { >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> @Query("select u >>>>>>>>>>>>>>>>> from User u") >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> public List<User> >>>>>>>>>>>>>>>>> getAllUsers(); >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> @Query("select u >>>>>>>>>>>>>>>>> from User u order by >>> u.name") >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> public List<User> >>>>>>>>>>>>>>>>> >>> getAllUsersSortedByName(); >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> } >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Now, it may be the case >>>>>>>>>>>>>>>>> that there aren't >>> any other use >>>>>>>>>>>>>>>>>>>> cases >>>>>>>>>>>>>>>>>>>>>> >>> for >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> service >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> handlers, in which case >>>>>>>>>>>>>>>>> we should perhaps just >>> offer >>>>>>>>>>>>>>>>>>>> this >>>> >>>>>>>>>>>>>>>>>>>>>> >>> particular >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> service handler - >>>>>>>>>>>>>>>>> references to type >>> safe queries - as I >>>>>>>>>>>>>>>>>>>> think >>>> >>>>>>>>>>>>>>>>>>>>>> >>> this >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> is >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> an >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> extremely powerful idea. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Note, that at the moment >>>>>>>>>>>>>>>>> service handlers are >>> scheduled >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>> CDI >>>> >>>>>>>>>>>>>>>>>>>>>> >>> 1.1. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On 7 Mar 2012, at 02:35, >>>>>>>>>>>>>>>>> Jason Porter wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Somewhat. I >>>>>>>>>>>>>>>>> wouldn't really >>> think of them as overrides, >>>>>>>>>>>>>>>>>>>> they, >>>>>>>>>>>>>>>>>>>>>> to >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> me, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> seem more like items to >>>>>>>>>>>>>>>>> do in addition to >>> whatever the >>>>>>>>>>>>>>>>>>>>> >>> original >>>> >>>>>>>>>>>>>>>>>>>>>> >>> impl >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> does. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> ServiceHandlers to me >>>>>>>>>>>>>>>>> seem more like super >>>>>>>>>>>>>>>>>>>> >>> interceptors. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Sent from my iPhone >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On Mar 6, 2012, at >>>>>>>>>>>>>>>>> 19:23, "John D. >>> Ament" < >>>> >>>>>>>>>>>>>>>>>>>>>> >>> [email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> @jason >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> I think the >>>>>>>>>>>>>>>>> concepts are very >>> dissimilar. >>>>>>>>>>>>>>>>>>>> >>> servicehandlers >>>> >>>>>>>>>>>>>>>>>>>>>> >>> create >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> implementation. >>>>>>>>>>>>>>>>> delegates are more >>> like overrides and >>>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>> to >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> know >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> about >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> the method >>>>>>>>>>>>>>>>> signature. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On Tue, Mar 6, >>>>>>>>>>>>>>>>> 2012 at 9:17 PM, Jason >>> Porter < >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> [email protected] >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> I think the >>>>>>>>>>>>>>>>> idea of >>> ServiceHandlers are good, but, >>>>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>> >>> not >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> do >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> this >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> with >>>>>>>>>>>>>>>>> delegates? >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Sent from my >>>>>>>>>>>>>>>>> iPhone >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On Mar 6, >>>>>>>>>>>>>>>>> 2012, at 19:05, >>> "John D. Ament" < >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> [email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> @mark >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> I >>>>>>>>>>>>>>>>> don't think >>> it's a hard requirement for it to be >>>>>>>>>>>>>>>>>>>> on an >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> interface. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> One of >>>>>>>>>>>>>>>>> the best use-cases we >>> built at my job is >>>>>>>>>>>>>>>>>>>> using it >>>>>>>>>>>>>>>>>>>>> for >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> calling >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> PL/SQL. >>>>>>>>>>>>>>>>> The JDBC bindings do >>> work, but not pretty. >>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> were >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> able to >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> create >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> a fairly >>>>>>>>>>>>>>>>> clean wrapper API, >>> generic enough for >>>>>>>>>>>>>>>>>>>> binding >>>>>>>>>>>>>>>>>>>>>> >>> in/out >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> parameters. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> JOhn >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On Tue, >>>>>>>>>>>>>>>>> Mar 6, 2012 at 12:58 >>> PM, Mark Struberg < >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> [email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> actually I don't >>> really see a real benefit. I just >>>>>>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>> >>> yet >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> grok >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> use >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> case >>>>>>>>>>>>>>>>> for real world >>> projects. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Why >>>>>>>>>>>>>>>>> would one intercept an >>> Interface and delegate >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> calls >>>> >>>>>>>>>>>>>>>>>>>>>> to >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> a >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> method >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> handler? >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> This >>>>>>>>>>>>>>>>> could be neat for >>> mocking, but there are >>>>>>>>>>>>>>>>>>>> better >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> frameworks for >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> that. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> thus >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> -0.2 >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> LieGrue, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> strub >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> ----- >>>>>>>>>>>>>>>>> Original Message ----- >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: Gerhard Petracek >>>>>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To: >>> [email protected] >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sent: Tuesday, March >>> 6, 2012 5:15 PM >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Subject: Re: [DISCUSS] >>> [DELTASPIKE-113] Review and >>>>>>>>>>>>>>>>>>>>> >>> Discuss >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ServiceHandler >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if you have a lot of >>> shared code, you can extract >>>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> >>> 1-n >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> method/s or >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> an >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> abstract class which >>> is still easier than a new >>>>>>>>>>>>>>>>>>>> concept. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> at least i haven't >>> seen an use-case which really >>>>>>>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>>>>>>>>> >>> it. >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> that >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> was >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> reason for a +0 (which >>> still means that i'm ok >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> adding >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> it). >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> So, you mean just write a bean with all the >>>>>>>>>>>>>>>>>>>> >>> boilerplate >>>> >>>>>>>>>>>>>>>>>>>>>> >>> code >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> in >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> it? >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On 6 Mar 2012, at 15:58, Gerhard Petracek >>>>>>>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> hi pete, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> instead of the interface you can just >>>>>>>>>>>>>>>>> implement >>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>> bean >>>> >>>>>>>>>>>>>>>>>>>>>> >>> which >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> does >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> same. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/6 Pete Muir >>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> What CDI mechanism would you use >>>>>>>>>>>>>>>>> instead? >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> On 5 Mar 2012, at 08:47, Gerhard >>>>>>>>>>>>>>>>> Petracek >>>>>>>>>>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> +0 >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> no -1 because there are >>>>>>>>>>>>>>>>> use-cases for it. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> no +1 because i would use std. >>>>>>>>>>>>>>>>> cdi mechanisms >>>>>>>>>>>>>>>>>>>>> >>> instead. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/4 Gerhard Petracek < >>>>>>>>>>>>>>>>>>>>> >>> [email protected] >>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> hi john, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> the sub-task is perfectly >>>>>>>>>>>>>>>>> fine. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> gerhard >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> 2012/3/4 John D. Ament >>>>>>>>>>>>>>>>>>>> >>> <[email protected]> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Hi All >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> I wanted to bring up >>>>>>>>>>>>>>>>> the subject of >>>>>>>>>>>>>>>>>>>>> >>> ServiceHandler. >>>>>>>>>>>>>>>>>>>>>> I >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> added 113 as a >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> child >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> of DELTASPIKE-2, looked >>>>>>>>>>>>>>>>> appropriate but not >>>>>>>>>>>>>>>>>>>> 100% >>>>>>>>>>>>>>>>>>>>>> >>> sure >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (so please let >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> me >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> know if you think >>>>>>>>>>>>>>>>> it's not >>> appropriate as a >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> child). >>> ServiceHandler >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> is >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> a >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> feature in Solder that >>>>>>>>>>>>>>>>> allows you to define >>>>>>>>>>>>>>>>>>>> an >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> interceptor that >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> manages >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> generic calls against >>>>>>>>>>>>>>>>> an injected interface. >>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>>>> >>> API >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> is as follows: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> - >>>>>>>>>>>>>>>>> >>> @ServiceHandlerType(Class<?> clazz) - >>>>>>>>>>>>>>>>>>>> placed >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> on an annotation that >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> would >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> be placed on the >>>>>>>>>>>>>>>>> interface. Indicates >>> what >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> interceptor would be >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> invoked >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> for calls against this >>>>>>>>>>>>>>>>> interface. >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> It's then up to the >>>>>>>>>>>>>>>>> application >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> developer/framework >>> author to define >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> annotations that go on >>>>>>>>>>>>>>>>> methods, as well as >>>>>>>>>>>>>>>>>>>> the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> interceptor itself >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> that >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> will >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> be invoked. The >>>>>>>>>>>>>>>>> feature for >>> ServiceHandler >>>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>>> be >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> to provide the >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> API of >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> the type and then the >>>>>>>>>>>>>>>>> infrastructure >>>>>>>>>>>>>>>>>>>> required >>> to >>>>>>>>>>>>>>>>>>>>>> >>> make >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the interceptor >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>> be >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> called. Existing >>>>>>>>>>>>>>>>> documentation of the >>>>>>>>>>>>>>>>>>>> feature: >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder- >>>>>>>>>>>>>>>>>>>> ser >>>>>>>>>>>>>>>>>>>> >>> vicehandler.html >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Regards, >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> john >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Jason Porter >>>>>>>>>>>>>>>>>>> >>> http://lightguard-jp.blogspot.com >>>>>>>>>>>>>>>>>>> >>> http://twitter.com/lightguardjp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Software >>> Engineer >>>>>>>>>>>>>>>>>>> Open Source >>> Advocate >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PGP key id: >>> 926CCFF5 >>>>>>>>>>>>>>>>>>> PGP key >>> available at: keyserver.net, pgp.mit.edu >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jason Porter >>>>>> http://lightguard-jp.blogspot.com >>>>>> http://twitter.com/lightguardjp >>>>>> >>>>>> Software Engineer >>>>>> Open Source Advocate >>>>>> >>>>>> PGP key id: 926CCFF5 >>>>>> PGP key available at: keyserver.net, pgp.mit.edu >>>>>> >>>> >>>> >>> >>
