[DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

john.d.ament
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
hi john,

the sub-task is perfectly fine.

regards,
gerhard



2012/3/4 John D. Ament <[hidden email]>

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
+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 <[hidden email]>

> hi john,
>
> the sub-task is perfectly fine.
>
> regards,
> gerhard
>
>
>
> 2012/3/4 John D. Ament <[hidden email]>
>
> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Pete Muir
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 <[hidden email]>
>
>> hi john,
>>
>> the sub-task is perfectly fine.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/3/4 John D. Ament <[hidden email]>
>>
>> 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
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
hi pete,

instead of the interface you can just implement a bean which does the same.

regards,
gerhard



2012/3/6 Pete Muir <[hidden email]>

> 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 <[hidden email]>
> >
> >> hi john,
> >>
> >> the sub-task is perfectly fine.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/3/4 John D. Ament <[hidden email]>
> >>
> >> 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
> >>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Pete Muir
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 <[hidden email]>
>
>> 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 <[hidden email]>
>>>
>>>> hi john,
>>>>
>>>> the sub-task is perfectly fine.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2012/3/4 John D. Ament <[hidden email]>
>>>>
>>>> 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
>>>>>
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
> >
> >> 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 <[hidden email]>
> >>>
> >>>> hi john,
> >>>>
> >>>> the sub-task is perfectly fine.
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2012/3/4 John D. Ament <[hidden email]>
> >>>>
> >>>> 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
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>
>>  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 <[hidden email]>
>>  >
>>  >> 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 <[hidden email]>
>>  >>>
>>  >>>> hi john,
>>  >>>>
>>  >>>> the sub-task is perfectly fine.
>>  >>>>
>>  >>>> regards,
>>  >>>> gerhard
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>> 2012/3/4 John D. Ament <[hidden email]>
>>  >>>>
>>  >>>> 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
>>  >>>>>
>>  >>>>
>>  >>>>
>>  >>
>>  >>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

john.d.ament
@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 <[hidden email]> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >
> >>  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 <[hidden email]>
> >>  >
> >>  >> 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 <[hidden email]>
> >>  >>>
> >>  >>>> hi john,
> >>  >>>>
> >>  >>>> the sub-task is perfectly fine.
> >>  >>>>
> >>  >>>> regards,
> >>  >>>> gerhard
> >>  >>>>
> >>  >>>>
> >>  >>>>
> >>  >>>> 2012/3/4 John D. Ament <[hidden email]>
> >>  >>>>
> >>  >>>> 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
> >>  >>>>>
> >>  >>>>
> >>  >>>>
> >>  >>
> >>  >>
> >>
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Jason Porter
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>
>>>> 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 <[hidden email]>
>>>>>
>>>>>> 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 <[hidden email]>
>>>>>>>
>>>>>>>> hi john,
>>>>>>>>
>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

john.d.ament
@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 <[hidden email]>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" <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> >>> To: [hidden email]
> >>> 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 <[hidden email]>
> >>>
> >>>> 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 <[hidden email]>
> >>>>>
> >>>>>> 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 <[hidden email]>
> >>>>>>>
> >>>>>>>> hi john,
> >>>>>>>>
> >>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>> gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Jason Porter
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" <[hidden email]> 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 <[hidden email]>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" <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>
>>>>>> 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 <[hidden email]>
>>>>>>>
>>>>>>>> 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 <[hidden email]>
>>>>>>>>>
>>>>>>>>>> hi john,
>>>>>>>>>>
>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Marius Bogoevici
On 12-03-06 9:35 PM, 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.
I'd rather think of mixins.

>
> Sent from my iPhone
>
> On Mar 6, 2012, at 19:23, "John D. Ament"<[hidden email]>  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<[hidden email]>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"<[hidden email]>  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<[hidden email]>
>>> 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<[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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<[hidden email]>
>>>>>>
>>>>>>> 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<[hidden email]>
>>>>>>>>
>>>>>>>>> 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<[hidden email]>
>>>>>>>>>>
>>>>>>>>>>> hi john,
>>>>>>>>>>>
>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/4 John D. Ament<[hidden email]>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Pete Muir
In reply to this post by Jason Porter
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" <[hidden email]> 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 <[hidden email]>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" <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>>
>>>>>>> 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 <[hidden email]>
>>>>>>>>
>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>>
>>>>>>>>>>> hi john,
>>>>>>>>>>>
>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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" <[hidden email]>
> 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 <[hidden email]
> >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" <[hidden email]>
> 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 <[hidden email]>
> >>> 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 <[hidden email]>
> >>>>>> To: [hidden email]
> >>>>>> 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 <[hidden email]>
> >>>>>>
> >>>>>>> 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 <[hidden email]>
> >>>>>>>>
> >>>>>>>>> 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 <[hidden email]>
> >>>>>>>>>>
> >>>>>>>>>>> hi john,
> >>>>>>>>>>>
> >>>>>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>>>>
> >>>>>>>>>>> regards,
> >>>>>>>>>>> gerhard
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
> >>>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Pete Muir
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 <[hidden email]>
>
>> 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" <[hidden email]>
>> 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 <[hidden email]
>>> 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" <[hidden email]>
>> 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 <[hidden email]>
>>>>> 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 <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> 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 <[hidden email]>
>>>>>>>>
>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>>
>>>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>>>>
>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>
>>>>>>>>>>>>> the sub-task is perfectly fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

George Gastaldi
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 <[hidden email]>

> 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 <[hidden email]>
> >
> >> 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" <[hidden email]>
> >> 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 <[hidden email]
> >>> 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" <[hidden email]>
> >> 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 <[hidden email]>
> >>>>> 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 <[hidden email]>
> >>>>>>>> To: [hidden email]
> >>>>>>>> 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 <[hidden email]>
> >>>>>>>>
> >>>>>>>>> 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 <[hidden email]>
> >>>>>>>>>>
> >>>>>>>>>>> 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 <[hidden email]>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> hi john,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the sub-task is perfectly fine.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> regards,
> >>>>>>>>>>>>> gerhard
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
>
> > 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 <[hidden email]>
> > >
> > >> 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" <[hidden email]>
> > >> 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 <
> [hidden email]
> > >>> 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" <[hidden email]>
> > >> 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 <[hidden email]
> >
> > >>>>> 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 <[hidden email]>
> > >>>>>>>> To: [hidden email]
> > >>>>>>>> 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 <[hidden email]>
> > >>>>>>>>
> > >>>>>>>>> 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 <[hidden email]>
> > >>>>>>>>>>
> > >>>>>>>>>>> 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 <[hidden email]>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> hi john,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> the sub-task is perfectly fine.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>> gerhard
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>
> > >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

George Gastaldi
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 <[hidden email]>

> 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 <[hidden email]>
>
>> 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 <[hidden email]>
>>
>> > 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 <[hidden email]>
>> > >
>> > >> 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" <[hidden email]>
>> > >> 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 <
>> [hidden email]
>> > >>> 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" <[hidden email]
>> >
>> > >> 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 <
>> [hidden email]>
>> > >>>>> 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 <[hidden email]>
>> > >>>>>>>> To: [hidden email]
>> > >>>>>>>> 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 <[hidden email]>
>> > >>>>>>>>
>> > >>>>>>>>> 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 <[hidden email]>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> 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 <[hidden email]>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>> hi john,
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> regards,
>> > >>>>>>>>>>>>> gerhard
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> 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
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>
>> > >>
>> > >>
>> >
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss ServiceHandler

Gerhard Petracek
Administrator
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 <[hidden email]>

> 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 <[hidden email]>
>
>> 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 <[hidden email]>
>>
>>> 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 <[hidden email]>
>>>
>>> > 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 <[hidden email]>
>>> > >
>>> > >> 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" <[hidden email]>
>>> > >> 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 <
>>> [hidden email]
>>> > >>> 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" <
>>> [hidden email]>
>>> > >> 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 <
>>> [hidden email]>
>>> > >>>>> 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 <[hidden email]>
>>> > >>>>>>>> To: [hidden email]
>>> > >>>>>>>> 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 <[hidden email]>
>>> > >>>>>>>>
>>> > >>>>>>>>> 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 <[hidden email]>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> 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 <[hidden email]>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>> hi john,
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> the sub-task is perfectly fine.
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> regards,
>>> > >>>>>>>>>>>>> gerhard
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> 2012/3/4 John D. Ament <[hidden email]>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> 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
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>
>>> > >>>>>
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>
>>
>
1234