Patch to enable unknown IQ messages to include childXML

Thats perfectly fine, but we have absolutely no control over that end device. We cannot fix it, as it was not something we own, control, exists, or even know about.

The devices will probably have a wrapper element that we don’t know about until integration time. We can and probably will eventually create a provider for that new element, but for test purposes and one off commands, having a generic way to test without a recompile/deploy would be very beneficial.

Again, we can in fact send arbitrary XML directly inside the IQ with the unpatched smack library. The problem is the asymetrical aspect. You can send anything, but even with a packetID packet collector, the excess reponse data is simply read and dropped.

I’ll have a look if it’s possible to equip UnparsedIQ with the from, to, type and id metadata/attributes of IQ. This should allow you to create a packet **collector **for the response that comes UnparsedIQ. SMACK-466

That’s already possible. I can send a random IQ message to a target, setup a packetID filter on a packet collector, and receive an IQ response. This IQ response has the IQ fields parsed out, including the type={error|result}

However, any contents underneath this IQ are discarded. The getChildXML() method of the IQ it returns simply is defined as “return null”.

The patch from earlier captures the unknown XML in a stringBuffer, and defines getChildXML() to return that string.

Which type has the response IQ stanza that you receive?

The idea is that it will be UnparsedIQ with the from, to, type, and id metadata filled out. And UnparsedIQ allows you to retrieve the text. If I understood you correctly, that is what you want.

I think that sounds good. The implementation I patched(see top post) created a StringIQ type that captured the text.

I don’t understand your queation about which type has the response IQ stanza though

I am wondering how the process you desribed here

I can send a random IQ message to a target, setup a packetID filter on a packet collector, and receive an IQ response. This IQ response has the IQ fields parsed out, including the type={error|result}
works.

Also looking at the code, it seem that UnparsedResultIQ does exactly what you need: It has the child XML and the ID set. Isn’t the reply of your IQs of type result?

I appologize.

I read the JIRA update as “instead of unparsedIQ, we’re using a listener instead”, which would have been no good. The resposnes will be Type.RESULT, so this should work.

Looking at the code, I think you might need to incorporate this patch to get the top level. of XML

https://gist.github.com/taer/9586e09865a67076d59c

I’ll test w/ the new code and see how it works.

And while I just came across this: RFC6120 8.4 Extended Content, clearly states that

and an IQ stanza of type “get” or “set” MUST contain one such child element. Such a child element MAY have any name and MUST possess a namespace declaration (other than “jabber:client”, “jabber:server”, or “http://etherx.jabber.org/streams”) that defines the data contained within the child element.
So every IQ stanza must contain a child element to be valid.

The ones we’re sending and receiving do have child elements, they’re just unknown to us for some of the use cases. These unknown elements will be properly formed according to the spec.