I checked the provider dealing with StreamingOutput, it does nothing but delegates back to the StreamingOutput instance, with the OutputStream retrieved from the message
cheers, Sergey On Thu, Jan 27, 2011 at 12:58 PM, Benson Margulies <[email protected]>wrote: > Glen's email put me back on the right track. > > Now I just have to track down mysterious closed streams between a > service writing to a StreamingOutput and a client waiting for the > response. > > > On Thu, Jan 27, 2011 at 5:00 AM, Sergey Beryozkin <[email protected]> > wrote: > > Hi > > > > SomeClass bean = webClient.get(SomeClass.class) > > > > will return a ServiceClass instance provided a provider understanding how > to > > read the response stream is available. > > If the error status code is returned than the above call will throw the > > ServerWebApplicationException. The underlying Response can still be > > retrieved, webClient.getResponse(). > > > > In 2.3.3-SNAPSHOT I've done a minor fix to ensure this works provided a > > ResponseReader provider is registered : > > > > Response r = webClient.get(); > > SomeClass bean = (SomeClass)r.get(); > > > > ResponseReader is mainly needed for cases where proxies are dealing with > > explicit Responses returned from methods. But I agree it can be handy for > > web clients as well, just so that the status can be checked first, etc. > > > > ResponseReader is a MessageBodyReader which uses an injected JAX-RS > > Providers context instance to find a more specific reader, such as > > org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider. > > > > The reason I'm reluctant to introduce a ClientResponse class which would > let > > users avoid registering ResponseReader is because Response has all the > > information the ClientResponse would have and having ClientResponse > would > > not fix the issue of helping proxies to cast Response.getEntity as JAX-RS > > Response is going to stay I believe. I'd prefer JAX-RS 2.0 to improve > just a > > little bit the Response interface rather than introducing a > ClientResponse > > duplicate > > > > thanks, Sergey > > > > > > On Thu, Jan 27, 2011 at 3:40 AM, Glen Mazza <[email protected]> wrote: > > > >> I don't think you ever need ResponseReader with WebClient; Sergey put it > in > >> 2.3.2 for client proxies only, and then added it to upcoming 2.3.3 for > >> WebClient. > >> > >> I *think* you want something like: > >> String jsonString = > >> > client.accept("application/json").path("/definedPredicates").get(String.class); > >> > >> Failing that, adding a custom MessageBodyReader as a Provider to handle > the > >> InputStream -> JSON conversion. But Sergey would know more. > >> > >> Glen > >> > >> > >> > >> On 26.01.2011 22:05, Benson Margulies wrote: > >> > >>> Given the following, I expected the provider to produce the entity in > >>> the response. Instead, I just get the stream. The doc mentions a > >>> ResponseReader, but doesn't show use with WebClient. What's the > >>> provider for, in any case, if a ResponseReader is needed? > >>> > >>> List<Object> providers = new ArrayList<Object>(); > >>> providers.add(new > >>> org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider()); > >>> WebClient client = WebClient.create(endpointAddress, > providers); > >>> Response r = > >>> client.accept("application/json").path("/definedPredicates").get(); > >>> Object o = r.getEntity(); > >>> assertEquals(Status.OK.getStatusCode(), r.getStatus()); > >>> > >> > >> > >> -- > >> Glen Mazza > >> Software Engineer, Talend (http://www.talend.com) > >> blog: http://www.jroller.com/gmazza > >> > >> > >> > > >
