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 Wed, 07 Mar 2012 02:05:50 GMT
@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