UriBuilder cannot be renamed as this would break the API.
What I propose is that those people that want an unlimited API builder work with the Java SE team to get one there.
The harm of adding other schemas besides http is that the API becomes inconsistent. From the JAX-RS view, support for file:// in JAX-RS makes no sense at all in any place. You simply misuse a JAX-RS class because Java SE's http client is missing it.
-Markus
Von: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Rob McDougall
Gesendet: Dienstag, 28. Januar 2020 20:33
An: jaxrs developer discussions
Betreff: Re: [jaxrs-dev] Spec clarification: UriBuilder
Hi Markus,
Are you arguing that the UriBuilder class should be renamed to HttpUriBuilder (since it can’t possibly support all possible URIs and since it is only really required to support http)?
I don’t think anyone is really arguing that UriBuilder should or can support all possible schemes, however I don’t think it’s unreasonable for it to support some small number of known (and common) schemes.
If I understand your point of view, you are arguing that this small number (as mandated by the JAX-RS spec) should be limited to http-related schemes. I can understand the logic in that.
What is the harm in logging an enhancement request with a specific implementation to support a very slightly larger superset of the schemes mandated by the spec? The Jersey team has already undertaken the work for their implementation and I wouldn’t imagine the work in supporting it in other implementations is particularly onerous. I can certainly see the benefit in supporting file:// in addition to the http-related schemes. Can’t you?
Regards,
Rob
Rob McDougall | Senior Technical Architect | 4Point | +1.613.907.6415 | www.4Point.com
Receive our news and announcements before anyone else - follow us on:
From: jaxrs-dev-bounces@xxxxxxxxxxx <jaxrs-dev-bounces@xxxxxxxxxxx> On Behalf Of Markus KARG
Sent: Tuesday, January 28, 2020 1:44 PM
To: 'jaxrs developer discussions' <jaxrs-dev@xxxxxxxxxxx>
Subject: Re: [jaxrs-dev] Spec clarification: UriBuilder
This could become complex given the fact that UriBuilder is a *Builder* but URI can have infinite schemas and each schema could have infinite syntaxes, so how shall this effectively work? And which vendor would be willing to guarantee support for ANY kind of URI in their existing product?
A general tool like this one should be part of Java SE's URI support, not part of JAX-RS. And again, chapter 1.2 mandates the _whole_ API's charter, independent of what a particular class's JavaDoc says.
-Markus
I agree that JAX-RS of course focus on HTTP, but UriBuilder is described as "URI template-aware utility class for building URIs". And therefore I would expect that it works with all kind of URIs. I don't think that it is worth to add TCK tests for it, but IMO this could/should be reported to CXF as a bug.
Jan,
I understand your point, but actually I doubt that any implementing product actually would support file:// URLs anywhere outside of UriBuilder. JAX-RS cleary and explicitly is solely http-centric:
1.2 Goals
The following are the goals of the API:
...
HTTP-centric The specification will assume HTTP[4] is the underlying network protocol and will provide a clear mapping between HTTP and URI[5] elements and the corresponding API classes and annotations. The API will provide high level support for common HTTP usage patterns and will be sufficiently flexible to support a variety of HTTP applications including WebDAV[6] and the Atom
Publishing Protocol[7].
...
So it wouldn't make much sense to force all implementations to support file:// URLs in UriBuilder if that is the sole place where file:// would work then.
Just My 2C
-Markus
-----Ursprüngliche Nachricht-----
Von: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jan Supol
Gesendet: Montag, 27. Januar 2020 11:21
An: jaxrs-dev@xxxxxxxxxxx
Betreff: Re: [jaxrs-dev] Spec clarification: UriBuilder
Markus,
UriBuilder refers to RFC 3986. I was always under the impression that
not only the HTTP scheme should be handled by UriBuilder, but other
described by the RFC, too. Am I wrong?
Thanks,
Jan
On 24.01.2020 17:52, Markus KARG wrote:
>
> Well, UriBuilder is defined by JAX-RS, and JAX-RS is an API for
> REST-/over-http/ only, so I doubt there will be a cross-product
> solution be defined by us as long as you want to use any other scheme
> than "http". ;-)
>
> -Markus
>
> *Von:*jaxrs-dev-bounces@xxxxxxxxxxx
> [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] *Im Auftrag von *Jonathan Gallimore
> *Gesendet:* Freitag, 24. Januar 2020 11:53
> *An:* jaxrs-dev@xxxxxxxxxxx
> *Betreff:* [jaxrs-dev] Spec clarification: UriBuilder
>
> Hi
>
> Hopefully this isn't daft question, but I'd appreciate some help. I
> have a scenario where UriBuilder is being used to construct a file
> URI, and append a path to it:
>
> UriBuilder.fromUri("file:///~/calendar").path("extra").build().toString()
>
> I've tried this with a couple of implementations, specifically Jersey
> and CXF, with differing results - Jersey returns
> file:///~/calendar/extra, which is what I personally would expect. CXF
> on the other hand picks up "///~/calendar" as a "schemeSpecificPart"
> of the URI, and used that, and does not append the path.
>
> I'm looking at
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaxrs/api/rs/core/uribuilder/JAXRSClient.java -
> its possible I've missed something, but I can't see a case that
> specifically covers file://, or a case that specifically covers
> UriBuilder.fromUri().path() (there are others that test cases such as
> fromUri().port(), fromUri().host() and fromUri().scheme() etc).
>
> Could you clarify what behaviour you'd expect in this scenario, and /
> or point me at the relevant part of the spec document (I'm struggling
> to find a reference there too).
>
> I'd be very happy to contribute any appropriate updates to either
> documentation or TCK tests if necessary.
>
> Many thanks
>
> Jon
>
> --
>
> Jonathan Gallimore
>
> http://www.tomitribe.com <http://www.tomitribe.com/>
>
>
> _______________________________________________
> jaxrs-dev mailing list
> jaxrs-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
--
