|
From: Scott S. <ss...@re...> - 2014-04-07 23:32:54
|
I have a client interface with a method like:
public interface INSP {
@PUT
@Path("/{domain}/subscriptions/{endpoint}{resourcePath}")
@Produces("application/json")
public String subscribeEndpointResource(@PathParam("domain") String domain,
@PathParam("endpoint") String endpoint,
@PathParam("resourcePath") String resourcePath);
}
A call like:
nsp.subscribeEndpointResource("domain", "mbed-ethernet-1DE41", "/303/0/5700");
results in a request with the resourcePath component of the request URI being encoded:
16:14:55,173 INFO [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) mbed-ethernet-1DE41(/303/0/5700)=32.12, observable=true
16:14:55,174 INFO [stdout] (default task-11) +++ Request(PUT) to: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700
16:14:55,174 INFO [stdout] (default task-11) --- Headers:
16:14:55,174 INFO [stdout] (default task-11) Accept: application/json
16:14:55,174 INFO [stdout] (default task-11) Authorization: Basic YWRtaW46c2VjcmV0
16:14:55,174 INFO [stdout] (default task-11) Accept-Encoding: gzip, deflate
16:14:55,174 INFO [stdout] (default task-11) --- End Headers:
16:14:55,175 INFO [stdout] (default task-11) null
16:14:55,175 INFO [stdout] (default task-11) --- End Body:
16:14:55,209 INFO [stdout] (default task-11) +++ Response from: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700, status=Method Not Allowed
16:14:55,209 INFO [stdout] (default task-11) --- Headers:
16:14:55,209 INFO [stdout] (default task-11) Content-Type: application/octet-stream
16:14:55,210 INFO [stdout] (default task-11) Content-Length: 62
16:14:55,210 INFO [stdout] (default task-11) Server: NSP/1.11.0-2
16:14:55,210 INFO [stdout] (default task-11) --- End Headers:
16:14:55,210 WARN [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) Failed to load mbed-ethernet-1DE41/303/0/5700 resource
: javax.ws.rs.NotAllowedException: HTTP 405 Method Not Allowed
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:183) [resteasy-client-3.0.6.Final.jar:]
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:154) [resteasy-client-3.0.6.Final.jar:]
at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) [resteasy-client-3.0.6.Final.jar:]
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) [resteasy-client-3.0.6.Final.jar:]
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) [resteasy-client-3.0.6.Final.jar:]
at com.sun.proxy.$Proxy71.subscribeEndpointResource(Unknown Source)
at org.jboss.devnation.iotbof.ejbs.NSPConnector.reload(NSPConnector.java:179) [iotbof-ejb.jar:]
The server is barfing on this because it is not uri decoding its incoming request uris. I don't have any control over it, so is there a way to prevent the resourcePath from being encoded?
Its easy enough to work around by coding my own subscribeEndpointResource utility method using the rest easy client classes, but it would be nice to simply be able to use the generated
web target proxy.
|
|
From: Bill B. <bb...@re...> - 2014-04-07 23:56:50
|
No, there's no workaround at the moment. If you are able to upgrade to
latest/greatest of Resteasy, I could add something in the 3.0.8 release
that is tomorrow.
On 4/7/2014 7:32 PM, Scott Stark wrote:
>
> I have a client interface with a method like:
>
> public interface INSP {
> @PUT
> @Path("/{domain}/subscriptions/{endpoint}{resourcePath}")
> @Produces("application/json")
> public String subscribeEndpointResource(@PathParam("domain") String domain,
> @PathParam("endpoint") String endpoint,
> @PathParam("resourcePath") String resourcePath);
> }
>
> A call like:
>
> nsp.subscribeEndpointResource("domain", "mbed-ethernet-1DE41", "/303/0/5700");
>
> results in a request with the resourcePath component of the request URI being encoded:
>
> 16:14:55,173 INFO [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) mbed-ethernet-1DE41(/303/0/5700)=32.12, observable=true
>
> 16:14:55,174 INFO [stdout] (default task-11) +++ Request(PUT) to: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700
> 16:14:55,174 INFO [stdout] (default task-11) --- Headers:
> 16:14:55,174 INFO [stdout] (default task-11) Accept: application/json
> 16:14:55,174 INFO [stdout] (default task-11) Authorization: Basic YWRtaW46c2VjcmV0
> 16:14:55,174 INFO [stdout] (default task-11) Accept-Encoding: gzip, deflate
> 16:14:55,174 INFO [stdout] (default task-11) --- End Headers:
> 16:14:55,175 INFO [stdout] (default task-11) null
> 16:14:55,175 INFO [stdout] (default task-11) --- End Body:
> 16:14:55,209 INFO [stdout] (default task-11) +++ Response from: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700, status=Method Not Allowed
> 16:14:55,209 INFO [stdout] (default task-11) --- Headers:
> 16:14:55,209 INFO [stdout] (default task-11) Content-Type: application/octet-stream
> 16:14:55,210 INFO [stdout] (default task-11) Content-Length: 62
> 16:14:55,210 INFO [stdout] (default task-11) Server: NSP/1.11.0-2
> 16:14:55,210 INFO [stdout] (default task-11) --- End Headers:
> 16:14:55,210 WARN [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) Failed to load mbed-ethernet-1DE41/303/0/5700 resource
> : javax.ws.rs.NotAllowedException: HTTP 405 Method Not Allowed
> at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:183) [resteasy-client-3.0.6.Final.jar:]
> at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:154) [resteasy-client-3.0.6.Final.jar:]
> at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) [resteasy-client-3.0.6.Final.jar:]
> at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) [resteasy-client-3.0.6.Final.jar:]
> at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) [resteasy-client-3.0.6.Final.jar:]
> at com.sun.proxy.$Proxy71.subscribeEndpointResource(Unknown Source)
> at org.jboss.devnation.iotbof.ejbs.NSPConnector.reload(NSPConnector.java:179) [iotbof-ejb.jar:]
>
>
> The server is barfing on this because it is not uri decoding its incoming request uris. I don't have any control over it, so is there a way to prevent the resourcePath from being encoded?
>
> Its easy enough to work around by coding my own subscribeEndpointResource utility method using the rest easy client classes, but it would be nice to simply be able to use the generated
> web target proxy.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Scott S. <ss...@re...> - 2014-04-08 00:31:49
|
I wouldn't worry about it unless its useful in general as I would rather just use what is shipped with the wildfly distribution to simplify set in the lab. Like I said, it is a simple workaround to wrap the client proxy in another proxy that just overrides this method to build the request uri without encoding. ----- Original Message ----- From: "Bill Burke" <bb...@re...> To: res...@li... Sent: Tuesday, April 8, 2014 4:56:37 AM Subject: Re: [Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded? No, there's no workaround at the moment. If you are able to upgrade to latest/greatest of Resteasy, I could add something in the 3.0.8 release that is tomorrow. |
|
From: Joseph O. <jo...@en...> - 2014-04-08 00:45:41
|
I think it'd be useful. :) On Mon, Apr 7, 2014 at 8:31 PM, Scott Stark <ss...@re...> wrote: > I wouldn't worry about it unless its useful in general as I would rather > just use what is shipped with the wildfly distribution to simplify set in > the lab. Like I said, it is a simple workaround to wrap the client proxy in > another proxy that just overrides this method to build the request uri > without encoding. > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Tuesday, April 8, 2014 4:56:37 AM > Subject: Re: [Resteasy-users] Is there a way to prevent a @PathParam from > being uri encoded? > > No, there's no workaround at the moment. If you are able to upgrade to > latest/greatest of Resteasy, I could add something in the 3.0.8 release > that is tomorrow. > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users > -- Joseph B. Ottinger http://enigmastation.com *Memento mori.* |