从Java 7上的Spring-WS客户端向Java 6上的服务器发送SOAP消息时,左尖括号被删除

时间:2012-05-06 01:28:23

标签: java soap bytearray spring-ws saaj

这对我来说真的很令人沮丧,所以我会尝试解释我所知道的,现在不要解释。请务必在帖子底部查看我的更新。

首先,我们有一场使用Spring-WS来处理消息的战争。我们还有一个使用WebServiceTemplate发送消息的客户端。我们在Tomcat 7上部署。

在我们当前的开发环境中,Tomcat 7服务器正在使用JRE 6u24。在本地,当我使用客户端发送SOAP消息时,我正在运行相同的版本。一切都按预期工作。

当我制作本地JRE 7u04时,我得到500响应,服务器看到以下错误:

[2012-05-05 20:19:13,179] DEBUG - org.springframework.web.servlet.FrameworkServlet.processRequest(671) | Could not complete request
org.springframework.ws.soap.saaj.SaajSoapEnvelopeException: Could not access envelope: Unable to create envelope from given source: ; nested exception is com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:
        at org.springframework.ws.soap.saaj.SaajSoapMessage.getSaajVersion(SaajSoapMessage.java:260)
        at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:342)
        at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:117)
        at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:184)
        at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:58)
        at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:90)
        at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:86)
        at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
        at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:222)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
        at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)
        at org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewrittenUrl.java:195)
        at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:159)
        at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
        at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
        at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:417)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:
        at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:127)
        at com.sun.xml.messaging.saaj.soap.ver1_2.SOAPPart1_2Impl.createEnvelopeFromSource(SOAPPart1_2Impl.java:84)
        at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:150)
        at org.springframework.ws.soap.saaj.support.SaajUtils.getSaajVersion(SaajUtils.java:155)
        at org.springframework.ws.soap.saaj.SaajSoapMessage.getSaajVersion(SaajSoapMessage.java:257)
        ... 39 more
Caused by: javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed.
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:501)
        at com.sun.xml.messaging.saaj.util.transform.EfficientStreamingTransformer.transform(EfficientStreamingTransformer.java:414)
        at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:118)
        ... 43 more
Caused by: org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed.
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1231)
        at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
        at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
        ... 45 more

我经历了很多潜在的问题。但是,我认为我已经在某些方面将其缩小为SAAJ问题。

在Spring-WS的SaajSoapMessageFactory类中,有一个方法以:

开头
public SaajSoapMessage createWebServiceMessage(InputStream inputStream) throws IOException {
        MimeHeaders mimeHeaders = parseMimeHeaders(inputStream);
        try {
            inputStream = checkForUtf8ByteOrderMark(inputStream);
            SOAPMessage saajMessage = messageFactory.createMessage(mimeHeaders, inputStream);
            postProcess(saajMessage);
            return new SaajSoapMessage(saajMessage, langAttributeOnSoap11FaultString, messageFactory);
        }

当我使用带有JRE 6的客户端发送时,createMessage调用之后的inputStream开始如下:

[60, 101, 110, 118, 58, 69, 110, 118, 101, 108, 111, 112, 101, 32, 120, 109, 108, 110, 115, 58, 101, 110, 118, 61, 34, 104, 116

转换为:<env:Envelope ...等等。

但是,当我使用JRE 7的客户端发送时,createMessage调用之后的inputStream开始如下:

[101, 110, 118, 58, 69, 110, 118, 101, 108, 111, 112, 101, 32, 120, 109, 108, 110, 115, 58, 101, 110, 118, 61, 34, 104, 116

正如您所看到的那样,第一个字节,左尖括号已经丢失。我一直试图调试它,但我缺乏com.sun.xml.internal源来真正做到很有效。

另外值得注意的是,在JRE 6中,checkForUtf8ByteOrderMark调用后的PushbackInputStream实际上看起来像最后的字节数组:

[60, 101, 110, 118, 58, 69, 110, 118, 101, 108, 111, 112, 101, 32, 120, 109, 108, 110, 115, 58, 101, 110, 118, 61, 34, 104, 116,

但是当使用JRE 7发送时,它看起来像这样:

[60, 0, 0, 0, 0, 0, 0, 0, 0

现在,该方法本身似乎遵循相同的流程,验证没有BOM,然后放回它开始验证它(至少,所以它在我看来)。

所以,我有两个问题:

1)有谁知道发生了什么事?这里有什么响铃的吗?

2)如何获取这些com.sun.xml.internal包的源代码?

我应该注意,我可以在Eclipse上运行本地Tomcat并且似乎没有任何问题,但我知道有一些时髦的类加载可能会发生在那里。

更新1:

我能够将一些源与代码相关联,并在SOAPPart1_2Impl中使用此方法:

   public void setContent(Source source) throws SOAPException {
        try {
            if (source instanceof StreamSource) {
                InputStream is = ((StreamSource) source).getInputStream();
                Reader rdr = ((StreamSource) source).getReader();

                if (is != null) {
                    this.source = new JAXMStreamSource(is);
                } else if (rdr != null) {
                    this.source = new JAXMStreamSource(rdr);
                } else {
                    log.severe("SAAJ0544.soap.no.valid.reader.for.src");
                    throw new SOAPExceptionImpl("Source does not have a valid Reader or InputStream");
                }
            }

现在,它需要设置InputStream的第一条路径。非常有趣的是,当这个完成时,source有一个以这样开头的ByteInputStream:

[60, 0, 0, 101, 110, 118, 58, 69, 110, 118, 101, 108, 111, 112, 101, 32, 120, 109, 108, 110, 115, 58, 101,

我很困惑。我将试着弄清楚那些第一个三个字符到底发生了什么 - 也许对checkForUtf8ByteOrderMark方法有一些副作用。

更新2:

好的,现在我真的到了某个地方。我调查了那个JAXMStreamSource类,它导致了一个ByteOutputStream类,它有一个方法:

public void write(InputStream in) throws IOException {
    if (in instanceof ByteArrayInputStream) {
        int size = in.available();
        ensureCapacity(size);
        count += in.read(buf,count,size);
        return;
    }
    while(true) {
        int cap = buf.length-count;
        int sz = in.read(buf,count,cap);
        if(sz<0)    return;     // hit EOS

        count += sz;
        if(cap==sz)
            // the buffer filled up. double the buffer
            ensureCapacity(count);
    }
}

在行“int sz = in.read(buf,count,cap);”是添加60之后的两个零的位置。我仍在试图弄清楚为什么以及为什么使用1.7的客户可能会产生这种影响。

2 个答案:

答案 0 :(得分:4)

升级到2.0.4.RELEASE以某种方式解决了这个问题。 checkForUtf8ByteOrderMark方法没有改变,但其他内容必须已经改变,因为之后流进来的内容看起来不同。

答案 1 :(得分:3)

  

也许对checkForUtf8ByteOrderMark有一些副作用   方法

我认为你可能是对的

https://jira.springsource.org/browse/SWS-750