The Ignite Realtime community is happy to announce the release of version 3.7.1 of Openfire! Downloads for various platforms are available here.

Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

The 3.7.1 release is primarily a bugfix release. Amongst others, these issues have been addressed:

• A number of enhancements were made to the server-to-server connectivity. Server-to-Server connectivity was enhanced and a bug preventing a successful dialback was fixed.
• Various improvements have been made to platform specific installers and scripts.
• The Multi-User Chat implementation has received various tweaks and updates.

The full changelog is available on the Openfire project page.

We welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.

Good things come to those who wait!

The Ignite Realtime Community is pleased to announce the beta for the next release of Openfire. This release contains a number of important  fixes and improvements to stability and XMPP protocol compliance. You can find a full list of fixed issues here. This beta is also the first version of Openfire to be released by the Ignite Realtime community under the Apache License v2.0.

You can download the 3.7.0 beta release here. Please provide us your feedback on the Ignite Realtime support forums. It would be helpful if you would tag your comments, discussions and questions with a tag that reads "openfire370beta"

As always, but particularly since this is a beta release, make sure to backup any existing version of Openfire and the persistent storage that it uses, before upgrading!

Some important security related notes to this release:

• Openfire no longer ignores the system property to disallow password changes via XMPP. With previous releases, it was not possible to prevent users from changing their password via their XMPP connection. (CVE-2009-1596)
• Fixed a XSS attack on the admin console login form.

Protocol compliance improvements:

• Publish Subscribe (PubSub)
• BOSH (http-bind) xml namespace compliance fix.

Some highlights of this beta release:

• Improves how Openfire handles "idle" connections. Some of you may have  the system property xmpp.client.idle set to -1 to work around  previously broken behaviour. You may now let it default to 6 minutes or  set it to your preference.
• Improved Openfire's caching to be less prone to memory exhaustion by correctly calculating cache size usage.
• Fixed a bug where admin console login into a newly installed Openfire server would fail until restarted.
• Fixed a bug with shared rosters within a LDAP environment.
• Openfire now ships with the latest JRE (1.6.0u21).
• A memory leak with the Personal Eventing Protocol (PEP) was fixed.
• Openfire's custom log interface has been replaced with SLF4J and a Log4J backend.
• Fix issues with self signed SSL certificates.
• A number of improvements and fixes were made to the Multi-User Chat (MUC) configuration pages on the admin console
• There were also some improvements made to the plugins.
• There are also French, Russian, and Lithuanian langauge translation fixes for Openfire and some of the plugins.

This year, Openfire will be the subject of two lectures given at the eleventh edition of the annual FISL conference in Porto Alegre, Brazil. Both presentations are scheduled for the last day of the event, Saturday. The lectures will provide a basic introduction to Openfire and Openfire development. They will be presented by yours truly.

If you're interested, I invite you to drop by! I'm pretty sure that Openfire (or even more generic XMPP related) discussions won't stop when the lectures are over. For one, Thiago Camargo, former Openfire developer and author of the new Jingle Relay Nodes enhancement proposal, will be attending as well. I've heard rumors of Openfire-ready implementations, which should be very, very interesting!

I'd love to see you there!

Static analysis is the analysis of software without executing that code. For Java, one of the better known static analysis tools is FindBugs.

The FindBugs team is planning a community review of warnings in several open source projects of varying sizes. The goals of the review are to bring problems to the attention of developers and compare the perspectives of independent reviewers on the severity of the warnings. Openfire has been included in this endeavor.

We invite you to take part. Using a Java Webstart instance of FindBugs, you will be able to review warnings and add comments where appropriate. If you're interested, please navigate to the FindBugs Community Review page and start reviewing!

I'm happy to announce the release of version 1.2.0 of Tinder. This new version brings interesting new features, a number of bugs fixes and general performance improvement.

Recently, I published a document describing a problem that I dubbed the Achilles' heel of Openfire. Tinder 1.2 introduces the AbstractComponent implementation, which will allow you to circumvent this problem easily. Additionally, AbstractComponent removes the need for the repetitive work that traditionally goes with implementing a full featured, spec-compliant component. Have a look at the Component Developer Guide for a detailed description.

Tinder 1.2 no longer depends on Openfire-specific logging. Instead, Simple Logging Facade is used, which will allow you to integrate with your existing logging framework easily. Finally, caching strategy and implementation have been modified to give you better performance.

A detailed list of changes can be found in the Tinder Release Notes. Did I mention that starting with 1.2 we're releasing the code under the Apache 2.0 license?

Java-monitor.com has released a new, free Openfire plugin that allows you to monitor your Openfire instance remotely. The plugin will notify you if your server goes off-line. It also allows you to keep a close eye on a number of important health indicators, such as the usage pattern of the Openfire worker threads, JVM memory usage and garbage collection statistics, JVM thread and Openfire's database connection pool usage.

Unlike most monitoring tools, you don't have to set up a monitoring server yourself for this to work. Java-monitor.com provides the infrastructure to do the monitoring for you. The probe that's integrated in the Openfire plugin sends statistics to java-monitor.com. Everything else is handled there. You can view the data from their website, as shown below.

To get started, register an account at http://java-monitor.com/install.html. After you've registered, you'll be able to download a personalized Java-Monitor probe package, which includes an Openfire plugin. Add this plugin to your Openfire installation, and you're done! The plugin will automatically start collecting data. Java-monitor allows you to monitor Openfire from anywhere - all you need is a javascript enabled browser.