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?
Thinking about the implementation for this, I think this actually becomes
easier to use and easier to understand over the Solder solution. The
implementation of the InvocationHandler becomes a true CDI bean.
Should DS support Interceptors and Decorators on
InvocationHandler beans?
Do you mean the implementation class or the interface?
John
On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
<[email protected]>wrote:
> i'd rather say no because the idea is to ease "util" extension
> writing. that's clearly not intended to be full business beans IMO (at
> least for a first step)
>
> That's why i'd leave it as this for now
>
> wdyt?
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/20 Arne Limburg <[email protected]>:
> > Mark refers to my call stack.
> >
> > Out of the box this call stack would exist just in OWB, because Weld
> would
> > not apply any Interceptors or Decorators...
> >
> > The question is: Should DS support Interceptors and Decorators on
> > InvocationHandler beans? My answer would be: yes, if our implementation
> > shall be a preview of CDI-110.
> > And that would make things complicated in the implementation...
> >
> > Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
> > <[email protected]>:
> >
> >>is it an issue for servicehandler? i don't think so
> >>
> >>it is often used to get util classes dynamically created, it is rarely
> >>(i never saw it) decorated directly
> >>
> >>
> >>Romain Manni-Bucau
> >>Twitter: @rmannibucau
> >>Blog: http://rmannibucau.wordpress.com/
> >>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >>2012/12/20 Mark Struberg <[email protected]>:
> >>> we stumbled about this lately. It seems CDI only forces support for
> >>>interceptors and decorators for CDI-annotated classes, but not for
> >>>Bean<T> which get added via extensions nor even producer methods and
> >>>fields :/
> >>>
> >>>
> >>> Of course OWB does it, but it would be not portable...
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: Arne Limburg <[email protected]>
> >>>> To: "[email protected]"
> >>>><[email protected]>
> >>>> Cc:
> >>>> Sent: Thursday, December 20, 2012 10:18 AM
> >>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
> >>>>ServiceHandler
> >>>>
> >>>>T wo things about this: First: I don't like from the solder approach,
> >>>> because the interface is annotated instead of the implementation.
> >>>>
> >>>> Second, if we implement this we should conceptually make clear how it
> >>>> differentiates from Interceptors and Decorators. And personally I
> think
> >>>> this would work better with the InvocationHandler approach than with
> an
> >>>> approach that is very similar to interceptors.
> >>>>
> >>>> So +1 for an approach like this:
> >>>>
> >>>> @HandlesInvocationsOn(MyInterface.class)
> >>>> public class MyInvocationHandler implements InvocationHandler {
> >>>> ...
> >>>> }
> >>>>
> >>>> Technically we would register a custom Bean for every found
> >>>> InvocationHandler with that annotation and take over the
> >>>> interceptor-bindings from the interfaceŠ
> >>>> So the invocation stack would be clear, too:
> >>>> First Interceptors,
> >>>> Second Decorators,
> >>>> Third InvocationHandler
> >>>>
> >>>> Wdyt?
> >>>>
> >>>> Arne
> >>>>
> >>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
> >>>> <[email protected]>:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
> >>>>> part portable ans it should be fine
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> Twitter: @rmannibucau
> >>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>> Github: https://github.com/rmannibucau
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/12/20 Jason Porter <[email protected]>:
> >>>>>> At this point, I'd say just do it as is in solder.
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
> >>>>>> <[email protected]>wrote:
> >>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> Regarding the two open questions:
> >>>>>>>
> >>>>>>> 1) the approach (including the name/s) we agree on will be used
> >>>> also
> >>>>>>> for
> >>>>>>> cdi 1.1 (the only difference is the package)
> >>>>>>> 2) the eg has a different opinion about it ->
> >>>>>>>
> >>>>>>> It looks like the JSR's answer
> >>>>>>> (https://issues.jboss.org/browse/CDI-110 )
> >>>>>>> is still unresolved - I'm not sure if we can get any further
> >>>> answer at
> >>>>>>> this
> >>>>>>> time. The last posts on the subject seem to discuss using
> >>>> something
> >>>>>>> along
> >>>>>>> the lines of an invocation handler, which I think would work well.
> >>>>>>> Since
> >>>>>>> we have some features coming up that are interested in having
> >>>> service
> >>>>>>> handlers available, do we
> >>>>>>>
> >>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
> >>>>>>> 2. Push EG on a resolution
> >>>>>>> 3. Do it using invocation handlers.
> >>>>>>> 4. Do it some other way?
> >>>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
> >>>>>>> [email protected]
> >>>>>>> > wrote:
> >>>>>>>
> >>>>>>> > hi john,
> >>>>>>> >
> >>>>>>> > as mentioned before we need the answers to the existing
> >>>> questions.
> >>>>>>> >
> >>>>>>> > regards,
> >>>>>>> > gerhard
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > 2012/4/4 John D. Ament <[email protected]>
> >>>>>>> >
> >>>>>>> > > All,
> >>>>>>> > >
> >>>>>>> > > I kind of let this one and the other drop off my radar, I
> >>>>>>> apologize.
> >>>>>>> it
> >>>>>>> > > looks like where we last left off, Gerhard was still
> >>>> requesting
> >>>>>>> > additional
> >>>>>>> > > comments from everyone. Any other feedback?
> >>>>>>> > >
> >>>>>>> > > John
> >>>>>>> > >
> >>>>>>> > > On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
> >>>>>>> > > [email protected]> wrote:
> >>>>>>> > >
> >>>>>>> > > > hi george,
> >>>>>>> > > >
> >>>>>>> > > > thx for the information. i thought there might be at
> >>>> least some
> >>>>>>> > > additional
> >>>>>>> > > > answers/clarifications, since pete asked for them in
> >>>> several
> >>>>>>> comments.
> >>>>>>> > > > -> imo we should continue with them.
> >>>>>>> > > >
> >>>>>>> > > > regards,
> >>>>>>> > > > gerhard
> >>>>>>> > > >
> >>>>>>> > > >
> >>>>>>> > > >
> >>>>>>> > > > 2012/3/12 George Gastaldi
> >>>> <[email protected]>
> >>>>>>> > > >
> >>>>>>> > > > > Hello Gerhard,
> >>>>>>> > > > >
> >>>>>>> > > > > Yeah, it´s the last state. I know it´s quite
> >>>> old, but I
> >>>>>>> haven´t had
> >>>>>>> > > time
> >>>>>>> > > > > to work on it after that.
> >>>>>>> > > > > Regards,
> >>>>>>> > > > >
> >>>>>>> > > > > George
> >>>>>>> > > > >
> >>>>>>> > > > >
> >>>>>>> > > > > 2012/3/12 Gerhard Petracek
> >>>> <[email protected]>
> >>>>>>> > > > >
> >>>>>>> > > > >> hi george,
> >>>>>>> > > > >>
> >>>>>>> > > > >> thx for the link.
> >>>>>>> > > > >> i'm not sure if it is the latest state
> >>>> of your discussion
> >>>>>>> and/or
> >>>>>>> > draft
> >>>>>>> > > > >> (at least it's quite old already).
> >>>>>>> > > > >>
> >>>>>>> > > > >> regards,
> >>>>>>> > > > >> gerhard
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >> 2012/3/7 George Gastaldi
> >>>> <[email protected]>
> >>>>>>> > > > >>
> >>>>>>> > > > >>> Hi !
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> +1 to #1. I also agree that the term
> >>>> "Service Handler" might
> >>>>>>> not
> >>>>>>> be
> >>>>>>> > > so
> >>>>>>> > > > >>> appropriate, so it should be discussed
> >>>> as well.
> >>>>>>> > > > >>> Here is the latest pull request with
> >>>> some comments from Pete
> >>>>>>> yet
> >>>>>>> to
> >>>>>>> > > be
> >>>>>>> > > > >>> reviewed:
> >>>> https://github.com/jboss/cdi/pull/28
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> 2012/3/7 Pete Muir
> >>>> <[email protected]>
> >>>>>>> > > > >>>
> >>>>>>> > > > >>> > Agreed :-)
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > George is working on it for CDI
> >>>> 1.1. George, can you share
> >>>>>>> your
> >>>>>>> > > > >>> proposal
> >>>>>>> > > > >>> > so far?
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > On 7 Mar 2012, at 17:05, Gerhard
> >>>> Petracek wrote:
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> > > hi pete,
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > independent of my opinion
> >>>> about the feature (which is
> >>>>>>> still
> >>>>>>> > +0):
> >>>>>>> > > > >>> > > if it should be part of cdi
> >>>> 1.1, we have the following
> >>>>>>> options
> >>>>>>> > > imo:
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 1) the approach (including
> >>>> the name/s) we agree on will
> >>>>>>> be
> >>>>>>> used
> >>>>>>> > > > also
> >>>>>>> > > > >>> for
> >>>>>>> > > > >>> > > cdi 1.1 (the only difference
> >>>> is the package)
> >>>>>>> > > > >>> > > 2) the eg has a different
> >>>> opinion about it ->
> >>>>>>> > > > >>> > > 2a) the rest of the eg joins
> >>>> this discussion
> >>>>>>> > > > >>> > > 2b) we wait for the final
> >>>> version and just allow the same
> >>>>>>> with
> >>>>>>> > > cdi
> >>>>>>> > > > >>> 1.0
> >>>>>>> > > > >>> > > 3) if the eg doesn't
> >>>> agree on the idea, it should be
> >>>>>>> re-visited
> >>>>>>> > > for
> >>>>>>> > > > >>> > > deltaspike (if we really need
> >>>> it)
> >>>>>>> > > > >>> > > 4) we agree on it independent
> >>>> of the result in cdi 1.1
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 1-3 is ok for me but -1 for
> >>>> #4
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > regards,
> >>>>>>> > > > >>> > > gerhard
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > > 2012/3/7 Pete Muir
> >>>> <[email protected]>
> >>>>>>> > > > >>> > >
> >>>>>>> > > > >>> > >> I'm not sure what you
> >>>> mean by a "super interceptor",
> >>>>>>> but if
> >>>>>>> > you
> >>>>>>> > > > >>> mean it
> >>>>>>> > > > >>> > as
> >>>>>>> > > > >>> > >> in "super man"
> >>>> (something better than an interceptor),
> >>>>>>> then
> >>>>>>> I
> >>>>>>> > > > would
> >>>>>>> > > > >>> > >> disagree, it's
> >>>> actually a specialised form of
> >>>>>>> interceptor.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> The best use case I know
> >>>> of is the one John mentions -
> >>>>>>> > creating
> >>>>>>> > > > type
> >>>>>>> > > > >>> > safe
> >>>>>>> > > > >>> > >> references to queries:
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @QueryService
> >>>>>>> > > > >>> > >> interface UserQuery {
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @Query("select u
> >>>> from User u")
> >>>>>>> > > > >>> > >> public List<User>
> >>>> getAllUsers();
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> @Query("select u
> >>>> from User u order by u.name")
> >>>>>>> > > > >>> > >> public List<User>
> >>>> getAllUsersSortedByName();
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> }
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> Now, it may be the case
> >>>> that there aren't any other use
> >>>>>>> cases
> >>>>>>> > > for
> >>>>>>> > > > >>> > service
> >>>>>>> > > > >>> > >> handlers, in which case
> >>>> we should perhaps just offer
> >>>>>>> this
> >>>>>>> > > > particular
> >>>>>>> > > > >>> > >> service handler -
> >>>> references to type safe queries - as I
> >>>>>>> think
> >>>>>>> > > > this
> >>>>>>> > > > >>> is
> >>>>>>> > > > >>> > an
> >>>>>>> > > > >>> > >> extremely powerful idea.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> Note, that at the moment
> >>>> service handlers are scheduled
> >>>>>>> for
> >>>>>>> > CDI
> >>>>>>> > > > 1.1.
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >> On 7 Mar 2012, at 02:35,
> >>>> Jason Porter wrote:
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>> Somewhat. I
> >>>> wouldn't really think of them as overrides,
> >>>>>>> they,
> >>>>>>> > > to
> >>>>>>> > > > >>> me,
> >>>>>>> > > > >>> > >> seem more like items to
> >>>> do in addition to whatever the
> >>>>>>> > original
> >>>>>>> > > > impl
> >>>>>>> > > > >>> > does.
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> ServiceHandlers to me
> >>>> seem more like super
> >>>>>>> interceptors.
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> Sent from my iPhone
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>> On Mar 6, 2012, at
> >>>> 19:23, "John D. Ament" <
> >>>>>>> > > > [email protected]>
> >>>>>>> > > > >>> > >> wrote:
> >>>>>>> > > > >>> > >>>
> >>>>>>> > > > >>> > >>>> @jason
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>> I think the
> >>>> concepts are very dissimilar.
> >>>>>>> servicehandlers
> >>>>>>> > > > create
> >>>>>>> > > > >>> the
> >>>>>>> > > > >>> > >>>> implementation.
> >>>> delegates are more like overrides and
> >>>>>>> need
> >>>>>>> > to
> >>>>>>> > > > >>> know
> >>>>>>> > > > >>> > >> about
> >>>>>>> > > > >>> > >>>> the method
> >>>> signature.
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>> On Tue, Mar 6,
> >>>> 2012 at 9:17 PM, Jason Porter <
> >>>>>>> > > > >>> [email protected]
> >>>>>>> > > > >>> > >>> wrote:
> >>>>>>> > > > >>> > >>>>
> >>>>>>> > > > >>> > >>>>> I think the
> >>>> idea of ServiceHandlers are good, but,
> >>>>>>> could
> >>>>>>> we
> >>>>>>> > > not
> >>>>>>> > > > >>> do
> >>>>>>> > > > >>> > this
> >>>>>>> > > > >>> > >>>>> with
> >>>> delegates?
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>> Sent from my
> >>>> iPhone
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>> On Mar 6,
> >>>> 2012, at 19:05, "John D. Ament" <
> >>>>>>> > > > >>> [email protected]>
> >>>>>>> > > > >>> > >> wrote:
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>>>>> @mark
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> I
> >>>> don't think it's a hard requirement for it to be
> >>>>>>> on an
> >>>>>>> > > > >>> interface.
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> One of
> >>>> the best use-cases we built at my job is
> >>>>>>> using it
> >>>>>>> > for
> >>>>>>> > > > >>> calling
> >>>>>>> > > > >>> > >>>>>> PL/SQL.
> >>>> The JDBC bindings do work, but not pretty.
> >>>>>>> we
> >>>>>>> > were
> >>>>>>> > > > >>> able to
> >>>>>>> > > > >>> > >>>>> create
> >>>>>>> > > > >>> > >>>>>> a fairly
> >>>> clean wrapper API, generic enough for
> >>>>>>> binding
> >>>>>>> > > in/out
> >>>>>>> > > > >>> > >> parameters.
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> JOhn
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>> On Tue,
> >>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
> >>>>>>> > > > >>> [email protected]>
> >>>>>>> > > > >>> > >>>>> wrote:
> >>>>>>> > > > >>> > >>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>> actually I don't really see a real benefit. I just
> >>>>>>> don't
> >>>>>>> > > yet
> >>>>>>> > > > >>> grok
> >>>>>>> > > > >>> > the
> >>>>>>> > > > >>> > >>>>> use
> >>>>>>> > > > >>> > >>>>>>> case
> >>>> for real world projects.
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> Why
> >>>> would one intercept an Interface and delegate
> >>>>>>> the
> >>>>>>> > calls
> >>>>>>> > > > to
> >>>>>>> > > > >>> a
> >>>>>>> > > > >>> > >> method
> >>>>>>> > > > >>> > >>>>>>>
> >>>> handler?
> >>>>>>> > > > >>> > >>>>>>> This
> >>>> could be neat for mocking, but there are
> >>>>>>> better
> >>>>>>> > > > >>> frameworks for
> >>>>>>> > > > >>> > >>>>> that.
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> thus
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> -0.2
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>> LieGrue,
> >>>>>>> > > > >>> > >>>>>>> strub
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>>> -----
> >>>> Original Message -----
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> From: Gerhard Petracek
> >>>>>>> <[email protected]>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> To: [email protected]
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Cc:
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Sent: Tuesday, March 6, 2012 5:15 PM
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
> >>>>>>> > Discuss
> >>>>>>> > > > >>> > >>>>>
> >>>> ServiceHandler
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> if you have a lot of shared code, you can extract
> >>>>>>> it
> >>>>>>> in
> >>>>>>> > > 1-n
> >>>>>>> > > > >>> > >> method/s or
> >>>>>>> > > > >>> > >>>>>>> an
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> abstract class which is still easier than a new
> >>>>>>> concept.
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> at least i haven't seen an use-case which really
> >>>>>>> needed
> >>>>>>> > > it.
> >>>>>>> > > > >>> that
> >>>>>>> > > > >>> > was
> >>>>>>> > > > >>> > >>>>> the
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> reason for a +0 (which still means that i'm ok
> >>>>>>> with
> >>>>>>> > adding
> >>>>>>> > > > >>> it).
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> regards,
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> gerhard
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> 2012/3/6 Pete Muir <[email protected]>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> So, you mean just write a bean with all the
> >>>>>>> boilerplate
> >>>>>>> > > > code
> >>>>>>> > > > >>> in
> >>>>>>> > > > >>> > it?
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
> >>>> wrote:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> hi pete,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> instead of the interface you can just
> >>>> implement
> >>>>>>> a
> >>>>>>> bean
> >>>>>>> > > > which
> >>>>>>> > > > >>> > does
> >>>>>>> > > > >>> > >> the
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> same.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>> 2012/3/6 Pete Muir
> >>>> <[email protected]>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> What CDI mechanism would you use
> >>>> instead?
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
> >>>> Petracek
> >>>>>>> wrote:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> +0
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> no -1 because there are
> >>>> use-cases for it.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> no +1 because i would use std.
> >>>> cdi mechanisms
> >>>>>>> > instead.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
> >>>>>>> > [email protected]
> >>>>>>> > > >
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> hi john,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> the sub-task is perfectly
> >>>> fine.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> gerhard
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> >>>>>>> <[email protected]>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>> Hi All
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> I wanted to bring up
> >>>> the subject of
> >>>>>>> > ServiceHandler.
> >>>>>>> > > I
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> added 113 as a
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> child
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
> >>>> appropriate but not
> >>>>>>> 100%
> >>>>>>> > > sure
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> (so please let
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> me
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> know if you think
> >>>> it's not appropriate as a
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> child). ServiceHandler
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> is
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> a
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> feature in Solder that
> >>>> allows you to define
> >>>>>>> an
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> manages
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> generic calls against
> >>>> an injected interface.
> >>>>>>> The
> >>>>>>> > > API
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> is as follows:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> -
> >>>> @ServiceHandlerType(Class<?> clazz) -
> >>>>>>> placed
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> on an annotation that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> would
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> be placed on the
> >>>> interface. Indicates what
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor would be
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> invoked
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> for calls against this
> >>>> interface.
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> It's then up to the
> >>>> application
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> developer/framework author to define
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> annotations that go on
> >>>> methods, as well as
> >>>>>>> the
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> interceptor itself
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>> that
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> will
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> be invoked. The
> >>>> feature for ServiceHandler
> >>>>>>> would
> >>>>>>> > be
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> to provide the
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> API of
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> the type and then the
> >>>> infrastructure
> >>>>>>> required to
> >>>>>>> > > make
> >>>>>>> > > > >>> > >>>>>>>>
> >>>> the interceptor
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>> be
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> called. Existing
> >>>> documentation of the
> >>>>>>> feature:
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>>
> >>>>>>> > > >
> >>>>>>> > >
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
> >>>>>>>ser
> >>>>>>> vicehandler.html
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> Regards,
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>> john
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> >
> >>>>>>>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>>
> >>>>>>> > > > >>> > >>>>>>>
> >>>>>>> > > > >>> > >>>>>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> > >>
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>> >
> >>>>>>> > > > >>>
> >>>>>>> > > > >>
> >>>>>>> > > > >>
> >>>>>>> > > > >
> >>>>>>> > > >
> >>>>>>> > >
> >>>>>>> >
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jason Porter
> >>>>>> http://lightguard-jp.blogspot.com
> >>>>>> http://twitter.com/lightguardjp
> >>>>>>
> >>>>>> Software Engineer
> >>>>>> Open Source Advocate
> >>>>>>
> >>>>>> PGP key id: 926CCFF5
> >>>>>> PGP key available at: keyserver.net, pgp.mit.edu
> >>>>
> >
>
