Interceptors don't matter, a service handler is essentially an interceptor already. Decorators would be nice, for sure, but I don't think this stops us implementing this feature.
On 20 Dec 2012, at 10:06, Mark Struberg wrote: > 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 >>
