Hi all,
So just to summarize the current proposal:
- Create a new annotation @ServiceHandlerBinding (in core/api) which will
be placed on on the interface that defines points of the
- Create a new annotation @ServiceHandler (in core/api) (I think based on
below this isn't needed since we have the interface now).
- Create an extension that can generate object proxies that link calls to
methods on the - org.apache.deltaspike.core.api....
Define the binding type annotation:
@ServiceHandlerBinding
@Qualifier
public @interface QueryHandler {
}
which will define the relationship between the interface/abstract class
that will use the service handler and the class that will serve as the
invocation handler.
For example, we can use @QueryHandler on an interface:
@QueryHandler
public interface PersonDAO {
//...
}
When the container finds this interface it will identify the appropriate
InvocationHandler, based on the following matches:
- Implements InvocationHandler
- Is annotated @QueryHandler
- Is annotated @ServiceHandler
DeltaSpike will provide a proxied object where all abstract method calls
are delegated to the InvocationHandler. The InvocationHandler will need to
have logic to handle all methods as defined within the class, as long as
that method is invoked through the InvocationHandler.
@QueryHandler @ServiceHandler
public QueryHandlerInvoker implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) {
if(method.getName().startsWith("find..."){
//...
}
return null;
}
}
In addition, the ServiceHandlerBinding can be placed on an abstract class.
In this case, only abstract methods will be passed to the
InvocationHandler.
@QueryHandler
public abstract interface PersonDAO {
public String doSomethingConcrete() {
return "concrete";
}
public abstract Person find(int id);
}
Only the find method will be wrapped, the method doSomethingConcrete will
be invoked directly. When interacting with an abstract class, the
InvocationHandler can call methods on the proxied object.
Finally, the app developer will be able to simply inject their
interface/abstract class in to their beans to perform work:
@Inject @QueryHandler PersonDAO dao;
Questions:
Should we provide a store (simple key/value map) to keep a history of found
object types and how they map?
Should we depend on certain libraries for proxying (e.g. javassist, I think
both Weld & OWB use this still?)
Since we now use the interface InvocationHandler should we rename the
binding to be InvocationHandlerBinding? I also think it's not necessary to
have @ServiceHandler since the marker interface now exists.
Comments welcome..
John
On Thu, Dec 20, 2012 at 12:33 PM, Jason Porter <[email protected]>wrote:
> +1 for @ServiceHandler
>
>
> On Thu, Dec 20, 2012 at 9:39 AM, John D. Ament <[email protected]
> >wrote:
>
> > If we're still calling the feature "ServiceHandler" then why not
> > @ServiceHandler?
> >
> >
> > On Thu, Dec 20, 2012 at 11:33 AM, Romain Manni-Bucau
> > <[email protected]>wrote:
> >
> > > if we don't need it perfect, if we need it we'll just use another name
> > > @DSHandler, @Handler...whatever it is ;)
> > >
> > > 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 Pete Muir <[email protected]>:
> > > > :-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
> > > >
> > > > On 20 Dec 2012, at 16:30, John D. Ament wrote:
> > > >
> > > >> The problem I have is that now InvocationHandler is both an
> interface
> > > and
> > > >> an @interface which will make it impossible for imports. I don't
> > think
> > > >> they should have the same name.
> > > >>
> > > >>
> > > >> On Thu, Dec 20, 2012 at 9:57 AM, Pete Muir <[email protected]>
> wrote:
> > > >>
> > > >>>
> > > >>> 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
> > > >>>> <[email protected]>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 <[email protected]>:
> > > >>>>>> 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
> > > >>>>>> <[email protected]>:
> > > >>>>>>
> > > >>>>>>> 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 <[email protected]>:
> > > >>>>>>>> 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 <[email protected]>
> > > >>>>>>>>> To: "[email protected]"
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>:
> > > >>>>>>>>>
> > > >>>>>>>>>> +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 <[email protected]>:
> > > >>>>>>>>>>> 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
> > > >>>>>>>>>>> <[email protected]>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 <
> > > >>>>>>>>>>>> [email protected]
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> hi john,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> as mentioned before we need the answers to the existing
> > > >>>>>>>>> questions.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2012/4/4 John D. Ament <[email protected]>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>>> [email protected]> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> 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" <
> > > >>>>>>>>>>>>>>> [email protected]>
> > > >>>>>>>>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>>>>>>> [email protected]
> > > >>>>>>>>>>>>>>>>>>>>>> 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" <
> > > >>>>>>>>>>>>>>>>>> [email protected]>
> > > >>>>>>>>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>>>>>>> [email protected]>
> > > >>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> To: [email protected]
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> 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 <[email protected]>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>> [email protected]
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> hi john,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> the sub-task is perfectly
> > > >>>>>>>>> fine.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> regards,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> gerhard
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> 2012/3/4 John D. Ament
> > > >>>>>>>>>>>> <[email protected]>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >
> > >
> >
>
>
>
> --
> 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
>
