powered by Jive Software

Problems with Trunk builds of Openfire and Tinder

Openfire Openfire Dev
#1

Wanted to report a few things.

  1. The latest build of openfire references an older version of tinder.jar. It’s pre- 11520 as protected JID jid = null; is missing in AbstractComponent

  2. Having rebuild the latest tinder.jar and updated openfire with this library discovered that the latest changes to JID had messed things up. Namely JID.toString() now returns **null@**component.domain.com for nodeless jids (components) so the components and plugins are pretty much disfunctional. Reverting to older code base for JID.java solved the problem.

If this hasn’t been reported yet looks like #1 is the reason from # didn’t surface right away.

cheers

#2

Thanks for reporting this, Andrei. I’ve noticed the problem myself, and actually fixed it, but neglected to check in the fix. I probably misseed my morning coffee that day. As you’ve bothered to do a proper report, I’ve created a proper JIRA issue for this: TINDER-45

I’ll check in the fix momentarily (most likely before you read this response).

#3

Any time. I wasn’t sure on the rule for reporting bugs as I am new to the community but please advise.

#4

FYI - the fix for this issue was not complete. toBareJID() also needs to be adjusted as follows:

public String toBareJID() {
final StringBuilder sb = new StringBuilder();
if (this.node != null) {
sb.append(this.node);
sb.append(’@’);
}
sb.append(this.domain);
return sb.toString();
}

This problem is causing plugins to send incorrect information in disco responses - causing all sorts of havoc.

#5

Hi Kevin, as far as I can tell “toBareJID” should return a bare JID which consists of node@domain. So one should at least update the javadoc that this method does not throw an exception when the node is missing.

@Guus: Why is toBareJID() not final, does one need to be able to overwrite it?

#6

Thanks for reporting this, Kevin. I’ve added OF-399 to track the Openfire-sided issue. I’ve also updated the original TINDER-45 issue.

@LG: Perhaps you’re right - this code is not designed to be extensible, as far as I can see. If we’re going to consider making things final to explicitly forbid this, I’d like to review the entire Tinder project in one go, and have it done all at once though.

#7

Tonights nightly builds will generate Openfire distributables that include a fix for this issue. Nightlies are being build by our Bamboo instance (http://bamboo.igniterealtime.org) and are also available in the download section of our we website

#8

Yeah, one should review the whole project, same for Openfire.

The JID class may be one which should we defined final and which should not be cloneable.

http://www.owasp.org/index.php/Java_leading_security_practice looks fine. We could add it to Guidelines for Smack Contributors and Becoming a Contributing Member.