deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 20 Dec 2012 15:31:12 GMT
Yes, decorators would be cool, since it would introduce the ability to use
decorators as mixins without having a base class.


For those who are not familiar with mixins, I have coded a gist where
mixins are used to resolve a multiple inheritance scenario [1]
The base idea of mixins is to create small code snippets (smaller than a
complete class), that the provide more reusability than a class...
In my example there is a mixin that holds just one property ("title") that
can be used for every component that has a title
and another mixin that provides a better implementation of the Comparable
interface…
The base idea for using mixins that way comes from qi4j [2]

[1] https://gist.github.com/4345897
[2] http://qi4j.org/

Am 20.12.12 11:57 schrieb "Pete Muir" unter <pmuir@redhat.com>:

>Interceptors don't matter, a service handler is essentially an
>interceptor already. Decorators would be nice, for sure, but I don't
>think this stops us implementing this feature.
>
>On 20 Dec 2012, at 10:06, Mark Struberg wrote:
>
>> 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
>>> 
>

Mime
View raw message