deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler
Date Thu, 20 Dec 2012 00:44:03 GMT
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-servicehandler.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