deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 20 Dec 2012 12:32:39 GMT
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
<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
> >>>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message