You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ronald Pieterse <ro...@gmail.com> on 2010/06/11 22:08:31 UTC
Response object is null
Hi people.
I have a problem I need to tackle pretty soon so I hope someone can give
some pointers here.
My client would like to see normal responses, even when exceptions have
occurred.
I'm trying to change the thrown exceptions into custom response objects
which are not extending Fault.
So actually I would like to change an exception outgoing flow into a normal
flow that returns some response object.
What I have done so far is (and I'm not sure this is the right way):
1. I created an outgoing fault interceptor that removes the exception from
the content:
message.removeContent(Exception.class);
2. I removed the existing Fault interceptors from the interceptor chain (not
sure if that is necessary though) which are
WebFaultOutInterceptor, SoapOutInterceptor, Soap11FaultOutInterceptor,
Soap12FaultOutInterceptor
3. and then I set some new content in the exchange:
Message newMessage = new MessageImpl();
message.getExchange().setInMessage(newMessage);
message.getExchange().put("exchange.finished", Boolean.TRUE);
newMessage.setExchange(message.getExchange());
message.setContent(List.class, Arrays.asList(new String[] { "result" }));
Now when I check I see that the exception is indeed gone and the new content
exists in the defaultContent of the message.
However I get the following exception when I invoke my call:
2010-06-11 21:52:43,042 INFO [FaultTransformationInterceptor] - Intercepted
by FaultTransformationInterceptor!
2010-06-11 21:52:43,043 WARN [AbstractHTTPDestination] - Response object is
null
2010-06-11 21:52:43,043 WARN [PhaseInterceptorChain] - Interceptor for
{namespace}ContactService#{namespace}countByContactDatabaseId has thrown
exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:292)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:730)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:649)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.io.IOException: Response object is null
at
org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:550)
at
org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.close(AbstractHTTPDestination.java:643)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at
org.apache.cxf.transport.http.AbstractHTTPDestination$BackChannelConduit.close(AbstractHTTPDestination.java:592)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 20 more
--
View this message in context: http://old.nabble.com/Response-object-is-null-tp28859579p28859579.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Response object is null
Posted by Ronald Pieterse <ro...@gmail.com>.
Ah yes, simple but effective. Thanks for all your help the past week.
Greetz,
Ronald
dkulp wrote:
>
> On Friday 18 June 2010 5:24:01 am Ronald Pieterse wrote:
>> Hi Dan,
>>
>> I got it working! It turned out to be as simple as giving all the
>> webresults the same name ('response') and in case of an exception I wrap
>> the response with an extra
>> wrapper class also called 'response'.
>> Now all the messages arrive in the same format at the client - whether
>> they
>> originated as exception or normal response.
>>
>> The only thing I struggled with (and I'm still not happy with the
>> solution)
>> is the way I had to get the extra wrapper in my schema.
>> Probably since it is not directly used in one of my calls it is not
>> appearing in my schema. So now I created a dummy call to force it to
>> show.
>> This feels a bit like a hack and now I have a call that does nothing. Is
>> there a way to force the appearance of the object in my schema by itself?
>
> Stick an @XmlSeeAlso annotation on the SEI that points at the class.
> That
> should add it to the schema.
>
> Dan
>
--
View this message in context: http://old.nabble.com/Response-object-is-null-tp28859579p28930134.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Response object is null
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 18 June 2010 5:24:01 am Ronald Pieterse wrote:
> Hi Dan,
>
> I got it working! It turned out to be as simple as giving all the
> webresults the same name ('response') and in case of an exception I wrap
> the response with an extra
> wrapper class also called 'response'.
> Now all the messages arrive in the same format at the client - whether they
> originated as exception or normal response.
>
> The only thing I struggled with (and I'm still not happy with the solution)
> is the way I had to get the extra wrapper in my schema.
> Probably since it is not directly used in one of my calls it is not
> appearing in my schema. So now I created a dummy call to force it to show.
> This feels a bit like a hack and now I have a call that does nothing. Is
> there a way to force the appearance of the object in my schema by itself?
Stick an @XmlSeeAlso annotation on the SEI that points at the class. That
should add it to the schema.
Dan
>
> dkulp wrote:
> > You may need to debug into the CXF code to figure out what is going on
> > for this. I'm not really sure without a full example. In
> > particular, look at
> > the WrapperClassOutInterceptor and the WrappedOutInterceptor. With
> > JAX-WS
> > frontend, the first interceptor above should take your object and wrapper
> > it
> > with a new (possibly generated in memory) JAXB object that would handle
> > the
> > wrapper element. Non-jaxws would fall into WrappedOutInterceptor to
> > force it.
> >
> > Dan
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Response object is null
Posted by Ronald Pieterse <ro...@gmail.com>.
Hi Dan,
I got it working! It turned out to be as simple as giving all the webresults
the same name ('response') and in case of an exception I wrap the response
with an extra
wrapper class also called 'response'.
Now all the messages arrive in the same format at the client - whether they
originated as exception or normal response.
The only thing I struggled with (and I'm still not happy with the solution)
is the way I had to get the extra wrapper in my schema.
Probably since it is not directly used in one of my calls it is not
appearing in my schema. So now I created a dummy call to force it to show.
This feels a bit like a hack and now I have a call that does nothing. Is
there a way to force the appearance of the object in my schema by itself?
dkulp wrote:
>
>
> You may need to debug into the CXF code to figure out what is going on for
> this. I'm not really sure without a full example. In particular, look
> at
> the WrapperClassOutInterceptor and the WrappedOutInterceptor. With
> JAX-WS
> frontend, the first interceptor above should take your object and wrapper
> it
> with a new (possibly generated in memory) JAXB object that would handle
> the
> wrapper element. Non-jaxws would fall into WrappedOutInterceptor to force
> it.
>
> Dan
>
--
View this message in context: http://old.nabble.com/Response-object-is-null-tp28859579p28922586.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Response object is null
Posted by Daniel Kulp <dk...@apache.org>.
You may need to debug into the CXF code to figure out what is going on for
this. I'm not really sure without a full example. In particular, look at
the WrapperClassOutInterceptor and the WrappedOutInterceptor. With JAX-WS
frontend, the first interceptor above should take your object and wrapper it
with a new (possibly generated in memory) JAXB object that would handle the
wrapper element. Non-jaxws would fall into WrappedOutInterceptor to force it.
Dan
On Sunday 13 June 2010 4:57:28 pm Ronald Pieterse wrote:
> Hi Dan,
>
> That helped me a lot, thanks! I have a custom response object so the path
> from fault chain to normal chain is working like a charm. There is only one
> issue left that showed up with the fix ;-)
>
> The call I do is getByContactDatabaseId which, if correct should return the
> following xml:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <api-version>3.2.1</api-version>
> </soap:Header>
> <soap:Body>
> <ns2:getByContactDatabaseIdResponse
> xmlns:ns2="http://services.tripolis.com/">
> <getByContactDatabaseIdResponse>
> <responseStatus>
> <code>200</code>
> <messageLanguage>en</messageLanguage>
> <message>This is a great message</message>
> </responseStatus>
> </getByContactDatabaseIdResponse>
> </ns2:getByContactDatabaseIdResponse>
> </soap:Body>
> </soap:Envelope>
>
> In Java this is the following object graph:
>
> GetContactsByIdResponse (@XmlType(name = "GetContactsByIdResponse") -> in
> the interface it's named 'getByContactDatabaseIdResponse'
> ResponseStatus
> code
> messageLanguage
> Message
>
> but when I return my custom response (instead of the fault), which is set
> up identically I get this format:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <api-version>3.2.1</api-version>
> </soap:Header>
> <soap:Body>
> <ns2:getByContactDatabaseIdResponse
> xsi:type="ns2:GetContactsByIdResponse"
> xmlns:ns2="http://services.tripolis.com/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <!-- missing start tag for 'getByContactDatabaseIdResponse' -->
> <responseStatus>
> <code>666</code>
> <messageLanguage>en</messageLanguage>
> <message>This is not such a great message</message>
> </responseStatus>
> <!-- missing end tag for 'getByContactDatabaseIdResponse' -->
> </ns2:getByContactDatabaseIdResponse>
> </soap:Body>
> </soap:Envelope>
>
> as you can see there are 3 changes in this response. The open and close
> tags for the object getByContactDatabaseIdResponse
> are missing and the ns2:getByContactDatabaseIdResponse line is different.
> Is there something I forgot to set in my custom OutgoingChainInterceptor?
>
> The relevant code is now like this:
>
> message.getInterceptorChain().pause();
>
> Endpoint ep = ex.get(Endpoint.class); // ex is exchange
> Message outMessage = new MessageImpl();
> outMessage.setExchange(ex);
> outMessage = ep.getBinding().createMessage(outMessage);
> ex.setOutMessage(outMessage);
>
> // here I set up my custom response object (for now it's the
> GetContactsByIdResponse object hardcoded)
> GetContactsByIdResponse response = new GetContactsByIdResponse();
> // in service interface this response object is named
> 'getByContactDatabaseIdResponse'
> response.setResponseStatus(new
> ResponseStatus(ResponseStatusCode.USER_ERROR));
> response.addError(new
> ServiceError().setCode(ErrorCode.VALIDATION_ERROR.getCode())
> .setMessage("Something went wrong before
> service method invocation"));
> MessageContentsList resultList = new
> MessageContentsList(Arrays.asList(new GetContactsByIdResponse[] { response
> }));
>
> // prepare new message and start chain
> outMessage.setContent(List.class, resultList);
> outMessage.setInterceptorChain(getOutInterceptorChain(ex)); //
set
> new interceptor chain
> outMessage.getInterceptorChain().doIntercept(outMessage);
>
> This issue is a problem while unmarshalling on the client. Running my
> testcase I get the following exception:
>
> 2010-06-13 22:50:34,972 WARN [PhaseInterceptorChain] - Interceptor for
> {http://services.tripolis.com/}ContactServiceService#{http://services.tripo
> lis.com/}getByContactDatabaseId has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element
> (uri:"", local:"responseStatus"). Expected elements are
> <{}getByContactDatabaseIdResponse>
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 73) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:6
> 24) at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteral
> InInterceptor.java:109) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:700) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
> eInternal(HTTPConduit.java:2261) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
> e(HTTPConduit.java:2134) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCon
> duit.java:1988) at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639) at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
> rceptor.handleMessage(MessageSenderInterceptor.java:62) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265) at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) at
> $Proxy54.getByContactDatabaseId(Unknown Source)
> at
> com.tripolis.services.client.ServiceTest.invokeClientNullAuthInfo(ServiceTe
> st.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
> 9) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
> l.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:607)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:517)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:669)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:956)
> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.jav
> a:126) at
> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110) at
> org.testng.TestRunner.runWorkers(TestRunner.java:759)
> at org.testng.TestRunner.privateRun(TestRunner.java:592)
> at org.testng.TestRunner.run(TestRunner.java:486)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
> at org.testng.SuiteRunner.run(SuiteRunner.java:204)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:877)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:842)
> at org.testng.TestNG.run(TestNG.java:751)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> Caused by: javax.xml.bind.UnmarshalException
> - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element (uri:"",
> local:"responseStatus"). Expected elements are
> <{}getByContactDatabaseIdResponse>]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamExcep
> tion(UnmarshallerImpl.java:425) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unmars
> hallerImpl.java:362) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(Unmarsh
> allerImpl.java:339) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 55) ... 41 more
> Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"",
> local:"responseStatus"). Expected elements are
> <{}getByContactDatabaseIdResponse>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(U
> nmarshallingContext.java:642) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254
> ) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:249
> ) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElemen
> t(Loader.java:116) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:10
> 1) at
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(Struc
> tureLoader.java:245) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:478) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(
> UnmarshallingContext.java:459) at
> com.sun.xml.bind.v2.runtime.unmarshaller.MTOMDecorator.startElement(MTOMDec
> orator.java:107) at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartEle
> ment(StAXStreamConnector.java:242) at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStr
> eamConnector.java:176) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unmars
> hallerImpl.java:360) ... 43 more
> Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"",
> local:"responseStatus"). Expected elements are
> <{}getByContactDatabaseIdResponse>
> ... 55 more
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Response object is null
Posted by Ronald Pieterse <ro...@gmail.com>.
Hi Dan,
That helped me a lot, thanks! I have a custom response object so the path
from fault chain to normal chain is working like a charm. There is only one
issue left that showed up with the fix ;-)
The call I do is getByContactDatabaseId which, if correct should return the
following xml:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<api-version>3.2.1</api-version>
</soap:Header>
<soap:Body>
<ns2:getByContactDatabaseIdResponse
xmlns:ns2="http://services.tripolis.com/">
<getByContactDatabaseIdResponse>
<responseStatus>
<code>200</code>
<messageLanguage>en</messageLanguage>
<message>This is a great message</message>
</responseStatus>
</getByContactDatabaseIdResponse>
</ns2:getByContactDatabaseIdResponse>
</soap:Body>
</soap:Envelope>
In Java this is the following object graph:
GetContactsByIdResponse (@XmlType(name = "GetContactsByIdResponse") -> in
the interface it's named 'getByContactDatabaseIdResponse'
ResponseStatus
code
messageLanguage
Message
but when I return my custom response (instead of the fault), which is set up
identically I get this format:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<api-version>3.2.1</api-version>
</soap:Header>
<soap:Body>
<ns2:getByContactDatabaseIdResponse
xsi:type="ns2:GetContactsByIdResponse"
xmlns:ns2="http://services.tripolis.com/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- missing start tag for 'getByContactDatabaseIdResponse' -->
<responseStatus>
<code>666</code>
<messageLanguage>en</messageLanguage>
<message>This is not such a great message</message>
</responseStatus>
<!-- missing end tag for 'getByContactDatabaseIdResponse' -->
</ns2:getByContactDatabaseIdResponse>
</soap:Body>
</soap:Envelope>
as you can see there are 3 changes in this response. The open and close tags
for the object getByContactDatabaseIdResponse
are missing and the ns2:getByContactDatabaseIdResponse line is different.
Is there something I forgot to set in my custom OutgoingChainInterceptor?
The relevant code is now like this:
message.getInterceptorChain().pause();
Endpoint ep = ex.get(Endpoint.class); // ex is exchange
Message outMessage = new MessageImpl();
outMessage.setExchange(ex);
outMessage = ep.getBinding().createMessage(outMessage);
ex.setOutMessage(outMessage);
// here I set up my custom response object (for now it's the
GetContactsByIdResponse object hardcoded)
GetContactsByIdResponse response = new GetContactsByIdResponse();
// in service interface this response object is named
'getByContactDatabaseIdResponse'
response.setResponseStatus(new
ResponseStatus(ResponseStatusCode.USER_ERROR));
response.addError(new
ServiceError().setCode(ErrorCode.VALIDATION_ERROR.getCode())
.setMessage("Something went wrong before
service method invocation"));
MessageContentsList resultList = new
MessageContentsList(Arrays.asList(new GetContactsByIdResponse[] { response
}));
// prepare new message and start chain
outMessage.setContent(List.class, resultList);
outMessage.setInterceptorChain(getOutInterceptorChain(ex)); // set
new interceptor chain
outMessage.getInterceptorChain().doIntercept(outMessage);
This issue is a problem while unmarshalling on the client. Running my
testcase I get the following exception:
2010-06-13 22:50:34,972 WARN [PhaseInterceptorChain] - Interceptor for
{http://services.tripolis.com/}ContactServiceService#{http://services.tripolis.com/}getByContactDatabaseId
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element
(uri:"", local:"responseStatus"). Expected elements are
<{}getByContactDatabaseIdResponse>
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:773)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:624)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:700)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2261)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2134)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1988)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy54.getByContactDatabaseId(Unknown Source)
at
com.tripolis.services.client.ServiceTest.invokeClientNullAuthInfo(ServiceTest.java:31)
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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:607)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:517)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:669)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:956)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110)
at org.testng.TestRunner.runWorkers(TestRunner.java:759)
at org.testng.TestRunner.privateRun(TestRunner.java:592)
at org.testng.TestRunner.run(TestRunner.java:486)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:877)
at org.testng.TestNG.runSuitesLocally(TestNG.java:842)
at org.testng.TestNG.run(TestNG.java:751)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.bind.UnmarshalException: unexpected element (uri:"",
local:"responseStatus"). Expected elements are
<{}getByContactDatabaseIdResponse>]
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:755)
... 41 more
Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"",
local:"responseStatus"). Expected elements are
<{}getByContactDatabaseIdResponse>
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:642)
at
com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254)
at
com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:249)
at
com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
at
com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:101)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:245)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:478)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at
com.sun.xml.bind.v2.runtime.unmarshaller.MTOMDecorator.startElement(MTOMDecorator.java:107)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:242)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:176)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
... 43 more
Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"",
local:"responseStatus"). Expected elements are
<{}getByContactDatabaseIdResponse>
... 55 more
--
View this message in context: http://old.nabble.com/Response-object-is-null-tp28859579p28873914.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Response object is null
Posted by Daniel Kulp <dk...@apache.org>.
On Saturday 12 June 2010 4:14:06 pm Ronald Pieterse wrote:
> Hi Dan,
>
> The first part of your reply was pretty straightforward. I created my own
> version of OutgoingChainInterceptor and at the end of handleMessage
> I did:
>
> message.getInterceptorChain().pause();
>
> This stops the current chain, right? Now I still created my new response,
> put that inside the message content.
> Now comes the bit I don't quite understand how to do. I put the interceptor
> in the SETUP phase, was that correct?
Sounds right.
> Also, how to pause the fault chain is unclear to me. The current chain IS
> the fault chain, isn't it?
Yep. So the line you put above is correct to pause it.
>
> What happens now when I invoke my call is, that my custom
> OutgoingChainInterceptor is reached but it ends there. I tried resuming the
> chain but that just shows the 'response object is null' exception which
> seems kind of logical since this is the same chain as I understand :-)
>
> Maybe you could provide me with an example on how to make this interceptor
> change from fault chain to normal chain and handle the reponse as normal
> response?
Ah. I see the confusion..
Around line 65, you see that the OutgoingChainInterceptor grabs the out
message from the exchange and then sets up the outgoing chain and has that
chain process that message.
In your case, it's likely that the out message is null since the fault was
thrown before it would have set that up. Take a look at the block that stars
around line 64 of the ServiceInvokerInterceptor (same package). That's
where the out message would normally be setup. Obviously, the
MessageContentsList that it sticks in that message would contain your custom
result bean.
Dan
> Thanx so far!
>
> Ronald
>
> dkulp wrote:
> > What you may want to try is take the code for the
> > OutgoingChainInterceptor from:
> >
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > e/cxf/interceptor/OutgoingChainInterceptor.java
> >
> > And pretty much duplicate it. the only addition would be to, at the very
> > end, grab the current chain and pause it. Stick it as the FIRST
> > interceptor
> > on the Fault chain. That should work fine as you would be setting up
> > an outgoing chain exactly like the normal responses. Don't forget to
> > stop/pause
> > the fault chain so it then doesn't try sending a fault as well. ;-)
> >
> > Dan
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Response object is null
Posted by Ronald Pieterse <ro...@gmail.com>.
Hi Dan,
The first part of your reply was pretty straightforward. I created my own
version of OutgoingChainInterceptor and at the end of handleMessage
I did:
message.getInterceptorChain().pause();
This stops the current chain, right? Now I still created my new response,
put that inside the message content.
Now comes the bit I don't quite understand how to do. I put the interceptor
in the SETUP phase, was that correct?
Also, how to pause the fault chain is unclear to me. The current chain IS
the fault chain, isn't it?
What happens now when I invoke my call is, that my custom
OutgoingChainInterceptor is reached but it ends there. I tried resuming the
chain but that just shows the 'response object is null' exception which
seems kind of logical since this is the same chain as I understand :-)
Maybe you could provide me with an example on how to make this interceptor
change from fault chain to normal chain and handle the reponse as normal
response?
Thanx so far!
Ronald
dkulp wrote:
>
>
> What you may want to try is take the code for the OutgoingChainInterceptor
> from:
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/OutgoingChainInterceptor.java
>
> And pretty much duplicate it. the only addition would be to, at the very
> end, grab the current chain and pause it. Stick it as the FIRST
> interceptor
> on the Fault chain. That should work fine as you would be setting up an
> outgoing chain exactly like the normal responses. Don't forget to
> stop/pause
> the fault chain so it then doesn't try sending a fault as well. ;-)
>
> Dan
>
--
View this message in context: http://old.nabble.com/Response-object-is-null-tp28859579p28867215.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Response object is null
Posted by Daniel Kulp <dk...@apache.org>.
What you may want to try is take the code for the OutgoingChainInterceptor
from:
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/OutgoingChainInterceptor.java
And pretty much duplicate it. the only addition would be to, at the very
end, grab the current chain and pause it. Stick it as the FIRST interceptor
on the Fault chain. That should work fine as you would be setting up an
outgoing chain exactly like the normal responses. Don't forget to stop/pause
the fault chain so it then doesn't try sending a fault as well. ;-)
Dan
On Friday 11 June 2010 4:08:31 pm Ronald Pieterse wrote:
> Hi people.
>
> I have a problem I need to tackle pretty soon so I hope someone can give
> some pointers here.
> My client would like to see normal responses, even when exceptions have
> occurred.
> I'm trying to change the thrown exceptions into custom response objects
> which are not extending Fault.
> So actually I would like to change an exception outgoing flow into a normal
> flow that returns some response object.
>
> What I have done so far is (and I'm not sure this is the right way):
>
> 1. I created an outgoing fault interceptor that removes the exception from
> the content:
>
> message.removeContent(Exception.class);
>
> 2. I removed the existing Fault interceptors from the interceptor chain
> (not sure if that is necessary though) which are
> WebFaultOutInterceptor, SoapOutInterceptor, Soap11FaultOutInterceptor,
> Soap12FaultOutInterceptor
>
> 3. and then I set some new content in the exchange:
>
> Message newMessage = new MessageImpl();
> message.getExchange().setInMessage(newMessage);
> message.getExchange().put("exchange.finished", Boolean.TRUE);
> newMessage.setExchange(message.getExchange());
> message.setContent(List.class, Arrays.asList(new String[] { "result"
}));
>
> Now when I check I see that the exception is indeed gone and the new
> content exists in the defaultContent of the message.
> However I get the following exception when I invoke my call:
>
> 2010-06-11 21:52:43,042 INFO [FaultTransformationInterceptor] - Intercepted
> by FaultTransformationInterceptor!
> 2010-06-11 21:52:43,043 WARN [AbstractHTTPDestination] - Response object is
> null
> 2010-06-11 21:52:43,043 WARN [PhaseInterceptorChain] - Interceptor for
> {namespace}ContactService#{namespace}countByContactDatabaseId has thrown
> exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
> rceptor.handleMessage(MessageSenderInterceptor.java:64) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(Ab
> stractFaultChainInitiatorObserver.java:99) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:292) at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
> bserver.java:110) at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestinati
> on.java:98) at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servle
> tController.java:423) at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController
> .java:178) at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServl
> et.java:142) at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abstract
> HTTPServlet.java:179) at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPSer
> vlet.java:103) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPSe
> rvlet.java:159) at
> com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.j
> ava:103) at
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:
> 187) at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java
> :265) at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273) at
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:682) at
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:730)
> at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:649)
> at java.lang.Thread.run(Thread.java:637)
> Caused by: java.io.IOException: Response object is null
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(Abstract
> HTTPDestination.java:550) at
> org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.c
> lose(AbstractHTTPDestination.java:643) at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at
> org.apache.cxf.transport.http.AbstractHTTPDestination$BackChannelConduit.cl
> ose(AbstractHTTPDestination.java:592) at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
> rceptor.handleMessage(MessageSenderInterceptor.java:62) ... 20 more
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog