Description
There are a couple of things that the average Java developer is unable to code correctly. One of these things is calculating the namespace context of an element in an XML document.
Examples:
(1) The following change in Axis2 attempts to resolve an issue where the databinding fails to resolve a QName value if the prefix is declared on the SOAP envelope:
http://svn.apache.org/viewvc?view=revision&revision=398161
Strictly speaking this change is incorrect because it only takes into account namespaces declared on the soap:Envelope, but not on the soap:Body.
(2) The following change in Synapse adds code to compile an XPath expression retrieved from an XML configuration document:
To build the namespace context for the XPath expression, the code uses OMElement#getAllDeclaredNamespaces() on the element that has the attribute the XPath expression is extracted from. That is incorrect because namespaces relevant for the interpretation of the XPath expression may also be declared on ancestors of this element.
(3) RAMPART-40 introduces code that attempts to build a namespace context by scanning the entire document tree for namespace declarations 
.
To avoid these issues and to make life easier for developers, Axiom should define high level methods that allow to calculate the namespace context of a given element. There should be actually two methods:
- One that returns an iterator over all namespace declarations in scope. This method could be used e.g. to initialize the namespace context of an XPath expression.
- One that returns a NamespaceContext object that can be used with other XML APIs that support this interface.
Attachments
Issue Links
- is related to
-
RAMPART-324 Caused by: org.apache.ws.security.WSSecurityException: General security error (WSEncryptBody/WSSignE nvelope: Element to encrypt/sign not found: {http://ws.apache.org/axis2}args0)
-
- Resolved
-