Changes in this pull request: https://github.com/igniterealtime/Openfire/pull/539/

I suspect that part of the namespace-related issues that are being solved through string manipulation find their origin in the following behavior of dom4j.

A namespace can be added to an element by using Element#addNamespace(prefix, uri). Some parts of Openfire abuse this method by supplying an empty string value for the prefix, assuming that this will cause the default namespace to be defined. This is not the case (and arguably, dom4j should have thrown an exception here).

Although the string representation of the element will include a namespace that's formatted as the default namespace (in other words: it has no prefix), internally, dom4j does not recognize that namespace as being the default namespace. This is how namespace checks fail, even though visually, everything appears to be in order.

I've modified code in Openfire to stop using of this faulty hack. Instead, the element is created with a proper namespace definition.

The change introduced in depends on a whitespace character being present in the first element, which is not the case here:

As the first whitespace is found in the child element, that's where the namespace definition gets added.

I've changed this code to work on the closing characters (> or />) instead of a whitespace. That should be safe, as any valid XML should have that.

Although this will prevent the problem, I've also created a new release of the Monitoring plugin in which I added a 'to' attribute in the original message stanza. This will add the whitespace character. This will allow people to work around the issue by updating the Monitoring plugin, instead of updating Openfire.

might be related, as it introduces a change related to namespaces in version 3.10.3.