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:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2008 8:50 AM To: [email protected] 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)" <[EMAIL PROTECTED]> To: <[email protected]> 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:[EMAIL PROTECTED] Sent: Monday, November 24, 2008 8:37 AM To: [email protected] 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)" <[EMAIL PROTECTED]> To: <[email protected]> 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:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 5:14 PM To: [email protected] 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:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 4:44 PM To: [email protected] 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:[EMAIL PROTECTED] Sent: 21 November 2008 18:17 To: [email protected] 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:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 12:54 PM To: [email protected] 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)" <[EMAIL PROTECTED]> To: <[email protected]> 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"
