11:28 a.m.
As you have noted there is no simple clean way to alter this processing behavior.
When it is this difficult and complex to control the processing behavior you
desire, its an strong indication that you are attempting to use a feature outside
its defined bounds and your implementation would be considered a bad code practice,
fraught with potential maintenance nightmares.
I strongly recommend you stop and reevaluate the problem you are attempting
to solve and seek a means of addressing it in a way that is considered a standard
practice.
If you absolutely must proceed down this solution path then you would need
to provide your own javax.ws.rs.core.URIBuilder implementation and pass it
to the ProxyBuilder as a target.
CustomURIBuilder cBuilder = new CustomURIBuilder();
ProxyBuilder<T> proxyBuilder = client
.target(cBuilder.uri(uri))
//.target(uri)
.proxyBuilder(apiClassType);
After looking at the code you might think that you can extend Resteasy's
URIBuilder implementation and override one of the resolveTemplates methods
but there are several problems with that.
- Overriding resolveTemplates method will not work because these methods
call method buildString, which is private.
- javax.ws.rs.core.URIBuilder is an abstract class that uses
RuntimeDelegate.getInstance().createUriBuilder() in a handful of methods
for creating a UriBuilder object. In Resteasy the RuntimeDelegate is
tied to ResteasyProviderFactory so you can not use methods newInstance,
fromUri, fromPath, fromResource, fromMethod because they will return
Resteasy's implementation class not yours.
- You will not be able to override URiBuilder.newInstance to avoid access to
RuntimeDelegate because it is a static method. You don't want to replace
Resteasy's RuntimeDelegate because then you will break Resteasy itself.
So now that we have discussed what you don't want to do and what you can't do
lets consider other options.
URI variables "{path}" can be matched by a regular expression
"[^/]+?". There are
a variety of web sites that discuss this. The disadvantage to this solution is
the more unrestricted a string you want to support the more complicated the the
expression may be. This could cause long term maintenance issues.
Use the URI variable as it is intended, in particular don't embed a forward slack in
the value
and use another methodology to process the path. Here is a post with some good suggests,
http://stackoverflow.com/questions/17000193/can-we-have-more-than-one-pat...
Don't pass the "path" information as a URI variable. Pass it as a
QueryParam to
your REST method, and process it internally.
----- Original Message -----
From: "Rebecca Searls" <rsearls(a)redhat.com>
To: "Gareth Healy" <garethahealy(a)gmail.com>
Cc: resteasy(a)lists.jboss.org
Sent: Friday, September 16, 2016 7:34:46 AM
Subject: Re: [resteasy] Client escapes slashes causing failure
I'm putting together an example of how to override the "encodeSlash"
setting.
Should be available later today.
----- Original Message -----
> From: "Gareth Healy" <garethahealy(a)gmail.com>
> To: "Rebecca Searls" <rsearls(a)redhat.com>
> Cc: resteasy(a)lists.jboss.org
> Sent: Friday, September 16, 2016 4:27:27 AM
> Subject: Re: [resteasy] Client escapes slashes causing failure
>
> Just digging into this a bit more, i can see the param processor is loaded
> [1] which calls the web target [2], but this calls an overload which always
> passes in true for "encodeSlash".
>
> [1] https://github.com/resteasy/Resteasy/blob/master/resteasy-
> client/src/main/java/org/jboss/resteasy/client/jaxrs/
> internal/proxy/processors/webtarget/PathParamProcessor.java
> [2] https://github.com/resteasy/Resteasy/blob/master/resteasy-
> client/src/main/java/org/jboss/resteasy/client/jaxrs/
> internal/ClientWebTarget.java#L134
> [3] https://github.com/resteasy/Resteasy/blob/master/resteasy-
> jaxrs/src/main/java/org/jboss/resteasy/specimpl/
> ResteasyUriBuilder.java#L1085
>
> The param processor is created by the factory [4] so i can't see how to
> change the default behaviour.
>
> [4]
>
https://github.com/resteasy/Resteasy/blob/master/resteasy-client/src/main...
>
> On Thu, Sep 15, 2016 at 9:54 AM, Gareth Healy <garethahealy(a)gmail.com>
> wrote:
>
> > I've added a simple unit test which shows the behaviour @
> > https://github.com/garethahealy/resteast-pathparam-escape
> >
> > Contains 1 test, which uses a ClientRequestFilter to check what the URI
> > is, if it contains "%2F", then it fails.
> >
> > Cheers.
> >
> > On Wed, Sep 14, 2016 at 8:01 PM, Rebecca Searls <rsearls(a)redhat.com>
> > wrote:
> >
> >>
> >> If you replace RelativePath with String do you have the same issue?
> >> What RelativePath class are you using?
> >>
> >> ----- Original Message -----
> >> > From: "Gareth Healy" <garethahealy(a)gmail.com>
> >> > To: resteasy(a)lists.jboss.org
> >> > Sent: Wednesday, September 14, 2016 11:36:31 AM
> >> > Subject: [resteasy] Client escapes slashes causing failure
> >> >
> >> > I have a client which uses the following method:
> >> >
> >> >
> >> >
> >> > @GET
> >> > @Path("/{path}/treeHash")
> >> > Response getEntityHash(@PathParam("path") RelativePath
path);
> >> >
> >> > The RelativePath object gets converted into a value of:
> >> > t;unit-testing/e;ua2shhq9
> >> >
> >> >
> >> >
> >> >
> >> > Example full URL: /entity/t;unit-testing/e;ua2shhq9/treeHash
> >> >
> >> > When its executed, the forward slash is converted to %2F (encoded /).
> >> This
> >> > causes the call to fail. What do i need to do, to make sure its not
> >> > URL
> >> > encoded?
> >> >
> >> > I've tried adding @Encoded, but that has no effect.
> >> >
> >> > Cheers.
> >> >
> >> > _______________________________________________
> >> > resteasy mailing list
> >> > resteasy(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/resteasy
> >> >
> >>
> >
> >
>
_______________________________________________
resteasy mailing list
resteasy(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy