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 00:25:08 GMT
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-servicehandler.html
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>>
Regards,
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>>
john
> > > >>> > >>>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>>>
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>>>
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>>
> > > >>> > >>>>>>>>
> > > >>> > >>>>>>>
> > > >>> > >>>>>
> > > >>> > >>
> > > >>> > >>
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

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