Mozammel’s Blog

I wasted more than four hours on this bug (feature?). I have an Ajax front end (using GWT) which connects to my existing Jabber Server (Openfire 3.3.0) using anonymous login (over SSL). For connectivity from my middle tire to Jabber server, I use Smack API version 3.0.4. Now, as I tried to implement InvitationRejectionListener on my MultiUserChat object (which was created with anonymous login), I found out the no packet was being forwarded to MUC (MultiUserChat) object from the jabber server. Now if I make that connection with a registered user, it works fine! Here is the troublesome code:

XMPPConnection conn = new XMPPConnection(connectionConfiguration);
conn.connect();
conn.loginAnonymously();

final MultiUserChat muc = new MultiUserChat(conn, "myroom@conference.domain");
muc.create("testmuc");
muc.sendConfigurationForm(new Form(Form.TYPE_SUBMIT));
muc.addInvitationRejectionListener(new InvitationRejectionListener() {
    public void invitationDeclined(String invitee, String reason) {
            System.out.println("User 1 recives a rejected invitation from user: "
                 + invitee + ", room: " + muc.getRoom());
    }
});
Thread.sleep(300);
muc.invite("mozammel@domain", "none");
Thread.sleep(10000);
muc.destroy("The room has almost no activity...", null);

Isn’t it possible to implement InvitationRejectionListener on anonymously connected MUC object? Still trying to find out….

I was looking to find out the maximum size of a message body in XMPP / Jabber protocol, and up to my current exploration, I didn’t find any limit. In RFC3291, it is mentioned:

2.1.2.2. Body
The element contains human-readable XML character data that
specifies the textual contents of the message; this child element is
normally included but is OPTIONAL. The element MUST NOT
possess any attributes, with the exception of the ‘xml:lang’
attribute. Multiple instances of the element MAY be included
but only if each instance possesses an ‘xml:lang’ attribute with a
distinct language value. The element MUST NOT contain mixed
content (as defined in Section 3.2.2 of [XML]).

But it doesn’t mention anything regarding size/length of the body element. So I’m assuming there is no theoretical limit to it, but different Jabber server may implement it differently.

On may 10th Openfire has released update 3.3.1. The issue that interests me most is this one:

[JM-1043] - Simulation of unavailable presence when socket was abruptly closed was not being properly routed

I tested this scenario previously with their server, and will have to test now after having this upgrade.