On Dec 1, 2008, at 11:34 AM, Sergey Beryozkin wrote:
> 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.
>
There's no way to do that with @Path but you can use @PathParam with a
parameter of type PathSegment to ensure you only see matrix parameters
from a particular path segment.
Marc.
>
>> 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
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.