That was my first idea, however thinking about it, that wouldn't be much
CDI-like ;-)
So we would introduce a @InvocationHandlerBinding meta-annotation?
Like:
@InvocationHandlerBinding
public @interface Repository {}
@Repository
public interface MyRepository {
...
}
@Repository @InvocationHandler
public class MyInvocationHandler implements InvocationHandler {
...
}
Looks much better, I think...
Am 20.12.12 10:24 schrieb "Romain Manni-Bucau" unter
<[email protected]>:
>sounds *almost* fine for me
>
>@Arne: maybe i got it wrong: you link a handler with an interface?
>
>what is nice with the annotation API is the handler doesn't know about
>the interface it proxies
>
>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]>:
>> Two things about this: First: I don't like from the solder approach,
>> because the interface is annotated instead of the implementation.
>>
>> Second, if we implement this we should conceptually make clear how it
>> differentiates from Interceptors and Decorators. And personally I think
>> this would work better with the InvocationHandler approach than with an
>> approach that is very similar to interceptors.
>>
>> So +1 for an approach like this:
>>
>> @HandlesInvocationsOn(MyInterface.class)
>> public class MyInvocationHandler implements InvocationHandler {
>> ...
>> }
>>
>> Technically we would register a custom Bean for every found
>> InvocationHandler with that annotation and take over the
>> interceptor-bindings from the interfaceŠ
>> So the invocation stack would be clear, too:
>> First Interceptors,
>> Second Decorators,
>> Third InvocationHandler
>>
>> Wdyt?
>>
>> Arne
>>
>> Am 20.12.12 01:53 schrieb "Romain Manni-Bucau" unter
>> <[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-s
>>>>>er
>>>>>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
>>
