deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Mon, 24 Dec 2012 13:47:39 GMT
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 <struberg@yahoo.de> 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 <john.d.ament@gmail.com>
>>> To: deltaspike-dev@incubator.apache.org
>>> 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 <pmuir@redhat.com> 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
>>> <lightguard.jp@gmail.com
>>>>> wrote:
>>>>> 
>>>>>> +1 for @ServiceHandler
>>>>>> 
>>>>>> 
>>>>>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament
>>> <john.d.ament@gmail.com
>>>>>>> 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
>>>>>>> <rmannibucau@gmail.com>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 <pmuir@redhat.com>:
>>>>>>>>> :-) 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
>>> <pmuir@redhat.com>
>>>>>> 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
>>>>>>>>>>>> <rmannibucau@gmail.com>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
>>> <arne.limburg@openknowledge.de>:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <rmannibucau@gmail.com>:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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
>>> <struberg@yahoo.de>:
>>>>>>>>>>>>>>>> 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
>>> <arne.limburg@openknowledge.de>
>>>>>>>>>>>>>>>>> To:
>>> "deltaspike-dev@incubator.apache.org"
>>>>>>>>>>>>>>>>> 
>>> <deltaspike-dev@incubator.apache.org>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 
>>> <rmannibucau@gmail.com>:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> +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 <lightguard.jp@gmail.com>:
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> 
>>> <john.d.ament@gmail.com>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 <
>>>>>>>>>>>>>>>>>>>> 
>>> gerhard.petracek@gmail.com
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> hi
>>> john,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> as
>>> mentioned before we need the answers to the existing
>>>>>>>>>>>>>>>>> questions.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>> regards,
>>>>>>>>>>>>>>>>>>>>> 
>>> gerhard
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>> 2012/4/4 John D. Ament <john.d.ament@gmail.com>
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>> 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 <
>>>>>>>>>>>>>>>>>>>>>> 
>>> gerhard.petracek@gmail.com> 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
>>>>>>>>>>>>>>>>> 
>>> <gegastaldi@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>> 
>>> <gerhard.petracek@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>> 
>>> <gegastaldi@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>> 
>>> <pmuir@redhat.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>> 
>>> <pmuir@redhat.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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" <
>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>> john.d.ament@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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 <
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> lightguard.jp@gmail.com
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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" <
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> john.d.ament@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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 <
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> struberg@yahoo.de>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>>>>> 
>>> <gerhard.petracek@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> To:
>>> deltaspike-dev@incubator.apache.org
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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
>>> <pmuir@redhat.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>>>>>>>>>>>>> 
>>> <pmuir@redhat.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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 <
>>>>>>>>>>>>>>>>>>>>> 
>>> gerhard.petracek@gmail.com
>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> hi john,
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> the sub-task is perfectly
>>>>>>>>>>>>>>>>> fine.
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> regards,
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> gerhard
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 2012/3/4 John D. Ament
>>>>>>>>>>>>>>>>>>>> 
>>> <john.d.ament@gmail.com>
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>> 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
>>>>>> 
>>>> 
>>>> 
>>> 
>> 


Mime
View raw message