NPE in MUC / RoomInfo when requesting room info

hi,

RoomInfo assumes that a server will always return the fields

muc#roominfo_description

muc#roominfo_subject

muc#roominfo_occupants

… i’‘m running the latest ejabberd version and it seams it doesn’‘t (always?) return muc#roominfo_subject … and so i’'m getting a null pointer exception when calling MultiUserChat.getRoomInfo()

see: http://www.jivesoftware.org/fisheye/viewrep/svn-org/smack/trunk/source/org/jives oftware/smackx/muc/RoomInfo.java?r=2493#l91

thanks,

Herbert Poul

http://goim.us

could anyone please look at this ? it’‘s really annoying i can’'t use the official build because of a simple null pointer exception …

simply replace line 89 - 94 in RoomInfo.java with the following code and you don’'t even need to think about it again:

FormField descField = form.getField(“muc#roominfo_subject”);

if(descField != null)

this.description =

(String) descField.getValues().next();

FormField subjectField = form.getField(“muc#roominfo_subject”);

if(subjectField != null)

this.subject = (String) subjectField.getValues().next();

FormField occField = form.getField(“muc#roominfo_occupants”);

if(occField != null)

this.occupantsCount =

Integer.parseInt((String) occField.getValues()

.next());

(ie. add checking if the value is null … before calling a method on it… not really a big feature improvement … but… it would make MUC usable…)

thanks,

Herbert Poul

http://goim.us

Hi Herbert,

maybe it is possible for you to use the XMPP debugger to display the XML packet which causes the problem, maybe the exception makes this impossible. I wonder what happens if you use Spark to query this room info.

Maybe one could read the JEP’'s to get the information whether this value is mandatory or not.

Anyway I agree that Smack should handle this without causing an exception. But I don’'t like your coding style without { }, you could also use unreadable code like this.subject = (subjectField != null) ? (String) subjectField.getValues().next() : “”;

May a developer read this, create an issue and fix it.

LG

i’'ve looked at the XML packet… and i know that the information is missing .

A chatroom MAY return more detailed information in its disco#info response using Service Discovery Extensions , identified by inclusion of a hidden FORM_TYPE field whose value is “http://jabber.org/protocol/muc#roominfo”. Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:

if i interpret it correctly . .it means everything is optional

cu

Herbert Poul

http://goim.us

P.S.: the code was just a quick fix so i don’'t get a nullpointer exception each time… but is still an improvement to the original ‘‘coding style’’

btw… it’‘s not too important any more … since i’'ve discovered the svn diff & patch works great

i’'ve imported it into my own subversion repository and was able to merge the jivesoftware.org changes into my own codebase … so … i can live with it not being fixed in the official release …

(it also contains the method i requested in: http://www.jivesoftware.org/community/message.jspa?messageID=109957 )

http://yourhell.com/WebSVN/listing.php?repname=Sphene&path=/smack-fork/

perhaps it would be good to create a fork with a more open structure … where everyone interested gets SVN write access… ? the changes could be easily merged back to jivesoftware if they prove successful…

Hi Herbert,

access to the SVN could imho be possible if one fills out the form available here http://www.jivesoftware.org/community/ann.jspa?annID=2 and is willing to do some development. Someone must review the changes within the SVN because Smack is used within Spark and should not contain bad-patched code. If everyone had write access to it we’'d see some patches which are made because some people have problems to use the API properly.

As you have “only a fix” to provide the forum (or an email to Matt or the Wednesday chat) is unfortunately the only place to do this.

LG

hi,

Someone must

review the changes within the SVN because Smack is

used within Spark and should not contain bad-patched

code.

that’'s what i ment … why not create a separate fork where a bit more experimental patches are applyed …

altough i want my IM to be stable… for an open source project without any company behind it, without support contracts or anything … it’'s more important to be more feature rich than stable (stable as in … need to go through dozens of QA cycles before releasing )