This indeed looks like a bug to me. I vaguely recalled that I once ran into a 
weird problem with SAAJ impl, which is that in some cases SOAPBody() wont be 
not properly initialized until SOAPMessage.writeTo() or some other similar 
methods are called. I guess what might happen is that CXF creates a STAX 
XMLStreamReader on top of a DOMSource which is in turn created from SOAPBody, 
this STAX wont have valid data to read until someone called 
SOAPMessage.writeTo(). Anyway, just a guess, could you please log a JIRA with 
your test case attached, I will take a deep look into this.

Thanks,
Jervis

> -----Original Message-----
> From: Yeroc [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?25? 5:37
> To: [email protected]
> Subject: Unintended Consequences...
> 
> 
> 
> 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(JAXBEnc
> oderDecoder.java:443)
>         at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderD
> ecoder.java:256)
>         at
> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:40)
>         at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(Doc
> LiteralInInterceptor.java:235)
>         at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessa
> ge(DocLiteralInInterceptor.java:121)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
> terceptorChain.java:207)
>         at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
> inInitiationObserver.java:73)
>         at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
> ServletDestination.java:78)
>         at
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:231)
>         at
> org.apache.cxf.transport.servlet.ServletController.invoke(Serv
> letController.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.internalDoFilt
> er(ApplicationFilterChain.java:252)
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilterChain.java:173)
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.java:213)
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.java:178)
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:126)
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:105)
>         at
> org.apache.catalina.valves.FastCommonAccessLogValve.invoke(Fas
> tCommonAccessLogValve.java:495)
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java:107)
>         at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
> ter.java:148)
>         at
> org.apache.coyote.http11.Http11Processor.process(Http11Process
> or.java:869)
>         at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHa
> ndler.processConnection(Http11BaseProtocol.java:664)
>         at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolT
> cpEndpoint.java:527)
>         at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(Le
> aderFollowerWorkerThread.java:80)
>         at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.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.ja
> va:721) at
> org.apache.cxf.staxutils.DepthXMLStreamReader.getName(DepthXML
> StreamReader.java:109)
>         at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallArray(JAXBEnc
> oderDecoder.java:426)
>         ... 28 more
> 
> Does anyone have any ideas on what is going on?
> 
> Thanks,
> Corey
> -- 
> View this message in context: 
http://www.nabble.com/Unintended-Consequences...-tf4687206.html#a13395660
Sent from the cxf-user mailing list archive at Nabble.com.

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Reply via email to