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 >>
