powered by Jive Software

Found a bug concerning Presence.Mode

Hi,

I wondered why I always reveived an “available” when I did a

presencePacket.getMode()

And so I went deep into the code until I found it:

When Smack (the PacketReader) reveives a packet (with presence in it) it creates a new Presence and tries to set its Mode:

presence.setMode(Presence.Mode.fromString(parser.nextText()));

However, the next text can be indented like this:

____away

_ = spaces

(as it is done by Iain’'s Server )

You should add a trim() statement to the method

Presence.Mode.fromString(String value){

if (value == null) {

return AVAILABLE;

}

value = value.toLowerCase().trim();

}

and/or to the constructor of Presence.Mode

I hope I helped you and others, not getting trapped as I did.

Greets Chriss

Message was edited by: chriss

Chriss,

We could certainly send the #trim message to get rid of possible blank spaces but the thing is that the show value that you are receiving is incorrect. The correct show values are: ‘‘away’’, ‘‘chat’’, ‘‘dnd’’ and ‘‘xa’’.

Could you check who is adding those blank spaces? Is the other XMPP client sending those spaces?

Regards,

– Gato

hmmm, it’‘s Iain Shigeoka’'s server adding those blanks. My clients are built upon smack and send the correct

dnd

the server delivers the message and blows it up to

__dnd

2*blank after EVERY opening or closing tag, so the complete packet looks like:

<presence from=’‘schmitz@bla.de/res’’ to=’‘bla.de’’ id=’‘7pnN7-6’’> dnd

However, not ALL packets are like that. Some of them - it seems as if it were the ones originally generated by the server itself - are correctly formed. And I didn’'t find where those 2 blanks are added.

I gonna post this issue to Iain’‘s forum; it’'s his thing, so…

Errr, and the values are incorrect because of the blanks, right?

thx a lot!

Chriss

Chriss,

Errr, and the values are incorrect because of the blanks, right?

Yes, the blank spaces are causing the Available presence.

– Gato