Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

add namespace declaration to XML inbound using cxf. Don´t know how to do it  RSS feed

Oscar Rugama
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

First of all, I want to start with the problem.

The problem I have it´s that I´m a client of a web service. This web service is returning an xml in the soapBody of the soapMessage. No problem at this point.

The problem I have it´s that the xml is not well formed, and the web service owner doesn´t want to change it at all.

The solution is that I need to add the following namespace declaration xmlns:xsd= to that xml before cxf parse it, because it cxf parses it, it fails due to the fact that xsd: string for instance is used but never xsd is declared.

I know I have to use an interceptor and I have made one that gets the XML, my code is the one below:

My interceptor works fine and I get the XML as string with no problem, but reaching this point I have no idea in how can I change that XML and add the namespace before the CXF parser takes the XML, does anyone have any idea please?

Thank you
Kind regards

g tsuji
Ranch Hand
Posts: 697
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem I have it´s that the xml is not well formed, ...

The term well-formedness is technical with very rich meaning. If your interceptor or otherwise the shown code can perform to such an extent of giving you back strBody etc, for instance, the soapmsg received is most probably well-formed. But I think we understand what you meant: it simply means it does not work with your code to begin with!

I am doubtful cxf will eventually complain of a missing namespace declaration xmlns:xsd="...", because those xsd:string or alike is not directly exposed in the payload of the soap message. Hence, an xmlns:xsd is strictly speaking not necessary and I think the provider refuses with probably good reason to change anything in that regard. The trouble probably comes from the client-side mapping (unmarshalling) to annotated pojo... You might like to take a look of @XmlSchema annotation sometimes appears in the package-info... just a suggestion.

If we take a blind eye on all that root causes of the trouble and only pursue on a local objective of adding an xmlns:xsd declaration via an interceptor, we can do that. You can before return strBody do a series of string operation on strBody by regex or common string functions by adding xmlns:xsd="" to the root element, after verifying that it is not there... This sure can be done and you should be able to do it look it that way.

But that is hardly a homogeneous use of xml technology. The cardinal way is certainly inserting a specifically designed xslt and transform the payload as Document object itself before serializing it to strBody. This can be done the way I outline below. We can do many things with the xslt 1.0 ordinarily most broadly used version. _But_, what is intriguing is that to add such a "purposeless" (in the sense that it serves nothing at all for validating and/or parsing with schema-aware parser) namespace delaration, in particular, is difficult even impossible (or severly discouraged by coding) in xslt 1.0. In xslt 2.0, this thing sees the light and can now be done with xslt 2 with its specific element xsl:namespace.

You can construct an xslt document (notice: version="2.0") like this.

Apply this xslt to the transformer instead of applying nothing (which means an identity transformation is used by default), see below. But this xslt is distinctly xslt 2.0, you also have to apply an xslt2.0 processor to the interceptor. The most convenient is to load up Saxon 9. The free version is pretty enough. Adding all necessary classpath(s) etc... Then the modification on the interceptor is limited to a couple of lines.

With all the above, you should be done.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!