Attribute “xmlns:ns2” was already specified for element …

Hi, all:

It is surely cold here in northeast right now. January does have its own teeth! ūüė¶

I am posting something I found during a SOAP Webservice invocation, which I hope can help you save some time in your development.

There was an error message when a SOAP client gets and parses a response from a SOAP Webservice and it started to complain about something like:

Attribute “xmlns:ns2” was already specified for element …..

It puzzled me at the first glance because in the actual captured SOAP response, the element the error is complaining about has no prefix “ns2” at all. After a couple days of not knowing what is wrong, I finally noticed that the element in the SOAP response has an empty seemingly benign namespace attribute:

xmlns=””

This one is actually the culprit! The error is actually indicating that the element SHOULD have a namespace based on the WSDL/XSD (in this case it was designed to have namespace of http://www.w3.org/2005/08/addressing). ¬†The empty namespace xmlns=”” triggered the error during parsing! ¬†After fixing at the server side to ensure the SOAP response has the correct namespace designated for the element as¬†http://www.w3.org/2005/08/addressing, the problem went away!

Now, the question remains why the error is complaining about the xmlns:ns2? i.e. where does the ns2 prefix come from? It is actually quite obvious when I look at the whole SOAP response. The ns2 prefix is mapped to the URI http://www.w3.org/2005/08/addressing at the root element of the SOAP response, thus, the error is referring to that prefix throughout the whole document.

Next time when we see similar error message to this, we can easily find out what namespace the element of concern should have and enforce it to be assigned correctly.

Stay warm!

-Tony

Datapower changes Content-Type in HTTP header

Hi, There:

I am having this issue with IBM WebSphere Datapower routing function, which I still haven’t solved it yet after a week or so. I suspect this is a bug in the Datapower for WS proxy. Anyway, the issue is as following.

I am trying to do some incoming URL based routing using XSLT, pretty straightforward like this core line in the stylesheet.

<dp:set-variable name=”‘var://service/routing-url'” value=”‘http://newhost:7001/newURL'&#8221; />

This routing itself actually works correctly as expected. However, when the incoming SOAP WS call is a multipart request such as in MTOM/XOP, the Datapower will strip off the Content-Type in the HTTP header (I could not prove this until I used Wireshark to capture the network packets).

The original HTTP Content-Type going into the WS proxy was:

multipart/related; boundary=”uuid:d50f031f-5eda-46cd-aee3-29d1d0e3f026″; start-info=”application/soap+xml”; type=”application/xop+xml”; start=”<rootpart*d50f031f-5eda-46cd-aee3-29d1d0e3f026@example.jaxws.sun.com>”; action=””

And after Datapower XSLT routing action, it becomes simply this:

application/xop+xml;charset=utf-8;type=”application/soap+xml”

This caused a SOAP fault on my Web Service server side with this error:

javax.xml.ws.soap.SOAPFaultException: Couldn’t create SOAP message due to exception: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character ‘-‘ (code 45) in prolog; expected ‘<‘ at [row,col {unknown-source}]: [3,1] at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:204) at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89) at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)

 

The error simply means that the server ignores the multipart (due to the new Content-Type) and attempts to parse the whole HTTP body as a single SOAP envelope. Naturally¬†it would fail¬†because it expects the first char from the SOAP XML as ‘<‘ instead of the actual first char of boundary ‘‘.

To date, I still haven’t solved this problem yet, although I truly believe Datapower altered the HTTP content-type header. ¬†I have tried a few things such as <dp:freeze-headers/> and set http request header’s content-type to var://service/original-content-type, in vain.

In comparison, without the XSLT routing, the content-type preserves correctly and the web services with multipart runs as expected without any issues. So the Content-Type loss is indeed related to the routing-url change.

I will update this issue when I found a solution by myself or from other resources.

-TY