NPE with OF 3.7.0 beta and Smack 3.1.0

RoomInfo(DiscoverInfo info) {

super();

this.room = info.getFrom();

// Get the information based on the discovered features

this.membersOnly = info.containsFeature(“muc_membersonly”);

this.moderated = info.containsFeature(“muc_moderated”);

this.nonanonymous = info.containsFeature(“muc_nonanonymous”);

this.passwordProtected = info.containsFeature(“muc_passwordprotected”);

this.persistent = info.containsFeature(“muc_persistent”);

// Get the information based on the discovered extended information

Form form = Form.getFormFrom(info);

if (form != null) {

this.description =

form.getField(“muc#roominfo_description”).getValues().next();

Iterator values = form.getField(“muc#roominfo_subject”).getValues();

if (values.hasNext()) {

this.subject = values.next();

}

else {

this.subject = “”;

}

this.occupantsCount =

Integer.parseInt(form.getField(“muc#roominfo_occupants”).getValues()

.next());

}

}

We have been testing our Smack-based client which works fine with OF 3.6.4 against OF 3.7.0b. Something must have been modified in OF that causes NPEs. The client discovers the roomInfo without joining (see smackx/muc/RoomInfo.java). Since there is no ‘roominfo_subject’ in the disco#info reply Smack throws an exception which is what we see in the message debug.

This bug has been reported as SMACK-163 . It shows up as fixed but it is not. When looking at the code, the original comment and proposed fix still applies.

Here is where it happens:

// Get the information based on the discovered extended information
        Form form = Form.getFormFrom(info);
        if (form != null) {
            this.description =
                    form.getField("muc#roominfo_description").getValues().next();
            Iterator<String> values = form.getField("muc#roominfo_subject").getValues();
            if (values.hasNext()) {                 this.subject = values.next();
            }
            else {
                this.subject = "";
            }
            this.occupantsCount =
                    Integer.parseInt(form.getField("muc#roominfo_occupants").getValues()
                    .next());
        }

The solution is described in the comments of OF 163 (see http://issues.igniterealtime.org/browse/SMACK-163) as following:

final FormField subjField = form.getField("muc#roominfo_subject"); this.subject = subjField == null ? "" : subjField.getValues().next();

PS: I have just noticed, that this has already been reported in multiple other threads (http://community.igniterealtime.org/message/192428#192428 , http://community.igniterealtime.org/message/198667#198667 …)

The OF bug must be in the XEP-128 support of OF http://xmpp.org/extensions/xep-0128.html

In the IQ response below I find a malformed XML which is the problem:

<field label="Number of occupants" var="muc#roominfo_occupants" > <value>test</value> <value>0</value> </field> <field/>

I could not find anything strange in the OF code:

http://fisheye.igniterealtime.org/browse/openfire/trunk/src/java/org/jivesoftwar e/openfire/muc/spi/MultiUserChatServiceImpl.java

<iq from="test@conference.localhost" type="result" id="aac9a" to="admin@localhost/Michael-Laukners-MacBook-Pro" >
<query xmlns="http://jabber.org/protocol/disco#info">
<identity category="conference" type="text" name="test" />
<feature var="http://jabber.org/protocol/muc" />
<feature var="muc_public" />
<feature var="muc_open" />
<feature var="muc_unmoderated" />
<feature var="muc_semianonymous" />
<feature var="muc_unsecured" />
<feature var="muc_persistent" />
<feature var="http://jabber.org/protocol/disco#info" />
<x xmlns="jabber:x:data" type="result" >
<field type="hidden" var="FORM_TYPE" > <value>http://jabber.org/protocol/muc#roominfo</value>
</field>
<field label="Description" var="muc#roominfo_description" > <value>test</value>
</field>
<field label="Number of occupants" var="muc#roominfo_occupants" > <value>test</value> <value>0</value> </field> <field/>
<field label="Creation date" var="x-muc#roominfo_creationdate" > <value>20101023T12:33:33</value>
</field>
</x>
</query>
</iq>

Finally, I did find the bug (typo = comment) in the OF code:

http://fisheye.igniterealtime.org/browse/openfire/trunk/src/java/org/jivesoftwar e/openfire/muc/spi/MultiUserChatServiceImpl.java

The bug = comment is in line 1293:

/*final FormField fieldOcc =*/ dataForm.addField();
                fieldSubj.setVariable("muc#roominfo_occupants");
                fieldSubj.setLabel(LocaleUtils.getLocalizedString("muc.extended.info.occupants"));
                fieldSubj.addValue(Integer.toString(room.getOccupantsCount()));

Could you please open a ticket?

Hi Michael,

Do you have a Jira account? I’d be happy to give you privs there to help out.

daryl

Hi Daryl,

Yes, I have got one but can only create issues for ‘Tinder’ .

Michael

Please try it now. you should be able to create openfire issues

Daryl,

I have created http://issues.igniterealtime.org/browse/OF-428

Thanks

Michael

Michael,

I have reopened SMACK-163 since you were explicitly claimed it to be not solved. Reading your comment about OF, can I close 163 again?

Walter

Hi Walter,

The Smack code is not failsafe/fault tolerant which is a quality criteria! I would rather prefer that all NPE situations are solved. Psi works without any issues despite the OF bug. Also XEP-128 is very weak such that it provides too much flexibility. The current implementation loops without Null pointer checking - what if there is another empty field received by Smack.

All I know is that we have a problem with our client and either have to fix the Smack issue in our code, bypass the GetExtendedRoomInfo method or cannot upgrade to OF 3.7.0.