On 20 Dec 2012, at 12:32, John D. Ament wrote:
> All,
>
> So mostly ok from my perspective. One thing to note:
>
> @InvocationHandlerBinding
> public @interface Repository {}
>
> @Repository
> public interface MyRepository {
> ...
> }
>
> @Repository @InvocationHandler
> public class MyInvocationHandler implements InvocationHandler {
> ...
> }
>
> Why do we have a @InvocationHandler here? Is it supposed to be
> @InvocationHandlerBinding instead? If so, is it really needed here?
No, it should be @InvocationHandler, it's analagous to @Interceptor. It's not
100% necessary as we already implement the interface, which is enough of the
marker.
>
> Thinking about the implementation for this, I think this actually becomes
> easier to use and easier to understand over the Solder solution. The
> implementation of the InvocationHandler becomes a true CDI bean.
>
> Should DS support Interceptors and Decorators on
> InvocationHandler beans?
>
> Do you mean the implementation class or the interface?
>
> John
>
>
> On Thu, Dec 20, 2012 at 7:06 AM, Romain Manni-Bucau
> <rmannibu...@gmail.com>wrote:
>
>> i'd rather say no because the idea is to ease "util" extension
>> writing. that's clearly not intended to be full business beans IMO (at
>> least for a first step)
>>
>> That's why i'd leave it as this for now
>>
>> wdyt?
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/20 Arne Limburg <arne.limb...@openknowledge.de>:
>>> Mark refers to my call stack.
>>>
>>> Out of the box this call stack would exist just in OWB, because Weld
>> would
>>> not apply any Interceptors or Decorators...
>>>
>>> The question is: Should DS support Interceptors and Decorators on
>>> InvocationHandler beans? My answer would be: yes, if our implementation
>>> shall be a preview of CDI-110.
>>> And that would make things complicated in the implementation...
>>>
>>> Am 20.12.12 12:11 schrieb "Romain Manni-Bucau" unter
>>> <rmannibu...@gmail.com>:
>>>
>>>> is it an issue for servicehandler? i don't think so
>>>>
>>>> it is often used to get util classes dynamically created, it is rarely
>>>> (i never saw it) decorated directly
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2012/12/20 Mark Struberg <strub...@yahoo.de>:
>>>>> we stumbled about this lately. It seems CDI only forces support for
>>>>> interceptors and decorators for CDI-annotated classes, but not for
>>>>> Bean<T> which get added via extensions nor even producer methods and
>>>>> fields :/
>>>>>
>>>>>
>>>>> Of course OWB does it, but it would be not portable...
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Arne Limburg <arne.limb...@openknowledge.de>
>>>>>> To: "deltaspike-dev@incubator.apache.org"
>>>>>> <deltaspike-dev@incubator.apache.org>
>>>>>> Cc:
>>>>>> Sent: Thursday, December 20, 2012 10:18 AM
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and Discuss
>>>>>> ServiceHandler
>>>>>>
>>>>>> T wo things about this: First: I don't like from the solder approach,
>>>>>> because the interface is annotated instead of the implementation.
>>>>>>
>>>>>> Second, if we implement this we should conceptually make clear how it
>>>>>> differentiates from Interceptors and Decorators. And personally I
>> think
>>>>>> this would work better with the InvocationHandler approach than with
>> an
>>>>>> approach that is very similar to interceptors.
>>>>>>
>>>>>> So +1 for an approach like this:
>>>>>>
>>>>>> @HandlesInvocationsOn(MyInterface.class)
>>>>>> public class MyInvocationHandler implements InvocationHandler {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> Technically we would register a custom Bean for every found
>>>>>> InvocationHandler with that annotation and take over the
>>>>>> interceptor-bindings from the interfaceŠ
>>>>>> So the invocation stack would be clear, too:
>>>>>> First Interceptors,
>>>>>> Second Decorators,
>>>>>> Third InvocationHandler
>>>>>>
>>>>>> Wdyt?
>>>>>>
>>>>>> Arne
>>>>>>
>>>>>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>>>>>> <rmannibu...@gmail.com>:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> that's a need, DS targets CDI 1.0 for now so just make this solder
>>>>>>> part portable ans it should be fine
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/12/20 Jason Porter <lightguard...@gmail.com>:
>>>>>>>> At this point, I'd say just do it as is in solder.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Dec 19, 2012 at 5:25 PM, John D. Ament
>>>>>>>> <john.d.am...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Regarding the two open questions:
>>>>>>>>>
>>>>>>>>> 1) the approach (including the name/s) we agree on will be used
>>>>>> also
>>>>>>>>> for
>>>>>>>>> cdi 1.1 (the only difference is the package)
>>>>>>>>> 2) the eg has a different opinion about it ->
>>>>>>>>>
>>>>>>>>> It looks like the JSR's answer
>>>>>>>>> (https://issues.jboss.org/browse/CDI-110 )
>>>>>>>>> is still unresolved - I'm not sure if we can get any further
>>>>>> answer at
>>>>>>>>> this
>>>>>>>>> time. The last posts on the subject seem to discuss using
>>>>>> something
>>>>>>>>> along
>>>>>>>>> the lines of an invocation handler, which I think would work well.
>>>>>>>>> Since
>>>>>>>>> we have some features coming up that are interested in having
>>>>>> service
>>>>>>>>> handlers available, do we
>>>>>>>>>
>>>>>>>>> 1. Implement as is, or similar to, what is currently in Solder?
>>>>>>>>> 2. Push EG on a resolution
>>>>>>>>> 3. Do it using invocation handlers.
>>>>>>>>> 4. Do it some other way?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 4, 2012 at 3:50 PM, Gerhard Petracek <
>>>>>>>>> gerhard.petra...@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> hi john,
>>>>>>>>>>
>>>>>>>>>> as mentioned before we need the answers to the existing
>>>>>> questions.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/4/4 John D. Ament <john.d.am...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> All,
>>>>>>>>>>>
>>>>>>>>>>> I kind of let this one and the other drop off my radar, I
>>>>>>>>> apologize.
>>>>>>>>> it
>>>>>>>>>>> looks like where we last left off, Gerhard was still
>>>>>> requesting
>>>>>>>>>> additional
>>>>>>>>>>> comments from everyone. Any other feedback?
>>>>>>>>>>>
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 12, 2012 at 1:06 PM, Gerhard Petracek <
>>>>>>>>>>> gerhard.petra...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> hi george,
>>>>>>>>>>>>
>>>>>>>>>>>> thx for the information. i thought there might be at
>>>>>> least some
>>>>>>>>>>> additional
>>>>>>>>>>>> answers/clarifications, since pete asked for them in
>>>>>> several
>>>>>>>>> comments.
>>>>>>>>>>>> -> imo we should continue with them.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> gerhard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/3/12 George Gastaldi
>>>>>> <gegasta...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Gerhard,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, it´s the last state. I know it´s quite
>>>>>> old, but I
>>>>>>>>> haven´t had
>>>>>>>>>>> time
>>>>>>>>>>>>> to work on it after that.
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> George
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/3/12 Gerhard Petracek
>>>>>> <gerhard.petra...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> hi george,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thx for the link.
>>>>>>>>>>>>>> i'm not sure if it is the latest state
>>>>>> of your discussion
>>>>>>>>> and/or
>>>>>>>>>> draft
>>>>>>>>>>>>>> (at least it's quite old already).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/3/7 George Gastaldi
>>>>>> <gegasta...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi !
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +1 to #1. I also agree that the term
>>>>>> "Service Handler" might
>>>>>>>>> not
>>>>>>>>> be
>>>>>>>>>>> so
>>>>>>>>>>>>>>> appropriate, so it should be discussed
>>>>>> as well.
>>>>>>>>>>>>>>> Here is the latest pull request with
>>>>>> some comments from Pete
>>>>>>>>> yet
>>>>>>>>> to
>>>>>>>>>>> be
>>>>>>>>>>>>>>> reviewed:
>>>>>> https://github.com/jboss/cdi/pull/28
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agreed :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> George is working on it for CDI
>>>>>> 1.1. George, can you share
>>>>>>>>> your
>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>> so far?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7 Mar 2012, at 17:05, Gerhard
>>>>>> Petracek wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> independent of my opinion
>>>>>> about the feature (which is
>>>>>>>>> still
>>>>>>>>>> +0):
>>>>>>>>>>>>>>>>> if it should be part of cdi
>>>>>> 1.1, we have the following
>>>>>>>>> options
>>>>>>>>>>> imo:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) the approach (including
>>>>>> the name/s) we agree on will
>>>>>>>>> be
>>>>>>>>> used
>>>>>>>>>>>> also
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> cdi 1.1 (the only difference
>>>>>> is the package)
>>>>>>>>>>>>>>>>> 2) the eg has a different
>>>>>> opinion about it ->
>>>>>>>>>>>>>>>>> 2a) the rest of the eg joins
>>>>>> this discussion
>>>>>>>>>>>>>>>>> 2b) we wait for the final
>>>>>> version and just allow the same
>>>>>>>>> with
>>>>>>>>>>> cdi
>>>>>>>>>>>>>>> 1.0
>>>>>>>>>>>>>>>>> 3) if the eg doesn't
>>>>>> agree on the idea, it should be
>>>>>>>>> re-visited
>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> deltaspike (if we really need
>>>>>> it)
>>>>>>>>>>>>>>>>> 4) we agree on it independent
>>>>>> of the result in cdi 1.1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1-3 is ok for me but -1 for
>>>>>> #4
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/3/7 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm not sure what you
>>>>>> mean by a "super interceptor",
>>>>>>>>> but if
>>>>>>>>>> you
>>>>>>>>>>>>>>> mean it
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>> in "super man"
>>>>>> (something better than an interceptor),
>>>>>>>>> then
>>>>>>>>> I
>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> disagree, it's
>>>>>> actually a specialised form of
>>>>>>>>> interceptor.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The best use case I know
>>>>>> of is the one John mentions -
>>>>>>>>>> creating
>>>>>>>>>>>> type
>>>>>>>>>>>>>>>> safe
>>>>>>>>>>>>>>>>>> references to queries:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @QueryService
>>>>>>>>>>>>>>>>>> interface UserQuery {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>> from User u")
>>>>>>>>>>>>>>>>>> public List<User>
>>>>>> getAllUsers();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Query("select u
>>>>>> from User u order by u.name")
>>>>>>>>>>>>>>>>>> public List<User>
>>>>>> getAllUsersSortedByName();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now, it may be the case
>>>>>> that there aren't any other use
>>>>>>>>> cases
>>>>>>>>>>> for
>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>> handlers, in which case
>>>>>> we should perhaps just offer
>>>>>>>>> this
>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>> service handler -
>>>>>> references to type safe queries - as I
>>>>>>>>> think
>>>>>>>>>>>> this
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> extremely powerful idea.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note, that at the moment
>>>>>> service handlers are scheduled
>>>>>>>>> for
>>>>>>>>>> CDI
>>>>>>>>>>>> 1.1.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7 Mar 2012, at 02:35,
>>>>>> Jason Porter wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Somewhat. I
>>>>>> wouldn't really think of them as overrides,
>>>>>>>>> they,
>>>>>>>>>>> to
>>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>> seem more like items to
>>>>>> do in addition to whatever the
>>>>>>>>>> original
>>>>>>>>>>>> impl
>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ServiceHandlers to me
>>>>>> seem more like super
>>>>>>>>> interceptors.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mar 6, 2012, at
>>>>>> 19:23, "John D. Ament" <
>>>>>>>>>>>> john.d.am...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @jason
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think the
>>>>>> concepts are very dissimilar.
>>>>>>>>> servicehandlers
>>>>>>>>>>>> create
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>> delegates are more like overrides and
>>>>>>>>> need
>>>>>>>>>> to
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>> the method
>>>>>> signature.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 6,
>>>>>> 2012 at 9:17 PM, Jason Porter <
>>>>>>>>>>>>>>> lightguard...@gmail.com
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think the
>>>>>> idea of ServiceHandlers are good, but,
>>>>>>>>> could
>>>>>>>>> we
>>>>>>>>>>> not
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> with
>>>>>> delegates?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sent from my
>>>>>> iPhone
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mar 6,
>>>>>> 2012, at 19:05, "John D. Ament" <
>>>>>>>>>>>>>>> john.d.am...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> @mark
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I
>>>>>> don't think it's a hard requirement for it to be
>>>>>>>>> on an
>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> One of
>>>>>> the best use-cases we built at my job is
>>>>>>>>> using it
>>>>>>>>>> for
>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>> PL/SQL.
>>>>>> The JDBC bindings do work, but not pretty.
>>>>>>>>> we
>>>>>>>>>> were
>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>>>>>> a fairly
>>>>>> clean wrapper API, generic enough for
>>>>>>>>> binding
>>>>>>>>>>> in/out
>>>>>>>>>>>>>>>>>> parameters.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> JOhn
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue,
>>>>>> Mar 6, 2012 at 12:58 PM, Mark Struberg <
>>>>>>>>>>>>>>> strub...@yahoo.de>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> actually I don't really see a real benefit. I just
>>>>>>>>> don't
>>>>>>>>>>> yet
>>>>>>>>>>>>>>> grok
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>> for real world projects.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why
>>>>>> would one intercept an Interface and delegate
>>>>>>>>> the
>>>>>>>>>> calls
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> handler?
>>>>>>>>>>>>>>>>>>>>>>> This
>>>>>> could be neat for mocking, but there are
>>>>>>>>> better
>>>>>>>>>>>>>>> frameworks for
>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -0.2
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> LieGrue,
>>>>>>>>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> From: Gerhard Petracek
>>>>>>>>> <gerhard.petra...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Sent: Tuesday, March 6, 2012 5:15 PM
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> Subject: Re: [DISCUSS] [DELTASPIKE-113] Review and
>>>>>>>>>> Discuss
>>>>>>>>>>>>>>>>>>>>>
>>>>>> ServiceHandler
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> if you have a lot of shared code, you can extract
>>>>>>>>> it
>>>>>>>>> in
>>>>>>>>>>> 1-n
>>>>>>>>>>>>>>>>>> method/s or
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> abstract class which is still easier than a new
>>>>>>>>> concept.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> at least i haven't seen an use-case which really
>>>>>>>>> needed
>>>>>>>>>>> it.
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> reason for a +0 (which still means that i'm ok
>>>>>>>>> with
>>>>>>>>>> adding
>>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> regards,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> gerhard
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> 2012/3/6 Pete Muir <pm...@redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you mean just write a bean with all the
>>>>>>>>> boilerplate
>>>>>>>>>>>> code
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6 Mar 2012, at 15:58, Gerhard Petracek
>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi pete,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> instead of the interface you can just
>>>>>> implement
>>>>>>>>> a
>>>>>>>>> bean
>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/3/6 Pete Muir
>>>>>> <pm...@redhat.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What CDI mechanism would you use
>>>>>> instead?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5 Mar 2012, at 08:47, Gerhard
>>>>>> Petracek
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> no -1 because there are
>>>>>> use-cases for it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> no +1 because i would use std.
>>>>>> cdi mechanisms
>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2012/3/4 Gerhard Petracek <
>>>>>>>>>> gerhard.petra...@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> hi john,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
>>>>>> fine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> gerhard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
>>>>>>>>> <john.d.am...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I wanted to bring up
>>>>>> the subject of
>>>>>>>>>> ServiceHandler.
>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> added 113 as a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> of DELTASPIKE-2, looked
>>>>>> appropriate but not
>>>>>>>>> 100%
>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> (so please let
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> know if you think
>>>>>> it's not appropriate as a
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> child). ServiceHandler
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> feature in Solder that
>>>>>> allows you to define
>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> manages
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> generic calls against
>>>>>> an injected interface.
>>>>>>>>> The
>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> is as follows:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -
>>>>>> @ServiceHandlerType(Class<?> clazz) -
>>>>>>>>> placed
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> on an annotation that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be placed on the
>>>>>> interface. Indicates what
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor would be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> invoked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> for calls against this
>>>>>> interface.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It's then up to the
>>>>>> application
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> developer/framework author to define
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> annotations that go on
>>>>>> methods, as well as
>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> interceptor itself
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be invoked. The
>>>>>> feature for ServiceHandler
>>>>>>>>> would
>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> to provide the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> API of
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> the type and then the
>>>>>> infrastructure
>>>>>>>>> required to
>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> the interceptor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> called. Existing
>>>>>> documentation of the
>>>>>>>>> feature:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-
>>>>>>>>> ser
>>>>>>>>> vicehandler.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> john
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jason Porter
>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>> http://twitter.com/lightguardjp
>>>>>>>>
>>>>>>>> Software Engineer
>>>>>>>> Open Source Advocate
>>>>>>>>
>>>>>>>> PGP key id: 926CCFF5
>>>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>
>>>
>>
