Hi Sergey, Can you formulate the issue you are seeing in the form of a failing unit test?
Gary On Mon, Jun 19, 2017 at 9:02 AM, Sergey Beryozkin <[email protected]> wrote: > Hi > > Awhile back, may be 5-6 years back, I had to deal with the following TCK > test: > > assertEquals("mailto:[email protected]";, > > UriBuilder.fromUri(new > URI("mailto:[email protected]";)).uri(new > URI(null, "[email protected]", null)). > build(); > > > new URI("mailto:[email protected]";) is opaque, while > new URI(null, "[email protected]", null) is not. > > At a time I found that the only way for this test to pass was to block any > rawPaths not starting from "/" causing the confusion in the code, such that > in this test, when > > new URI(null, "[email protected]", null). > > is submitted, the original "mailto" scheme is preserved, and the original > scheme specific part, "[email protected]" is overridden as expected, > otherwise there would be some 'conflict; in the internal state, after the > 1st pass the 'path' is undefined because it was an opaque URI, and in the > second pass we suddenly get a path component value which is meant to > replace an origin schemeSpecificPart where the path component was not even > defined... > > I realize that is not the most robust approach, but that worked at a time. > > I see that UriBuilder.fromPath() does work in this case. > > Can you think of the fix that can address your issue such that the > original UriBuilderImplTest tests continue passing ? > > Thanks, Sergey > > > > > On 17/06/17 00:23, Rubén Pérez wrote: > >> Hi, >> >> Sorry for the double mail. >> >> I forgot to add that, while I know the .jar versions are not the latest, >> I checked the code in Fisheye and from what I understood the issue >> corresponds with the latest code. The problems seems to arise from the code >> in the line 627 <https://fisheye.apache.org/br >> owse/cxf/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxr >> s/impl/UriBuilderImpl.java?hb=true#to627> [2]: if the path does not >> start with a "/", the varirable schemeSpecificPart is set to null, which in >> turn prevents the code block in the line 161 < >> https://fisheye.apache.org/browse/cxf/rt/frontend/jaxrs/src >> /main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java?hb=true#to161> >> [3] to run. >> >> Regards >> >> >> On 16/06/17 23:52, Rubén Pérez wrote: >> >>> >>> Hi, >>> >>> This is my first email to the list, so I hope I will not miss something >>> or do something wrong. I'm writing here instead of reporting a bug >>> directly, mainly because I'm not sure if I can even register in the bug >>> tracker, so apologies if that was the expected way to go. >>> >>> Cutting to the chase, I believe there is a bug in the UriBuilderImpl. >>> Specifically, when an instance of the class is created through the >>> '.fromURI' method, and the provided URI does not start with a "/" (i.e. it >>> has no schema and authority and its path is not absolute), UriBuilderImpl >>> assumes incorrectly that the URI is non-hierarchical and therefore the >>> '.build()' method will always return the provided URI without modification, >>> regardless of which edit methods (e.g. "queryParam", "path", etc.) are >>> called on the instance. >>> >>> In order to illustrate what I mean, I created a very simple program >>> (attached). I compiled it with: >>> >>> javac -cp '.:<path_to_the_jar>/javax.ws.rs-api-2.0.1.jar' >>> UriBuilderBug.java >>> >>> and runned it with: >>> >>> java -cp '.:/<path_to_the_jar>/javax.ws >>> .rs-api-2.0.1.jar:<path_to_the_jar2>/cxf-rt-frontend-jaxrs- >>> 3.1.11.jar:<path_to_the_jar3>/cxf-core-3.1.11.jar' UriBuilderBug >>> >>> The RFC-3986, in its section 4.2 <https://tools.ietf.org/html/r >>> fc3986#section-4.2> [1] defines the syntax for valid relative URI >>> references and explicitly allows references without schema or authority >>> that do *not* start with a forward slash. Perhaps part of the confusion >>> comes from the fact that the ABNF defining the relative references is as >>> follows: >>> >>> relative-part = "//" authority path-abempty >>> / path-absolute >>> / path-noscheme >>> / path-empty >>> >>> , where the "/" symbol representing the different alternatives can be >>> easily mistaken for a literal "/" in the URI itself. >>> >>> So that's it. Thanks for reading till here. Please let know your >>> opinions about this and, if I'm right, it would be great to get it fixed >>> soon. If something is not clear or you have any questions, I'm willing to >>> answer them. If there's a reason for the current behaviour, or if I am >>> incorrectly interpreting the standard, I'd also be very glad to know. >>> >>> Best regards >>> -- >>> Rubén Pérez Vázquez >>> >>> *Universität zu Köln* >>> /Regionales Rechenzentrum (RRZK)/ >>> Weyertal 121, Raum 4.05 >>> D-50931 Köln >>> ✆: +49-221-470-89603 >>> >>> [1] https://tools.ietf.org/html/rfc3986#section-4.2 >>> >> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ >
