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:


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 ¬†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¬†, 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 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!



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*>”; action=””

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


This caused a SOAP fault on my Web Service server side with this error: 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 at at at at


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 Choose between org.apache.cxf.jaxws .spi.ProviderImpl and

Hi, long time again!

Spent a few days with this on and off and finally solved the problem. So it is worth posting!  The source of the problem is not universal, probably. But the solution would be useful for many.

For some strange reason, our CXF client fails to talk to a Web server when the payload is more than 40KB. It works fine when the attachment to SOAP is less than that. This is really absurd. Using Wireshark, it was determined that the communication failed at the TCP level. Because it is hard to change the receiver side, and it is relatively easier to change on the client side, we decided to alter the http transport layer that came with CXF.

To make things more complicated, our client uses Karaf as the OSGi impl.¬† I first followed the instruction of adding META-INF\services\ with the contents But Karaf didn’t care that at all. Actually, Karaf throws a weird exception:$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found

After many trials, the only thing that worked was to use dynamic System property setting at run time before the Webservice  client call.

String existingSpi = System.getProperty(“”);

System.setProperty(“”, “”);¬†

//¬† —JAX-WS code calls Webservices —

System.setProperty(“”, existingSpi);

This successfully avoids CXF impl. to the default JAX-WS impl for the HTTP SPI provider implementation.

Note that there is really nothing wrong with CXF impl per se, but under the Karaf environment runtime, the above code allows us to alter the provider to make our client work with the server.