General2 Comments
Nov 08

Smack API: Destorying persistent Multi-User Chat Rooms

Another one that is not documented.
Suppose you have a persistent Multi-User Chat Room (MUC) and room is empty. Apparently to destroy the room, the owner needs to join it, and then call the destroy() method on that room.
See, short and sweet.

Nov 08

Smack API: No clean way to discover if a multi-user chat room exists

Here’s another one to follow the previous two posts about Smack API and Multi-User Chat issues.
Suppose you want to create a persistent room. Suppose you are not sure if that room already exists. In Smack, and I am not familiar of any other APIs, there is no non-exception-throwing way of doing this.

Fundamentally, a room already exists is the situation where a room is already set up on the server with the same name as the one you wish to create.

The MultiUserChat object has a static getRoomInfo() method which may have been the way to go. If the room does not exist, return null. Instead, if the room does not exist throws an XMPPException. Not sure what the error situation is here – I am just trying to find out if a room exists or not, but that causes an exception.

The flipside is on the creation end. If you try to create a room that already exists, an XMPPException will be thrown. This makes sense and is recoverable. Still, I am a fan of checking first instead of trying to do something only to encounter a bad situation. Not a biggie – just hope this spares someone the exploration and time. Not really documented, etc.

Nov 08

Openfire/Smack bug? Unable to ask Multi-User Chat who the admins are

I encountered two interesting points when working with the Openfire XMPP server and the Smack API, both from IgniteRealtime.

  1. After joining a Multi-User Chat (MUC) independently, without invite, I was forbidden (e.g. error 403) from finding out who the administrators or owners of the room were. I could not find anything about this in the documentation.
    The workaround was not too bad: apparently the method getOccupant() allows you to get an Occupant object which does hold affiliation and can report admin rights.
  2. In some situations – not sure when yet – the owner of an MUC was able to grant another user admin status by just using his/her nickname, without using the full JID. That is
    grantAdmin("nickname") worked just as well as grantAdmin("nickname@conference.server"). Nonetheless, when trying to use the method getOccupant() as mentioned above, the full JID form worked while the nickname-only one failed.

I am using Smack 3.0.4 and Openfire 3.5.2. Weird.