Skip navigation
All Places > Ignite Realtime Blog > Author: Guus der Kinderen
1 2 Previous Next

Ignite Realtime Blog

21 Posts authored by: Guus der Kinderen Champion


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!

We have just released version 1.2.1 of Tinder. This version is a bugfix release, that improvement the AbstractComponent implementation that was added in version 1.2.0.

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 Openfires Achilles' heel. 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?

We've just released the second version of Tinder, the new XMPP library that was introduced two months ago. This release focusses on Java concurrency (threading) issues and fixes a number of important bugs from 1.0.0. More detailed information is available in the release notes. 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. provides the infrastructure to do the monitoring for you. The probe that's integrated in the Openfire plugin sends statistics to Everything else is handled there. You can view the data from their website, as shown below.

Java-Monitor architecture

To get started, register an account at 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.

We've just released a new project, named Tinder. Tinder is a new Java based XMPP library, providing an implementation for XMPP stanzas and components.


Tinders origins lie in code that's shared between Jive Software's Openfire and Whack implementations. The implementation that's provided in Tinder hasn't been written again from scratch. Instead, code has been moved from the original projects into Tinder, preserving al of the existing features and functionality. Most of the code that's now in Tinder is based on the org.xmpp package implementation that previously existed in Openfire and Whack. This is the code that defines classes such as Packet, JID, IQ, Component and their extensions. Additionally, some multi-purpose code (such as the DataForm and Result Set Management implementations have been moved to Tinder as well.


Why a new project?


Parts of the code of Openfire are useful in other contexts than that of an XMPP server implementation. Developers might, for instance, want to use the XMPP stanza implementation within other projects. Having to include Openfire as a dependency of such a project is quite a bit of overkill. In such an example, it would be useful to have a small project that you can include, that offers you a lightweight XMPP object implementation, without the rest of the features that Openfire offers. Enter Tinder. Tinder will allow developers to re-use parts of Openfire, without having to include Openfire itself.


There's other benefits to Tinder though:


Tinder will replace some most of the duplicate code that's currently shared in Openfire, Whack and ConnectionManager projects. Removing duplicate code will make it easier to maintain and develop these projects. By delegating the implementation and maintenance of the low-level XMPP implementation, Openfire, Whack and other developers will be able to focus on the development that adds value to their project.


On the flip-side of that medal, you can argue that the 'core' code that will make up Tinder deserves a bit of dedicated development attention (unit tests, bug-tracking, stuff like that). This would benefit any attempt to really fine-tune the code, for example for high-performance tuning. Currently, the code is a bit put in the shadows of the other projects (of which they are part of).


So, will this replace Smack (the library that provides the base of Spark)?


No, definitely not. Smack offers a full-fledged XMPP client implementation, while Tinder only defines some XMPP building blocks. Tinder provides some basic objects on which a client library such as Smack could be build. However, Smack does not share the same code base as Openfire and Whack do. It's therefor unlikely that Tinder and Smack will be merged in the foreseeable future - there's simply to much difference.


What's next?


We've wrapped up a initial roadmap, in which we capture the first steps of the development of Tinder. As always, you're invited to contribute. We're looking forward to hear your suggestions, thoughts and ideas. If you're interested, you can find more information on the new Tinder-related community space and project page that have been opened on

Filter Blog

By date: By tag: