You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Glinski, Tomasz" <to...@capgemini.com> on 2011/03/22 15:18:29 UTC
Changing response staus on the client side
Hi,
I am writing a client to the server (no changes on server possible), that sends responses with no message body, with response status 200. CXF throws than WebApplicationException, as it expects status 204 in such situation.
Is there a way to change the status "on-the-fly", before the response is parsed? Tried with interceptors, with no success...
Greets
Tomasz
________________________________
Capgemini Polska Sp. z o.o.,
ul. Pi?kna 18, 00-549 Warszawa
S?d Rejonowy dla M.ST. Warszawy, XII Wydzia? Gospodarczy Rejestrowy, nr KRS: 0000040605
NIP: 526-11-84-467,
wysoko?? kapita?u zak?adowego: 16 397 097,00 Z?
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
AW: Changing response staus on the client side
Posted by "Glinski, Tomasz" <to...@capgemini.com>.
Hi Sergey
=========================
Hi Tomasz
=============
> Hi Sergey,
>
> WebApplicationException comes from AbstractClient.readBody(), inside catch:
>
> MessageBodyReader mbr =
> ProviderFactory.getInstance(inMessage).createMessageBodyReader(
> try {
> return mbr.readFrom(cls, type, anns, contentType, new MetadataMap<String,
> Object>(r.getMetadata(), true, true), conn.getInputStream());
> } catch (Exception ex) {
> throw new WebApplicationException();
> }
>
> Few lines before is the status checked, in some cases (204) simply null is
> returned. So yes, client tries to read the body.
>
> I use CXF in cooperation with Spring, so I'm not sure, what exactly should
> I answer, so I will simply attach part o stacktrace:
> javax.ws.rs.WebApplicationException
> at
> org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:391)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:444)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:428)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:171)
> at $Proxy88.update(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
> at $Proxy95.update(Unknown Source)
> (lower in stacktrace is no important stuff)
>
> I tried the trick with IN interceptor and different phases, did not work...
> Which phase you think it should be? I tried to debug this, the status is
> taken from HttpURLConnection, can it be really overridden?
>
>
I'm fixing that right now, it's unfortunate HttpUrlConnection is used to
check the status there given that few lines earlier the status is taken from
the message. In 2.3.4 you'll be able to override the status.
The direct HttpUrlConnection dependency itself will be removed once the
async http conduit gets supported.
I think you can try the following at the moment. I can see the proxies are
injected from Spring, but the actual code where the invocations are made can
be handled like this:
@Resource
BookService proxy;
try {
return proxy.getIt();
} catch (WebApplicationException ex) {
Response response = WebClient.client(proxy).getResponse();
if (response.getStatus() == 200) {
return null;
}
throw ex;
}
Will it work for you ?
Sergey
===========================================================
Hi Sergey
Well, at least I know a cannot handle the problem the right way ;) Your workaround is not perfect, but maybe it will be the only solution. Will see.
Thank you very much for your such quick help!
Pozdrawiam :)
Tomasz
> Thanks
>
> ====
>
> Greets
> > Tomasz
> >
>
Capgemini Polska Sp. z o.o.,
ul. Piękna 18, 00-549 Warszawa
Sąd Rejonowy dla M.ST. Warszawy, XII Wydział Gospodarczy Rejestrowy, nr KRS: 0000040605
NIP: 526-11-84-467,
wysokość kapitału zakładowego: 16 397 097,00 ZŁ
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
Re: Changing response staus on the client side
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
=============
> Hi Sergey,
>
> WebApplicationException comes from AbstractClient.readBody(), inside catch:
>
> MessageBodyReader mbr =
> ProviderFactory.getInstance(inMessage).createMessageBodyReader(
> try {
> return mbr.readFrom(cls, type, anns, contentType, new MetadataMap<String,
> Object>(r.getMetadata(), true, true), conn.getInputStream());
> } catch (Exception ex) {
> throw new WebApplicationException();
> }
>
> Few lines before is the status checked, in some cases (204) simply null is
> returned. So yes, client tries to read the body.
>
> I use CXF in cooperation with Spring, so I'm not sure, what exactly should
> I answer, so I will simply attach part o stacktrace:
> javax.ws.rs.WebApplicationException
> at
> org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:391)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:444)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:428)
> at
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:171)
> at $Proxy88.update(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
> at $Proxy95.update(Unknown Source)
> (lower in stacktrace is no important stuff)
>
> I tried the trick with IN interceptor and different phases, did not work...
> Which phase you think it should be? I tried to debug this, the status is
> taken from HttpURLConnection, can it be really overridden?
>
>
I'm fixing that right now, it's unfortunate HttpUrlConnection is used to
check the status there given that few lines earlier the status is taken from
the message. In 2.3.4 you'll be able to override the status.
The direct HttpUrlConnection dependency itself will be removed once the
async http conduit gets supported.
I think you can try the following at the moment. I can see the proxies are
injected from Spring, but the actual code where the invocations are made can
be handled like this:
@Resource
BookService proxy;
try {
return proxy.getIt();
} catch (WebApplicationException ex) {
Response response = WebClient.client(proxy).getResponse();
if (response.getStatus() == 200) {
return null;
}
throw ex;
}
Will it work for you ?
Sergey
> Thanks
>
> ====
>
> Greets
> > Tomasz
> >
>
AW: Changing response staus on the client side
Posted by "Glinski, Tomasz" <to...@capgemini.com>.
> Hi,
> I am writing a client to the server (no changes on server possible), that
> sends responses with no message body, with response status 200. CXF throws
> than WebApplicationException, as it expects status 204 in such situation.
> Is there a way to change the status "on-the-fly", before the response is
> parsed? Tried with interceptors, with no success...
>
>
Where is this WebApplicationException originating from ? Is client trying to
read the response body and fails ?
Do you use WebClient like this :
client.get(Book.class) ?
when the concrete type, as opposed to Response as expected, the runtime
thinks that the response stream has to be read. Can you try using Response,
say,
Response response = client.get();
?
CXF 2.3.3 has a ResponseReader utility class for reading Response entities
But you can also change the status from the custom *in* interceptor, do
message.getExchange().put(Message.RESPONSE_CODE, 204);
Cheers, Sergey
=========================================================================
Hi Sergey,
WebApplicationException comes from AbstractClient.readBody(), inside catch:
MessageBodyReader mbr = ProviderFactory.getInstance(inMessage).createMessageBodyReader(
try {
return mbr.readFrom(cls, type, anns, contentType, new MetadataMap<String, Object>(r.getMetadata(), true, true), conn.getInputStream());
} catch (Exception ex) {
throw new WebApplicationException();
}
Few lines before is the status checked, in some cases (204) simply null is returned. So yes, client tries to read the body.
I use CXF in cooperation with Spring, so I'm not sure, what exactly should I answer, so I will simply attach part o stacktrace:
javax.ws.rs.WebApplicationException
at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:391)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:444)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:428)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:171)
at $Proxy88.update(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at $Proxy95.update(Unknown Source)
(lower in stacktrace is no important stuff)
I tried the trick with IN interceptor and different phases, did not work... Which phase you think it should be? I tried to debug this, the status is taken from HttpURLConnection, can it be really overridden?
Thanks
====
Greets
> Tomasz
>
>
Capgemini Polska Sp. z o.o.,
ul. Piękna 18, 00-549 Warszawa
Sąd Rejonowy dla M.ST. Warszawy, XII Wydział Gospodarczy Rejestrowy, nr KRS: 0000040605
NIP: 526-11-84-467,
wysokość kapitału zakładowego: 16 397 097,00 ZŁ
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
Re: Changing response staus on the client side
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Tue, Mar 22, 2011 at 2:18 PM, Glinski, Tomasz <
tomasz.glinski@capgemini.com> wrote:
> Hi,
> I am writing a client to the server (no changes on server possible), that
> sends responses with no message body, with response status 200. CXF throws
> than WebApplicationException, as it expects status 204 in such situation.
> Is there a way to change the status "on-the-fly", before the response is
> parsed? Tried with interceptors, with no success...
>
>
Where is this WebApplicationException originating from ? Is client trying to
read the response body and fails ?
Do you use WebClient like this :
client.get(Book.class) ?
when the concrete type, as opposed to Response as expected, the runtime
thinks that the response stream has to be read. Can you try using Response,
say,
Response response = client.get();
?
CXF 2.3.3 has a ResponseReader utility class for reading Response entities
But you can also change the status from the custom *in* interceptor, do
message.getExchange().put(Message.RESPONSE_CODE, 204);
Cheers, Sergey
Greets
> Tomasz
>
>