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...@gmail.com>wrote:
>
>> +1 for @ServiceHandler
>>
>>
>> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <john.d.am...@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
>>> <rmannibu...@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 <pm...@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 <pm...@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
>>>>>>>> <rmannibu...@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.limb...@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
>>>>>>>>>> <rmannibu...@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 <strub...@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.limb...@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
>>>>>>>>>>>>> <rmannibu...@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...@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.am...@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.petra...@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.am...@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.petra...@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
>>>>>>>>>>>>> <gegasta...@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.petra...@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
>>>>>>>>>>>>> <gegasta...@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
>>>>>>>>>>>>> <pm...@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
>>>>>>>>>>>>> <pm...@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.am...@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...@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.am...@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 <
>>>>>>>>>>>>>>>>>>>>>> strub...@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.petra...@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 <pm...@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
>>>>>>>>>>>>> <pm...@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.petra...@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>>>>>>>>> fine.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>>>>>>>>> <john.d.am...@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
>>
