You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com> on 2008/11/21 18:11:36 UTC
@MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
Re: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <se...@progress.com>.
That's done on the trunk now.
I have to admit I remain pessimistic about the algorithm which leads to the following test passing so the work I've done is partial
in this regard - that is 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. I'll relax this condition as necessary.
Basically, I think if a user explicitly requests no matrix parameters can be cariied with /base through, for ex,
@Path("{base:base&&[^;]}"), or a number of similar regular expressions, then the match should not happen
Thanks, Sergey
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Tuesday, November 25, 2008 3:26 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Thanks for the fast turn time on these. I'll create the JIRA in the
next couple of days as time permits.
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>.
Thanks for the fast turn time on these. I'll create the JIRA in the
next couple of days as time permits.
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Tuesday, November 25, 2008 8:50 AM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi,
Your tests 2 & 3 will work now as expected (fixes on 2.2-SNAPSHOT
trunk). Additionally, MatrixParam("") CXF extension will be
supported to have matrix params injected as properties into a custom
bean.
The remaining issue is to fix Test 4 - it might take me a bit of time
but will get fixed. If you could create a JIRA (specificallu
for test 4) then it would be apreciated
Thanks for your input
Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 2:00 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Likewise, I appreciate your working to make the suggested changes.
I agree that in the case of #3, there is some ambiguity and there are
posts out there regarding the fact that a matrix parameter with the same
'name' multiple times in a URI leads to ambiguity. I would suspect that
the proper way to deal with this is to declare the method parameter as
ArrayList<string>. That way the runtime could populate the array with
all of the values, yet it would remain undefined where the values fall
in the URI path forcing the application to parse the raw string. Anyone
have suggestions on how to address this challenge?
Unfortunately, the current implementation doesn't necessarily avoid
falling into the same trap. For instance, the results below (where I
include the matrix param twice) are not necessarily as one would expect
using 'Jersey'. Note that the first instance of the matrix parameter
appended to '/base' is discarded.
The other upshot of all of this is that current implementations only
support matrix parameters appended to the end of a URI. This seems to
undermine much of their potential value, but that is a spec (reference
implementation) issue and I'll try to address that through Jersey and
keep you posted on any progress.
With @Path("base/{tail}"):
==========================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: null
tail: tail
matrixParm=ParamValueTail
With @Path("{base}/{tail}"):
============================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: base
tail: tail
matrixParm=ParamValueTail
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Monday, November 24, 2008 8:37 AM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Many thanks for helping me to understand how all the matrix params stuff
is working
On test2 : I've got one confirmation that matrix params should be
stripped from a path value -
I thought the right way was to use PathSegment instead and do
PathSegment.getPath() or PathSegment.getMatrixParameters() as
appropriate rather than swallowing matrix data - but perhaps it's more
consistent with theway query parameters are dealt with so
yea, I guess I'll neeed to fix it.
on test3 : I still reckon it's correct that you get a null matrix param
- otherwise if an identically named matrix parameter is
associated with a number of path segments then how would you figure out
what this matrix parameter means as I reckon the scope of
its path 'parent' provides the additional hints ?
On test4 : same as test 2 - will need to fix it
Thanks, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 1:24 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
Re: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <se...@progress.com>.
Hi,
Your tests 2 & 3 will work now as expected (fixes on 2.2-SNAPSHOT trunk). Additionally, MatrixParam("") CXF extension will be
supported to have matrix params injected as properties into a custom bean.
The remaining issue is to fix Test 4 - it might take me a bit of time but will get fixed. If you could create a JIRA (specificallu
for test 4) then it would be apreciated
Thanks for your input
Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 2:00 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Likewise, I appreciate your working to make the suggested changes.
I agree that in the case of #3, there is some ambiguity and there are
posts out there regarding the fact that a matrix parameter with the same
'name' multiple times in a URI leads to ambiguity. I would suspect that
the proper way to deal with this is to declare the method parameter as
ArrayList<string>. That way the runtime could populate the array with
all of the values, yet it would remain undefined where the values fall
in the URI path forcing the application to parse the raw string. Anyone
have suggestions on how to address this challenge?
Unfortunately, the current implementation doesn't necessarily avoid
falling into the same trap. For instance, the results below (where I
include the matrix param twice) are not necessarily as one would expect
using 'Jersey'. Note that the first instance of the matrix parameter
appended to '/base' is discarded.
The other upshot of all of this is that current implementations only
support matrix parameters appended to the end of a URI. This seems to
undermine much of their potential value, but that is a spec (reference
implementation) issue and I'll try to address that through Jersey and
keep you posted on any progress.
With @Path("base/{tail}"):
==========================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: null
tail: tail
matrixParm=ParamValueTail
With @Path("{base}/{tail}"):
============================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: base
tail: tail
matrixParm=ParamValueTail
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Monday, November 24, 2008 8:37 AM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Many thanks for helping me to understand how all the matrix params stuff
is working
On test2 : I've got one confirmation that matrix params should be
stripped from a path value -
I thought the right way was to use PathSegment instead and do
PathSegment.getPath() or PathSegment.getMatrixParameters() as
appropriate rather than swallowing matrix data - but perhaps it's more
consistent with theway query parameters are dealt with so
yea, I guess I'll neeed to fix it.
on test3 : I still reckon it's correct that you get a null matrix param
- otherwise if an identically named matrix parameter is
associated with a number of path segments then how would you figure out
what this matrix parameter means as I reckon the scope of
its path 'parent' provides the additional hints ?
On test4 : same as test 2 - will need to fix it
Thanks, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 1:24 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
Re: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <se...@progress.com>.
Hi
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 2:00 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Likewise, I appreciate your working to make the suggested changes.
I agree that in the case of #3, there is some ambiguity and there are
posts out there regarding the fact that a matrix parameter with the same
'name' multiple times in a URI leads to ambiguity. I would suspect that
the proper way to deal with this is to declare the method parameter as
ArrayList<string>. That way the runtime could populate the array with
all of the values, yet it would remain undefined where the values fall
in the URI path forcing the application to parse the raw string. Anyone
have suggestions on how to address this challenge?
>S.B - either use PathSegment per every Path {id} parameter
@Path(/{a}/{b})
someMethod(@PathParam("a") PathSegment a, @PathParam("b") PathSegment b)
or use UriInfo.getPathSegments() in cases where you do not want to introduce template variables.
I added PathSegment (as path parameters) support yesterday evening.
So in the former case you can get the associations unambiguosly
Cheers, Sergey
Unfortunately, the current implementation doesn't necessarily avoid
falling into the same trap. For instance, the results below (where I
include the matrix param twice) are not necessarily as one would expect
using 'Jersey'. Note that the first instance of the matrix parameter
appended to '/base' is discarded.
The other upshot of all of this is that current implementations only
support matrix parameters appended to the end of a URI. This seems to
undermine much of their potential value, but that is a spec (reference
implementation) issue and I'll try to address that through Jersey and
keep you posted on any progress.
With @Path("base/{tail}"):
==========================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: null
tail: tail
matrixParm=ParamValueTail
With @Path("{base}/{tail}"):
============================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: base
tail: tail
matrixParm=ParamValueTail
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Monday, November 24, 2008 8:37 AM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Many thanks for helping me to understand how all the matrix params stuff
is working
On test2 : I've got one confirmation that matrix params should be
stripped from a path value -
I thought the right way was to use PathSegment instead and do
PathSegment.getPath() or PathSegment.getMatrixParameters() as
appropriate rather than swallowing matrix data - but perhaps it's more
consistent with theway query parameters are dealt with so
yea, I guess I'll neeed to fix it.
on test3 : I still reckon it's correct that you get a null matrix param
- otherwise if an identically named matrix parameter is
associated with a number of path segments then how would you figure out
what this matrix parameter means as I reckon the scope of
its path 'parent' provides the additional hints ?
On test4 : same as test 2 - will need to fix it
Thanks, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 1:24 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>.
Likewise, I appreciate your working to make the suggested changes.
I agree that in the case of #3, there is some ambiguity and there are
posts out there regarding the fact that a matrix parameter with the same
'name' multiple times in a URI leads to ambiguity. I would suspect that
the proper way to deal with this is to declare the method parameter as
ArrayList<string>. That way the runtime could populate the array with
all of the values, yet it would remain undefined where the values fall
in the URI path forcing the application to parse the raw string. Anyone
have suggestions on how to address this challenge?
Unfortunately, the current implementation doesn't necessarily avoid
falling into the same trap. For instance, the results below (where I
include the matrix param twice) are not necessarily as one would expect
using 'Jersey'. Note that the first instance of the matrix parameter
appended to '/base' is discarded.
The other upshot of all of this is that current implementations only
support matrix parameters appended to the end of a URI. This seems to
undermine much of their potential value, but that is a spec (reference
implementation) issue and I'll try to address that through Jersey and
keep you posted on any progress.
With @Path("base/{tail}"):
==========================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: null
tail: tail
matrixParm=ParamValueTail
With @Path("{base}/{tail}"):
============================
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValueBase/tail;mat
rixParam=ParamValueTail
base: base
tail: tail
matrixParm=ParamValueTail
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Monday, November 24, 2008 8:37 AM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Many thanks for helping me to understand how all the matrix params stuff
is working
On test2 : I've got one confirmation that matrix params should be
stripped from a path value -
I thought the right way was to use PathSegment instead and do
PathSegment.getPath() or PathSegment.getMatrixParameters() as
appropriate rather than swallowing matrix data - but perhaps it's more
consistent with theway query parameters are dealt with so
yea, I guess I'll neeed to fix it.
on test3 : I still reckon it's correct that you get a null matrix param
- otherwise if an identically named matrix parameter is
associated with a number of path segments then how would you figure out
what this matrix parameter means as I reckon the scope of
its path 'parent' provides the additional hints ?
On test4 : same as test 2 - will need to fix it
Thanks, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 1:24 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
Re: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <se...@progress.com>.
Hi
Many thanks for helping me to understand how all the matrix params stuff is working
On test2 : I've got one confirmation that matrix params should be stripped from a path value -
I thought the right way was to use PathSegment instead and do PathSegment.getPath() or PathSegment.getMatrixParameters() as
appropriate rather than swallowing matrix data - but perhaps it's more consistent with theway query parameters are dealt with so
yea, I guess I'll neeed to fix it.
on test3 : I still reckon it's correct that you get a null matrix param - otherwise if an identically named matrix parameter is
associated with a number of path segments then how would you figure out what this matrix parameter means as I reckon the scope of
its path 'parent' provides the additional hints ?
On test4 : same as test 2 - will need to fix it
Thanks, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Monday, November 24, 2008 1:24 PM
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>.
Sergey:
Over the weekend I ported the code over onto Jersey to see how the
reference implementation handled things. Below are the results of
testing on that JAX-RS implementation:
Test #1
=======
Full Request URI: http://localhost:8088/Jersey_10/base/tail
base: base
tail: tail
matrixParm=null
//Test #2 - Note that in the reference implementation, the matrix
parameter is stripped from the value of 'tail:'. As noted below, CXF
leaves the matrix parameter appended to the value of @PathParam("tail").
Full Request URI:
http://localhost:8088/Jersey_10/base/tail;matrixParam=value
base: base
tail: tail
matrixParm=value
//Test #3 - The results are the same, so I think this is a defect in the
reference implementation based on the information provided below in my
11/21 email. Having said that, it would seem that I'll have to register
a defect with them, since you are required to conform to their
implementation.
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/taill
base: base
tail: taill
matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to '/base' as shown below. Unlike CXF, which
fails to match, Jersey does properly match the request. It also
properly parses out the value of 'tail' and 'base' (base is no longer
valid given the change in the @Path annotation. The results relative to
the treatment of the matrix parameter are consistent with #3. I think
this demonstrates that a change needs to be made to CXF, based on the
reference implementation behavior.
@Path("base/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info)
Results -
Full Request URI:
http://localhost:8088/Jersey_10/base;matrixParam=ParamValue/tail
base: null
tail: tail
matrixParm=null
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: Friday, November 21, 2008 5:14 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>.
Sergey:
I think that matrix parameters are allowed within any path segment of a
URI.
RFC 3986 - URI Generic Syntax
Section 3.3 Path has this to say regarding the topic:
=======
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
=======
If you refer the RFC it seems clear that they are allowed within any
path segment, not just the last one. This tends to be reinforced by
next link where Paul Sandoz discusses them and the example he makes use
of within the context of JAX-RS (Jersey reference implementation) has
the matrix parameters embedded in the middle of the URI path segments:
http://n2.nabble.com/Example-of-matrix-URIs--td1482069.html
This one demonstrates the expectation that matrix parameters can be
found embedded in the URI and not only at the end.
Hope this helps clarify why my expectations are that test #3 is valid
and the matrix parameter should be found.
Regards,
Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Friday, November 21, 2008 4:44 PM
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Bruce
Ok, thanks. I agree about test2. I think in test3 it's correct that you
see a null matrix parameter as I belive they're checked on the last path
segment, not on all of them.
I'm still not sure about 4, that is that
@Path("base/{tail}")
Should match
base;a=2;b=3/tail
but most likely it's just my ignorance and I'll be happy to accept I'm
wrong here and make it right. I'll try to fix it all asap (I have a
couple of other JAX-RS bugs pending).
Thanks again for posting useful test data
Sergey
-----Original Message-----
From: Maxfield, Bruce D. (LNG-DAY)
[mailto:Bruce.Maxfield@lexisnexis.com]
Sent: 21 November 2008 18:17
To: users@cxf.apache.org
Subject: RE: @MatrixParam anomoly - four test cases w/ code example
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
RE: @MatrixParam anomoly - four test cases w/ code example
Posted by "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>.
Regarding your reply to #2 and #4, you may wish to look at:
JAX-RS JavaDoc - javax.ws.rs Annotation Type Path
In the 'Element Detail' section of the page it reads:
====================
Defines a URI template for the resource class or method, must not
include matrix parameters.
Embedded template parameters are allowed and are of the form:
param = "{" *WSP name *WSP [ ":" *WSP regex *WSP ] "}"
name = (ALPHA / DIGIT / "_")*(ALPHA / DIGIT / "." / "_" / "-" ) ;
\w[\w\.-]*
regex = *( nonbrace / "{" *nonbrace "}" ) ; where nonbrace is any char
other than "{" and "}"
See RFC 5234 for a description of the syntax used above and the
expansions of WSP, ALPHA and DIGIT. In the above name is the template
parameter name and the optional regex specifies the contents of the
capturing group for the parameter.
====================
Note that the URI template 'must not include the matrix parameters'. As
a result, matrix parameters are not bound to a URI path segment. It
also means that #4 should match, since you cannot explicitly call out
the presence or absence of a matrix parameter using the URI template.
This is in fact a known issue, that I would assume is attributable to
this statement. Ideally, I would like to call out what matrix parameter
is valid on what path. In most cases, this is what is needed.
I've actually tried to put some regular expressions in place to attempt
this, but have been striking out badly.
Regards, Bruce
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@progress.com]
Sent: Friday, November 21, 2008 12:54 PM
To: users@cxf.apache.org
Subject: Re: @MatrixParam anomoly - four test cases w/ code example
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically
MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching
path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base'
path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
Re: @MatrixParam anomoly - four test cases w/ code example
Posted by Sergey Beryozkin <se...@progress.com>.
Hi
Thanks for posting your test results
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
S.B. I need to confirm it on the jaxrs user list - technically MatrixParam is part of a single path segment
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
S.B. Need to check this one too, as I'm not sure if all the matching path segments but the last one need to be checked
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"
S.B I think it might be correct as there're is only 'base' in the 'base' path segment @Path("base/{tail}
I'll confirm it all and get back to you
Cheers, Sergey
----- Original Message -----
From: "Maxfield, Bruce D. (LNG-DAY)" <Br...@lexisnexis.com>
To: <us...@cxf.apache.org>
Sent: Friday, November 21, 2008 5:11 PM
Subject: @MatrixParam anomoly - four test cases w/ code example
I've been working with the CXF 2.2 snapshot and have encountered what I
believe to be anomalies in its behavior. Below is my test code, then
below that the output/description of four test cases. Any insight into
whether this is expected behavior or a defect would be appreciated.
package com.example.simpleJaxRsResources;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.Path;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
@Path("{base}/{tail}")
@Produces("text/plain")
public class FirstResource {
@GET
public String getFirstResource(@PathParam("base") String base,
@PathParam("tail") String tail,
@MatrixParam("matrixParam") String matrixParm,
@Context UriInfo info) {
return "Full Request URI: " + info.getRequestUri() + "\n" +
"base: " + base + "\n" +
"tail: " + tail + "\n" +
"matrixParm=" + matrixParm;
}
}
//Test #1
//Full Request URI: //CXF22/base/beginTail
//base: base
//tail: beginTail
//matrixParm=null
//Test #2 - Seems like the ';matrixParam=ParamValue' should not appear
in 'tail:'
//Full Request URI: //CXF22/base/beginTail;matrixParam=ParamValue
//base: base
//tail: beginTail;matrixParam=ParamValue
//matrixParm=ParamValue
//Test #3 - Seems like ';matrixParam=ParamValue' should not appear in
'base', and should appear in 'matrixParm'
//Full Request URI: //CXF22/base;matrixParam=ParamValue/beginTail
//base: base;matrixParam=ParamValue
//tail: beginTail
//matrixParm=null
//Test #4 - change the @Path to be @Path("base/{tail}, then append
';matrixParam=ParamValue' to it.
// The following URL then does not match
".../base;matrixParam=ParamValue/beginTail"