powered by Jive Software

IllegalArgumentException: No enum const class Presence$Type.invisible

2006.02.18 05:16:51 Invalid presence type

java.lang.IllegalArgumentException: No enum const class org.xmpp.packet.Presence$Type.invisible

at java.lang.Enum.valueOf(Unknown Source)

at org.xmpp.packet.Presence$Type.valueOf(Presence.java:321)

at org.xmpp.packet.Presence.getType(Presence.java:106)

at org.jivesoftware.wildfire.net.SocketReader.readStream(SocketReader.java:215)

at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:119)

at java.lang.Thread.run(Unknown Source)

/code

Some clients still use the deprecated http://www.jabber.org/jeps/jep-0018.html. This fills the warning log with these exceptions and obscures the warnings I really care about.

What I suggest is to catch this exception (or even better - check the value before calling Presence.Type.valueOf()) and log one line message like:

uses the deprecated JEP-0018. Request for invisible presence ignored![/i]

I suggest we check only for ‘‘invisible’’, because it seems to be very common. I’'m fine with having exceptions for other invalid presences.

Hi Dimitar,

this is once again an exception with stack trace without much value content I just saw your post and did wonder if it wouldn’'t be better just to log

ignored![/i]

What’'s the benefit in getting a stack trace without JID for other invalid presences?

LG

The benefit of a stack trace is that it draws attention

The invisible presence is kinda ‘‘normal’’ - Psi uses it, Gaim uses it, I gues there are other clients as well. On the other hand, for guys implementing clients it would be useful to get a stronger error when they misspell ‘‘unaveilable’’.

The indented exception draws my attention when the log file scrolls through the console. Of course I wouldn’‘t mind exception AND usefull error message, but I think that’'s asking too much