We're updating the issue view to help you get more done. 

Monitoring plugin gives invalid responses

Description

Results returned by the monitoring plugin should not have two namespace declarations:

The problem appears to be introduced in 3.10.3 (3.10.2 did not have the problem with the same plugin version - 1.4.7)

Not only does the child element of the last message stanza have two namespace declarations, the last message stanza itself does not have any. The forwarded message stanza has an empty xmlns delcaration.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
February 15, 2016, 8:41 AM

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

Guus der Kinderen
February 15, 2016, 11:50 AM

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.

Guus der Kinderen
February 15, 2016, 11:55 AM

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.

Guus der Kinderen
February 15, 2016, 11:58 AM
Fixed

Assignee

Guus der Kinderen

Reporter

Guus der Kinderen

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Affects versions

Priority

Minor
Configure