+1 SecuresOnReturn or maybe SecuresAfterReturn -1 SecuresReturn. Just looking at it makes it seem like they're going be securing the returned value which is certainly not the case. Also it doesn't makes if you put it on a void method
Sent from my iPhone On Dec 15, 2012, at 14:29, Gerhard Petracek <[email protected]> wrote: > +1 for @SecuredOnReturn or @SecuredResult as an additional annotation (-> > no api changes for @Secures). > > regards, > gerhard > > > > 2012/12/15 Arne Limburg <[email protected]> > >> I've updated the gist [1] (see ReadingAuthorizer0) to see how it works out. >> If we leave out the "on", then it would even read better. You could read >> the method call like a sentence: >> >> public boolean isAllowedToRead(@SecuredReturn Address a... >> >> >> >> So +1 for @SecuredReturn from me >> >> >> [1] https://gist.github.com/4279323 >> >> >> >> Am 15.12.12 21:59 schrieb "Romain Manni-Bucau" unter >> <[email protected]>: >> >>> and the secure one too so it is not ambigous +1 for this one >>> >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> >>> 2012/12/15 Arne Limburg <[email protected]>: >>>> You mean to the second list? >>>> I like that, because it contains the java keyword "return" >>>> With this I would feel comfortable with 1.C >>>> >>>> What do the others think? >>>> >>>> >>>> Am 15.12.12 21:51 schrieb "Gerhard Petracek" unter >>>> <[email protected]>: >>>> >>>>> we could add @SecuredOnReturn to the list. >>>>> >>>>> regards, >>>>> gerhard >>>>> >>>>> >>>>> >>>>> 2012/12/15 Arne Limburg <[email protected]> >>>>> >>>>>> I am also not happy with that name. >>>>>> >>>>>> So we have to decide about two annotations >>>>>> 1. The method-level annotation of the authorizer method: >>>>>> A. @Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) >>>>>> B. @Secures and @SecuresResult >>>>>> C. @Secures for both (pre- and post method-invocation authorization, >>>>>> distinguishing by the existence of the parameter-level annotation) >>>>>> 2. The parameter-level annotation of the injected result (something >>>>>> like a >>>>>> qualifier for the result of the business-method invocation) >>>>>> A. @Result >>>>>> B. @SecuredResult >>>>>> C. Other proposals? >>>>>> >>>>>> And we should consider both together, i.e. The word "Result" in the >>>>>> method-level annotation AND the parameter-level annotation looks ugly. >>>>>> >>>>>> Cheers, >>>>>> Arne >>>>>> >>>>>> Am 14.12.12 18:15 schrieb "Gerhard Petracek" unter >>>>>> <[email protected]>: >>>>>> >>>>>>> -1 for @Result (as a name), because the name is too generic. >>>>>>> >>>>>>> regards, >>>>>>> gerhard >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/12/14 Arne Limburg <[email protected]> >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> I have done the coding and we just need to agree on the names of >>>>>> the >>>>>>>> annotations. >>>>>>>> Looking at the gist I have no strong opinion on one of the >>>>>> solutions. >>>>>>>> However I like the @Secures(AFTER_INVOCATION) a little more because >>>>>> of >>>>>>>> to >>>>>>>> things: >>>>>>>> First it is symmetric to @Secures(BEFORE_INVOCATION) and second the >>>>>>>> other >>>>>>>> solution has the word "Result" twice in the declaration: once in >>>>>> the >>>>>>>> method annotation and once in the parameter annotation. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Arne >>>>>>>> >>>>>>>> Am 13.12.12 21:09 schrieb "Arne Limburg" unter >>>>>>>> <[email protected]>: >>>>>>>> >>>>>>>>> Hi Mark, >>>>>>>>> >>>>>>>>> I have coded a gist to lookup an address from an entityManager >>>>>> (see >>>>>>>> [1]) >>>>>>>>> using the groups suggested by Rudy: >>>>>>>>> >>>>>>>>> group1 (in my case users with role "guest") -> no access at all >>>>>>>>> group2 (in my case the owner of the address) -> has access but >>>>>> only >>>>>> to >>>>>>>> a >>>>>>>>> limited set of result types (access to his addresses) >>>>>>>>> group3 (in my case users with role "admin") -> has access and can >>>>>> see >>>>>>>> all >>>>>>>>> result >>>>>>>>> >>>>>>>>> I have coded the authorizer twice once using >>>>>> @Secures(AFTER_INVOCATION) >>>>>>>>> and once using @SecuresResult. >>>>>>>>> I think it is obvious that we need just one interceptor (for the >>>>>> custom >>>>>>>>> security annotation @Read) >>>>>>>>> and it should be obvious, too, that it makes no sense to annotate >>>>>> one >>>>>>>> of >>>>>>>>> the authorizer methods with both @Secures and @SecuresResult >>>>>>>>> >>>>>>>>> Hope that helps, >>>>>>>>> Arne >>>>>>>>> >>>>>>>>> [1] https://gist.github.com/4279323 >>>>>>>>> >>>>>>>>> Am 13.12.12 19:27 schrieb "Mark Struberg" unter >>>>>> <[email protected]>: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Could be helpful if we gather some samples in a gist? >>>>>>>>>> >>>>>>>>>> It seems that I have a different understanding about it's usage >>>>>> than >>>>>>>> Arne >>>>>>>>>> (which is much more into it). Arnes argument sounded well funded, >>>>>> but >>>>>>>>>> this excesses my knowledge right now. >>>>>>>>>> >>>>>>>>>> It basically boils down to >>>>>>>>>> >>>>>>>>>> 1. does it make sense to have both annotations on the same >>>>>> method? >>>>>>>>>> 2. will the stuff get handled by the same interceptor? (well, we >>>>>> will >>>>>>>>>> anyway do the @Dependent InterceptorStrategy trick for it I >>>>>> guess, >>>>>> so >>>>>>>> no >>>>>>>>>> real problem) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: Jason Porter <[email protected]> >>>>>>>>>>> To: "[email protected]" >>>>>>>>>>> <[email protected]>; Mark Struberg >>>>>>>> <[email protected] >>>>>>>>> >>>>>>>>>>> Cc: >>>>>>>>>>> Sent: Thursday, December 13, 2012 6:32 PM >>>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-298 support >>>>>>>> post-method-authorization >>>>>>>>>>> >>>>>>>>>>> +1 to Mark's names >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 13, 2012 at 4:13 AM, Mark Struberg >>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> what about @Secures and @SecuresResult? >>>>>>>>>>>> >>>>>>>>>>>> These are 2 different inteceptors, right? >>>>>>>>>>>> >>>>>>>>>>>> A method could also have both >>>>>>>>>>>> >>>>>>>>>>>> @Secures and >>>>>>>>>>>> >>>>>>>>>>>> @SecuresResult >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>>> ________________________________ >>>>>>>>>>>>> From: Arne Limburg <[email protected]> >>>>>>>>>>>>> To: "[email protected]" < >>>>>>>>>>>> [email protected]> >>>>>>>>>>>>> Sent: Thursday, December 13, 2012 12:11 PM >>>>>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-298 support >>>>>>>>>>>> post-method-authorization >>>>>>>>>>>>> >>>>>>>>>>>>> OK, >>>>>>>>>>>>> >>>>>>>>>>>>> so I would go with your first suggestion, Romain: >>>>>>>>>>>>> >>>>>>>>>>>>> @Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) >>>>>>>>>>>>> >>>>>>>>>>>>> That would leave the readability of the authorizer method >>>>>> and >>>>>>>>>>>>> BEFORE_INVOCATION could be the default, so that it could >>>>>> left >>>>>>>> blank. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Of course the extension detects at deployment time the >>>>>> problem >>>>>>>> that >>>>>>>>>>>> a >>>>>>>>>>>>> authorizer method exists with @Secures(BEFORE_INVOCATION) >>>>>> and >>>>>> a >>>>>>>>>>> parameter >>>>>>>>>>>>> annotated with @Result and suggests to use >>>>>>>>>>>> @Secures(AFTER_INVOCATION) >>>>>>>>>>>>> >>>>>>>>>>>>> Wdyt? >>>>>>>>>>>>> >>>>>>>>>>>>> Am 13.12.12 12:03 schrieb "Romain Manni-Bucau" unter >>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> if you add the "post" management @Secures will be >>>>>>>>>>> ambiguous (even if >>>>>>>>>>>>>> naturally i understand pre is implicit) so i'd just switch >>>>>> it >>>>>>>>>>>>>> >>>>>>>>>>>>>> if the API is explicit enough to not need doc it is better >>>>>> ;) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2012/12/13 Arne Limburg <[email protected]>: >>>>>>>>>>>>>>> Btw. are we talking about another name for @Secures or >>>>>> for >>>>>>>>>>> @Result? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thinking about @Secures it should not be too confusing >>>>>>>>>>> (talking with >>>>>>>>>>>>>>> myself here ;-) ), since the developer knows, if he needs >>>>>> the >>>>>>>>>>> result >>>>>>>>>>>> for >>>>>>>>>>>>>>> evaluation or not. So either he adds @Result and will >>>>>> know >>>>>>>>>>> that the >>>>>>>>>>>>>>> method >>>>>>>>>>>>>>> needs to be invoked before the authorization. Or he >>>>>>>>>>> doesn't need the >>>>>>>>>>>>>>> result, then the intuitive thing is, that the >>>>>> authorization >>>>>>>>>>> takes place >>>>>>>>>>>>>>> before the business method invocation... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 13.12.12 11:55 schrieb "Romain Manni-Bucau" unter >>>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> so i'd go for @PreSecures and @PostSecures, just >>>>>>>>>>> explicit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> but i wouldn't something not symmetrical >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/12/13 Arne Limburg >>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>> @Secures sounds cool at a first glance, but may it be >>>>>>>>>>> confusing for >>>>>>>>>>>>>>>>> users? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And also we should support a mixture of >>>>>>>>>>> @SecurityParameterBindings >>>>>>>>>>>> and >>>>>>>>>>>>>>>>> result, so the annotation should somehow indicate that >>>>>>>>>>> the parameter >>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>> the return value of the method invocation. >>>>>>>>>>>>>>>>> Consider the following example: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Copy >>>>>>>>>>>>>>>>> public MyObject copy(@Source MyObject source) { >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> public class MyCopyAuthorizer { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Secures @Copy >>>>>>>>>>>>>>>>> public boolean isCopyAllowed(@Source MyObject >>>>>>>>>>> source, >>>>>>>>>>>>>>>>> @SecuredReturnValue MyObject target) { >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> where @Copy is a @SecurityBindingType and @Source is a >>>>>>>>>>>>>>>>> @SecurityParameterBinding >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 13.12.12 11:45 schrieb "Romain >>>>>>>>>>> Manni-Bucau" unter >>>>>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Why @Secures is not fine? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> if the rule is "on parameter" it is a >>>>>>>>>>> post it can be enough. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Another solution is @Secure(hook = POST) with a >>>>>>>>>>> default to PRE >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>> Twitter: @rmannibucau >>>>>>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>>>>>>>>>>>>> Github: https://github.com/rmannibucau >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2012/12/13 Arne Limburg >>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>>>> Feel free to make a suggestion. >>>>>>>>>>>>>>>>>>> What about >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> @SecuredResult >>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>> @SecuredReturnValue >>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 13.12.12 10:50 schrieb "Gerhard >>>>>>>>>>> Petracek" unter >>>>>>>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> +1, but imo we need a better name for it. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>>>>>>> gerhard >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2012/12/13 Rudy De Busscher >>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I had once also such a requirement >>>>>>>>>>> (post-method authorization) >>>>>>>>>>>>>>>>>>>>> where >>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>> could be very handy. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We kept information about persons >>>>>>>>>>> (name, age, address, medical >>>>>>>>>>>>>>>>>>>>> info, >>>>>>>>>>>>>>>>>>>>> ...) >>>>>>>>>>>>>>>>>>>>> but there where some categories. One >>>>>>>>>>> kind of category was linked >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> Royals and you needed a special role >>>>>>>>>>> before you could read the >>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So we where only able to determine if >>>>>>>>>>> the user was allowed to >>>>>>>>>>>> read >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> person information after we had read >>>>>>>>>>> it frmo the database and >>>>>>>>>>>>>>>>>>>>> matched >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> category. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So >>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>> Rudy >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 13 December 2012 09:26, Arne >>>>>>>>>>> Limburg >>>>>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Jean-Louis, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A simple use case is a method >>>>>>>>>>> that creates an object, stores it >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> database and returns it. >>>>>>>>>>>>>>>>>>>>>> You may want to check the object >>>>>>>>>>> to decide if the user is >>>>>>>>>>>>>>>>>>>>> allowed >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>> create it. With my proposal it is >>>>>>>>>>> as easy as: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> public class MyObjectRepository { >>>>>>>>>>>>>>>>>>>>>> @Create >>>>>>>>>>>>>>>>>>>>>> public MyObject create() { >>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> public class MyAuthorizer { >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> @Secures @Create >>>>>>>>>>>>>>>>>>>>>> public boolean >>>>>>>>>>> canCreate(@Result MyObject object) { >>>>>>>>>>>>>>>>>>>>>> // security check here >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hope that makes it clear. And >>>>>>>>>>> note that the check may depend on >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> state >>>>>>>>>>>>>>>>>>>>>> of the object, i.e. the user is >>>>>>>>>>> just allowed to create the >>>>>>>>>>>>>>>>>>>>> object, >>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>> he >>>>>>>>>>>>>>>>>>>>>> is the owner... >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Am 13.12.12 09:20 schrieb >>>>>>>>>>> "Jean-Louis MONTEIRO" unter < >>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Arne, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Just read the JIRA but could >>>>>>>>>>> not find a relevant use case for >>>>>>>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>>>>>>>>> But if you proposed it, I >>>>>>>>>>> probably missed something so if you >>>>>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>>>>> elaborate a bit more. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Jean-Louis >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2012/12/13 Mark Struberg >>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>>>>>>>>> Arne Limburg schrieb am >>>>>>>>>>> Mi., 12. Dez 2012 23:38 PST: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> What do you think of >>>>>>>>>>> supporting post-method-authorization >>>>>>>>>>>>>>>>>>>>> (see >>>>>>>>>>>>>>>>>>>>> [1]) >>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> addition to our current >>>>>>>>>>> pre-method-authorization? >>>>>>>>>>>>>>>>>>>>>>>>> I just started >>>>>>>>>>> coding it and it is not much to do. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>>> Arne >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>> https://issues.apache.org/jira/browse/DELTASPIKE-298 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Jean-Louis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >> >>
