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