[SWS-457] AxiomSoapMessageFactory payloadCaching=false causes org.springframework.ws.soap.axiom.AxiomSoapEnvelope.getBody() to fail Created: 08/Dec/08  Updated: 04/May/12  Resolved: 21/Dec/08

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: 1.5.5
Fix Version/s: 1.5.6

Type: Bug Priority: Major
Reporter: Nikkeri2001 Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Spring 2.5.6, Windows xp, Jetty 6.1.11, apache.axiom 1.2.7, Soap UI, saaj-api and saaj-impl 1.3, jaxen 1.1


Attachments: Zip Archive echo.zip     Zip Archive nikkeri_echo.zip     JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    

 Description   

http://forum.springframework.org/showthread.php?t=64350

Hello,

I have problem with AxiomSoapMessageFactory payloadCaching=false.

Spring config is simple as this:

<bean id="messageFactory" class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory">
  <property name="payloadCaching" value="false"/>
</bean>
 
<bean class="org.springframework.ws.soap.server.endpoint.mapping.SoapActionEndpointMapping">
  <property name="mappings">
    <props>
      <prop key="SoapAction1">endpoint1</prop>
    </props>
  </property>
</bean>
 
<bean id="wsdl" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
  <property name="schema" ref="schema" />
  <property name="portTypeName" value="resource1" />
  <property name="locationUri" value="/service1/" />
  <property name="targetNamespace" value="my.service" />
  <property name="soapActions">
    <props>
      <prop key="UploadAddressMaterial">SoapAction1</prop>
    </props>
  </property>
</bean>
 
<bean id="schema" class="org.springframework.xml.xsd.SimpleXsdSchema ">
  <property name="xsd" value="/WEB-INF/schema.xsd" />
</bean>

I'm not using any kind of interceptors.

Actual ws end point extends AbstractStaxStreamPayloadEndpoint but the request doesn't get that far.

I get exception "com.sun.jdi.InvocationException occurred invoking method." when trying to invoke the web service in method org.springframework.ws.soap.axiom.AxiomSoapEnvelope.getBody().

Line 59 SOAPBody axiomBody = getAxiomEnvelope().getBody(); fails some how and the OMException on line 71 is catched. This leads to:

"Nested in org.springframework.ws.soap.axiom.AxiomSoapMessage Exception: Could not write message to OutputStream: problem accessing the parser. Parser already accessed!; nested exception is javax.xml.stream.XMLStreamException: problem accessing the parser. Parser already accessed!:
java.lang.IllegalStateException: Parser already accessed! "

I am running spring ws v.1.5.5 and spring core 2.5.6.

Everything works fine if payloadCaching is true.

Is this a bug? There is a resolved Jira that looks much the same: id SWS-359



 Comments   
Comment by Arjen Poutsma [ 09/Dec/08 ]

Can you supply the complete stack trace, please? As attachment or comment?

Comment by Nikkeri2001 [ 16/Dec/08 ]

I commented out all MessageTracing from log4j.properties and stream reading works now.
Allso the org.springframework debuging must be turned off because the MessageDispatcher logs the incoming request and that ruins everything.

My log4j.properties file is now like this.

  1. Spring ws
    #log4j.logger.org.springframework.ws.client.Messag eTracing.sent=DEBUG
    #log4j.logger.org.springframework.ws.client.Messag eTracing.received=DEBUG
    #log4j.logger.org.springframework.ws.server.Messag eTracing=DEBUG
  1. Spring
    log4j.logger.org.springframework=INFO

Stream reading started to work but the sream writing still didn't work. My reply from this service was allmost empty like this:

<soapenv:Envelope xmlns:soapenv="shemaUrl">
<soapenv:Body/>
</soapenv:Envelope>

When payloadCache is false the streamWriter is made like this: TraxUtils.getXMLStreamWriter(result);
When payloadCache is true the streamWriter is made like this: getOutputFactory().createXMLStreamWriter(result);

So i changed the AbstractStaxStreamPayloadEndpoint getStreamWriter method to this:

    private XMLStreamWriter getStreamWriter(Result result) {
        XMLStreamWriter streamWriter = null;
        /*if (TraxUtils.isStaxResult(result)) {
            streamWriter = TraxUtils.getXMLStreamWriter(result);
        }*/
        //if (streamWriter == null) {
            try {
                streamWriter = getOutputFactory().createXMLStreamWriter(result);
            }
            catch (XMLStreamException ex) {
                // ignore
            }
        //}
        return streamWriter;
    }

And this solved the problem... The response is not empty anymore.

In which case should this TraxUtils.getXMLStreamWriter(result) method work and could this AbstractStaxStreamPayloadEndpoint operate like in code above?
is this a bug in spring-ws source?
Should the log4j debug work with spring-ws when payloadCache is false?

Nikkeri

Comment by Nikkeri2001 [ 16/Dec/08 ]

Ok, the code is formatted very fuzzy in this jira...

In short this line is used allvays: streamWriter = getOutputFactory().createXMLStreamWriter(result)
this line is used never: streamWriter = TraxUtils.getXMLStreamWriter(result)

Nikkeri

Comment by Arjen Poutsma [ 18/Dec/08 ]

I've improved the workings of the Axiom support. Could you try a recent snapshot (http://static.springframework.org/spring-ws/sites/1.5/downloads/snapshots.html) and see if that works better?

Comment by Nikkeri2001 [ 18/Dec/08 ]

I took spanshot jars from spring-ws-1.5.6-20081219.020020-20-minimal.zip. http://static.springframework.org/spring-ws/downloads/1.5-snapshot-download.php
<url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url> doesn't work with my maven build. No jars with 1.5.6-SNAPSHOT don't know why.

How ever I can't see any progression here.

1.Incoming request explodes if there is a log4j config is like log4j.logger.org.springframework.ws.server.MessageTracing=INFO.

2. Reply is still empty. There must be some streamWriter issue. This works well if payloadCachi is true.

Comment by Arjen Poutsma [ 19/Dec/08 ]

That is very strange. I have tested this locally, on a modified echo sample, and everything seems OK for me. I will attach the sample, the changes are in StreamingEchoEndpoint and spring-ws-servlet.xml.

Are you sure you're not running an older version of Spring-WS perhaps? Because I know there were issues with this in the past...

Comment by Nikkeri2001 [ 19/Dec/08 ]

Hello and thank you for your test project.

I tested echo program and it didn't work either. It works exactly like my own programs with spring ws 1.5.5. When payload caching is false the reply is empty. When caching is true everything works fine.

I just couldn't run the echo project as is because my maven didn't accept the pom.xml directly. So I had to did some modifications to pom.xml to get it compiled and run in Jetty. This leads me to conclusion this must be some dependency related problem. If you could please try my version of this project and tell me what is your conclusion. Please let your maven find all the dependecys to make sure that the spring ws version in snapshot repo is the right one. The .classpath file is also included so you can compare it to yours.

I will attach my version of the echo-program so you will se what dependency causes this problem.

Thank you very much of your efforts so far.

Nikkeri

p.s one missing library 'woodstox-core-asl-3.9.9-1.jar' is located in echo/lib folder. Maven can not find this library from common repository. Only sources are available at the moment.

Comment by Nikkeri2001 [ 19/Dec/08 ]

SoapUI test with empty reply.

Comment by Tareq Abedrabbo [ 21/Dec/08 ]

There was an issue with the snapshot builds. Now that the issue is fixed, would you please try a recent snapshot to see if this fixes the issue for you?

Comment by Nikkeri2001 [ 21/Dec/08 ]

Echo works now!
This is so fantacstic! Thank you guys.

So the problem was I couldn't get the latest version of Spring-ws from the snapshot repository.

Nikkeri

Comment by Arjen Poutsma [ 21/Dec/08 ]

Great!

Once again, sorry about the snapshot issue, but it's good that it has been resolved now.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sat Dec 16 13:00:26 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.