The original title and description of this bug turned out to be an incorrect summary of the matter. The issue was that some clients (namely Pidgin) would not display messages that have a blank xmls="" on the message->body tag. The exact reason for this happen is not clear, but we tested a patch to resolve this and at the same time.
Very puzzling, the routing 'seems' to actually be working, but the client (Pidgin) fails to actually display the message in the chatroom! More boggling and testing other clients ahead. Maybe the 'XML' is getting corrupted somehow and the client is ignoring the message. I did capture one packet with
So Gajim gave me better xmlconsole results, this message fails to be displayed by pidgin
While this one does
Strangely, when this happens, a message coming from Pidgin gets 'corrupted' as well
So I had a suspicion that this change was having some strange side effect
I built Openfire circa 4 August (prior to this change) and could not reproduce this issue.
I then built current master with this patch backed out and could not reproduce this issue either.
Will let ignite run with this build and see if we can make the pot boil again
Regarding the rollback of the fix for OF-938, this will have the unfortunate side effect of breaking the integration for websocket-based clients (e.g. using stanza.io). I will re-open that ticket for further investigation.
Fixed this issue by using string insert rather than the Element API. See for more info.