powered by Jive Software

Smack bug 232 caused by im gateway?

Hi jadestorm,

Please look at the following openfire smack forum posting:


I can’t tell if there is a relation between the im-gateway and the smack bug here. It seems like you guys are parsing on the first “@” sign whereas you should be parsing on the LAST “@” sign. If you need more logs, lemme know.

This bug might stop us from rolling our the newest smack api onto our production servers.

Also, we’re testing using “\40” instead of the traditional “@” sign.

I’m afraid I’m not really following. I run JIDs through “JID escaping” routines from Openfire that converts @ to \40 and such as needed. MSN for example explicitly has to deal with this since the accounts are email addresses. testaccount@foo.com@aim.whatever.org <- I don’t think that’s even valid is it? I’ve never seen signs that that’s valid. It would have to be testaccount\40foo.com@aim.whatever.org.

Strangely enough that’s what is exactly coming out of our logs. If you would like, I can send you a non-anonymized version over email so it’ll be easier to follow. I understand what you’re saying, and we haven’t issues like this before. Only when we upgraded to Smack 3.0.4 do I get this. Are you running 3.0.4? And if foo.com is a federated network, you can certainly have testaccount@foo.com@aim.whatever.org.

I’m using Smack 3.0.4 with the IM gateway plugin’s XMPP and Google Talk support. I don’t suppose you have an example of where it says that multiple @'s are valid do you? I’d like to read more about it. =)

It’s not really multiple @ signs, just one for the federated network. So openfire is trying to add the contact testAccount@foo.com. However, the packets will return testAccount@foo.com@theopenfireserver.org. It’s really one @ sign, and it seems like sending \40 instead of @ did the trick for smack in our tests. We can live with that.