Hi
So can I ask what this mean then :
@Path("{base:.+}")
?
Well, my understanding is that this means that a runtime will act as per a user request, as far as matching is concerned.
Right ?
Therefore I'd expect the runtime to act on my request same way as it does in the former case when I do request through a custom
expression that no matrix parameters are associated with a given segment. Now, if we preprocess in all cases by removing all the
matrix parameters then it won't matter whether we use custom expressions or not but the user expectations about enforcing the
position won't work.
IMHO, a simpler approach is to expect that if a given path segment relies on a custom regular expression then the match will happen
only if a given custom expression allows for such a match
Yes, I understand that PathSegment will do it for me but it requires me to introduce a JAXRS specific type into my interface or
abstract type - may not a big deal, but anyway and I don't understand why a user is not allowed to use MatrixParams and expect that
parameters will be positioned as it's been designed by a user
Cheers, Sergey
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net