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 09:18:25 GMT
Two 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