You probably hit a bug in the SAAJ implementation where it doesn't really
parse thing completely until asked for, but the DOMSource stuff doesn't
ask for it in a way it expects. This MIGHT be fixed for 2.0.2 or
2.0.3-SNAPSHOT as I did add a bunch of "soapMsg.getEnvelope().getBody()"
calls in the code to force it to parse fully. Can you try the
2.0.3-SNAPSHOT and see if that helps?
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/apache-cxf/2.0.3-incubator-SNAPSHOT/
If not, I MAY be able to get a fix in place before 2.0.3 is released.
(couple days now)
Couple notes:
1) You could do:
SOAPMessage msg = smc.getMessage();
msg.getEnvelope().getBody();
if (!log.isTraceEnabled()) return;
That would probably fix it.
2) This is really a "slow" way of logging. You parse the XML, then
regenerate the XML by walking the tree, then we have to re-walk the tree
to deserialize, etc.... I'd suggest using the LoggingInInterceptor
(or at least look at the code and use that as a model) that we already
have that will log at the stream level.
Dan
On Wednesday 24 October 2007, Yeroc wrote:
> All...
>
> I've got a very puzzling problem issue with CXF v2.0.1. I implemented
> a SOAPHandler that logs all the SOAP messages being sent over the
> wire. It's very similar to the one that ships as an example in the
> CXF distribution except that I'm logging to a log4j Logger.
>
> What's strange is that in one case the behavior of my SOAP service
> changes depending on whether the logging is enabled or not! (The
> SOAPHandler itself is enabled always, just the logging of the messages
> is enabled/disabled at runtime.) Even stranger, is that when the
> logging is enabled the service is working fine, but when the logging
> is disabled, the service errors with an unmarshalling error (see
> below).
>
> Logging a SOAP message shouldn't be affecting the parsing of a message
> in any way. Here's the relevant code:
>
> private void log(SOAPMessageContext smc)
> {
> if (!log.isTraceEnabled()) return;
>
> Boolean outbound =
> (Boolean)smc.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
>
> SOAPMessage msg = smc.getMessage();
>
> try
> {
> if (outbound.booleanValue())
> { los.write(">\n".getBytes()); }
> else
> { los.write("<\n".getBytes()); }
> msg.writeTo(los);
> los.flush();
> }
> catch (Exception e)
> { log.error(e.getMessage(), e); }
> }
>
> It seems to me that either SOAPMessageContext.getMessage() or
> SOAPMessage.writeTo() must have some sort of sideaffect?!? Surely
> this can't be intended?
>
> Here's the error I'm getting when logging is NOT enabled (the code
> above returns on the initial if condition check):
>
> Oct 23, 2007 5:02:51 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error : Current state
> not START_ELEMENT or END_ELEMENT
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallArray(JAXBEncoderDeco
>der.java:443) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.j
>ava:256) at
> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:40)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralI
>nInterceptor.java:235) at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLi
>teralInInterceptor.java:121) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>rChain.java:207) at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
>tionObserver.java:73) at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletD
>estination.java:78) at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(S
>ervletController.java:231) at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletContr
>oller.java:139) at
> com.kelman.kws.v2.CXFServlet.invoke(CXFServlet.java:121) at
> com.kelman.kws.v2.CXFServlet.doPost(CXFServlet.java:92) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>cationFilterChain.java:252) at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>lterChain.java:173) at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
>lve.java:213) at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
>lve.java:178) at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
>va:126) at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
>va:105) at
> org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonA
>ccessLogValve.java:495) at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
>e.java:107) at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
>:148) at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
>869) at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.pr
>ocessConnection(Http11BaseProtocol.java:664) at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoi
>nt.java:527) at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFoll
>owerWorkerThread.java:80) at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
>ol.java:684) at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Current state not
> START_ELEMENT or END_ELEMENT
> at
> com.ctc.wstx.sr.BasicStreamReader.getName(BasicStreamReader.java:721)
> at
> org.apache.cxf.staxutils.DepthXMLStreamReader.getName(DepthXMLStreamRe
>ader.java:109) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallArray(JAXBEncoderDeco
>der.java:426) ... 28 more
>
> Does anyone have any ideas on what is going on?
>
> Thanks,
> Corey
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
