I'm sorry - I've read it and I've got confused myself :-)
Here's an attempt to say it in simpler terms, hopefully with no typos :
In my service I would like to rely on @MatrixParam("myparam"). It's absolutely critical that this
@MatrixParam's value comes from a specific path segment only. For ex :
/base/tail;myparam
It's not expected that this parameter can be associated with /base, but only with /tail. Hence I'd like to enforce this requirement
by using a regular expression which forbids /base to carry matrix parameters.
In fact it does not if I want to use MatrixParam or PathSegment, but what does is that I'd like to enforce that matrix parameters
are associated with a given path segment only - for ex, the last one, or the first one, etc.
hope it makes sense
Thanks, Sergey
> Hi Marc
>
> I agree - and I got the idea that they should not influence the matching algorithm by default.
>
> But my point is that a user should be able to have a say - by providing an explicit regular expression which basically forbids a
> given method be invoked unless no matrix parameters are present.
>
> In other words, if one goes with @MatrixParam then by default the service/method URI space is too 'lenient' in that it will accept
> that matrix parameter at any path segment. There's no way to enforce a position when using @MatrixParam which makes @MatrixParam
> unusable in cases where the positioning matters.
>
> I believe the use of an explicit expression prohibiting matrix parameters at all path segments but some specific one
> makes it possible to use @MatrixParam unusable in cases where the positioning matters reliably. Which leads me to the conclusion
> that the exclusion of matrix parameters at the preprocessing time is only correct in cases when no arbitray path expressions are
> specified, otherwise the arbitrary regular expressions explicitly requesting that no matrix params are available on some path
> segments won't work.
>
> Cheers, Sergey
>
>
> ----- Original Message -----
> From: "Marc Hadley" <Marc.Hadley_at_Sun.COM>
> To: <users_at_jsr311.dev.java.net>
> Sent: Monday, December 01, 2008 4:06 PM
> Subject: Re: Dealing with Matrix parameters
>
>
> I think the best way to specify the ignoring of matrix parameters is
> to explicitly add it to the preprocessing of section 3.7.1. That way
> its clear that any matrix parameters in the request URI are stripped
> out for the purposes of matching to resource classes.
>
> Marc.
>
> On Nov 30, 2008, at 4:30 PM, Sergey Beryozkin wrote:
>
>> Hi,
>>
>> > >> @GET
>> > >> @Path("base/{tail}")
>>
>>
>> > >> GET /base;matrixParam=ParamValue/beginTail
>> > >>
>> > >> does not match the method.
>> > >The method matches the request, because the matching of
>> @Path(...) ignores the matrix parameters.
>>
>>
>> I have one more question about it. Consider a custom regular expression where a use explicitly requests that only URI containing
>> no
>> “;” symbols in a ‘/base’ path segment are accepted.
>>
>> I think it’s a very realistic way to enforcing a position of an expected matrix parameter while using @MatrixParam.
>>
>> Therefore I don’t think the algorithm ‘matching of @Path(...) ignores the matrix parameters’ works in all cases as it’s
>> unrealistic IMHO to expect
>> the runtime to check if an arbitrary regular expression explicitly disaalows ‘;’ or not as there’s a number of way to express
>> this requirement in a regular
>> expression.
>>
>> Thus I think we have :
>>
>> • @Path("base/{tail}")
>> GET /base;matrixParam=ParamValue/beginTail
>>
>> This request should be matched
>>
>> • @Path("base/{tail}")
>> GET /base/beginTail;matrixParam=ParamValue
>>
>> This request should be matched – this is the most expected outcome as we’re dealing with a default regular
>> expression
>>
>> • @Path("{base:base&&[^;]}/{tail}")
>> GET /base;matrixParam=ParamValue/beginTail
>>
>> This must not match – a user has explicitly requested it should not.
>>
>> • @Path("{base:base}/{tail}")
>> GET /base;matrixParam=ParamValue/beginTail
>>
>> This should not match – how the runtime will find out that this arbitrary reg expression is not equivalent to that
>> one in 3 ?.
>>
>> In fact, I believe 4 is identical to 1
>>
>>
>> IMHO it would be inconsistent if 3 & 4 did not match but 1 were expected to match (as it is now).
>>
>> Thus I’d suggest that the algorithm “‘matching of @Path(...) ignores the matrix parameters’” is changed to
>> “‘matching of @Path(...) ignores the matrix parameters’ only when parameterized path values are used as in {base}”.
>>
>> In cases like
>> @Path("base/{tail}")
>> GET /base;matrixParam=ParamValue/beginTail
>>
>> By default there should be no match – but if the user would like a match to happen while ensuring that ‘base’ path segment is
>> used then
>> it would be possible for a user to express it using an arbitrary regular expression which would expect ‘base’ plus optional
>> matrix params.
>>
>>
>> Any comments from experts ?
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>