Openfire 5.0.0: A New Era of Real-Time Communication

[guus]

We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

The changelog lists all of the changes that have been made.

We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

Here’s to the future of real-time communication with Openfire 5.0.0!

For other release announcements and news follow us on Mastodon or X

[claude_stabile]

Congrats excellent news excellent work done
In openfire we trust

[speedy]

Congrats team and that you for all the hard work!

[Miguel_Martin-Forero]

Keep up with the good work!

[wroot]

Kudos

[CSH]

Just read it here, nice work!

[Arwen]

Huge kudos!

[guus]

When installing Openfire on Microsoft Windows, there are several ways that Openfire can be started. People that are using the Openfire Launcher with Openfire 5.0.0 have reported a bug: the Launcher, instead of starting Openfire, shows an error (as illustrated below).

We have recorded this bug in our issue tracker as OF-3093, which will be fixed in the next release of Openfire.

In the mean time, you can use one of the following workarounds:

Workaround #1
It is preferred to start Openfire as a service, not through this launcher. Starting Openfire as a service does not suffer from the problem above.

Workaround #2
I you’d like to use the launcher, you can work around the problem as follows

1. Download this file: openfire500quickfix.jar (186.9 KB)
2. Save the file (unmodified) in the lib folder of your Openfire installation, for example, in C:\Openfire\lib\ (not in C:\Openfire).

The Launcher will now work as before.

[nobby6]

How about when you use the tarball download - there is no bin/openfire ?
Tried the dot sh file and it seems to try do something but it never runs.

[guus]

Hmm, that does seem to work for me (I have used the tarball downloaded from under the ‘Linux’ button on Ignite Realtime: Downloads):

guus@octarine:~/Downloads$ tar -xzf openfire_5_0_0.tar.gz 
guus@octarine:~/Downloads$ ls openfire
bin  changelog.html  conf  dist  documentation  lib  LICENSE.html  plugins  README.html  resources
guus@octarine:~/Downloads$ ls openfire/bin
extra  openfirectl  openfire.sh
guus@octarine:~/Downloads$ sh openfire/bin/openfire.sh
JAVA_HOME is empty, trying to find it
JAVA_HOME is set to /usr/lib/jvm/java-21-openjdk-amd64
OPENFIRE_HOME is empty, trying to find it
OPENFIRE_HOME is set to /home/guus/Downloads/openfire
Openfire 5.0.0 [Jun 27, 2025, 10:58:19 AM]
Admin console listening at http://octarine:9090
Successfully loaded plugin 'admin'.

The admin console is listening on localhost:9090 afterwards, as expected.

What are you getting? Anything in the logs?

[nobby6]

I can get to this admin page after upgrade, but it doesnt background, and the xmpp doest start, ie: clients can not connect, not even us.
at the end of below it just sits there. also the upgrade instrutions in this archive say bin/openfire is how to start, just like we’ve been doing for years with all previous versions, in fact, the opennfire.sh at about 5k has never been executable, only openfire 19k sh SH file that no longer seems to exist.

There errors are numerous and I know SFA java - I’ll redact anything to avoid bots, and try attach it in a new post.
But on screen shows (and although this try is running /opt/openfire5 - I did perform the usual backup-wipe-install into /opt/openfire and had same results, I just moved to openfore5 so I could restore the 4.9.2 working version

sudo -u ims /opt/openfire5/bin/openfire.sh
JAVA_HOME is empty, trying to find it
/opt/openfire5/bin/openfire.sh: line 31: update-alternatives: command not found
Unable to get preferred JAVA_HOME from java alternative
JAVA_HOME is set to 
OPENFIRE_HOME is empty, trying to find it
OPENFIRE_HOME is set to /opt/openfire5
Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is 
automatically registered via the SPI and manual loading of the driver class is generally unnecessary.
Openfire 5.0.0 [Jun 28, 2025, 12:14:19 PM]
Admin console listening at:
  http://xxxxxxxx:9098
  https://xxxxxxxxxx:9099
Successfully loaded plugin 'admin'.
Successfully loaded plugin 'bookmarks-1.2.0'.
Successfully loaded plugin 'broadcast-1.9.3'.
Successfully loaded plugin 'avatarresizer-1.0.1'.
Successfully loaded plugin 'certificatemanager-1.2.0'.
Ignoring plugin 'httpfileupload': compatible with server versions up to but excluding 5.0.0. Current server version is 5.0.0.
Successfully loaded plugin 'contentfilter-1.8.2'.
Successfully loaded plugin 'dbaccess-1.3.0'.
Ignoring plugin 'monitoring': compatible with server versions up to but excluding 4.10.0. Current server version is 5.0.0.
Ignoring plugin 'jsxc': compatible with server versions up to but excluding 5.0.0. Current server version is 5.0.0.
Successfully loaded plugin 'userimportexport-2.7.1'.
Successfully loaded plugin 'pushnotification-1.0.1'.
Successfully loaded plugin 'search-1.7.4'.
Successfully loaded plugin 'userstatus-1.3.0'.
Finished processing all plugins.

this is where it hangs, after 15 mins or so I ctl-c it, and it responds with server halted.

[nobby6]

openfire log if it will accept it
OS: Slackware 15.0
java --version 17.0.13 2024-10-15
OpenJDK build 17.0.13+11

openfire.log.gz (8.5 KB)

[guus]

It’s hard for me to follow along with what you’re writing, but I think I spot at least one issue from the log files that you provided:

Most of the errors in the log files are caused by the AvatarResizer plugin. This plugin was removed in 2017. It’s functionality is part of Openfire itself now. I recommend that you remove the 'avataresizer.jar` file from the plugins directory. That, at the very least, will cause your log files to contain (a lot) less errors.

Another curious find is that CertificateStoreManager appears to be looking at /opt/openfire5 to find a store for connection type SOCKET_S2S. That’s not the standard location of those files. I would expect something like /opt/openfire5/resources/security/truststore. Can you check if in your installation, properties are defined of which the name ends with truststore? It may very well not be (in which case default values are used), but if those properties do exist, they should point to files that exist on your server. I’ll include a screenshot as an example below (obviously, the file locations on your system may be different):

[nobby6]

No that last one is left blank using system default, seems always has.

OK removing that avatarresize, seems to have allowed it to start, just have to test again need to do some edits to startup because its not backgrounding when starting like used to with the old openfire script, I’ll report back, but seems you probably solved the wont start xmpp component which is most important, obviously

[nobby6]

hrmmm, it only runs if we login and run it as root, this is as I hope you can appreciate not a clever thing to do, when wee had the ol bin/openfire and ran that itwas fine, we could run and stop it as calling the user it runs as, this seems no longer possible, well, sure we could edit the openfire.sh file to run as user, but then it gets wiped out on next update.

then trying to run it by su fails for cant find java home, cant run load main class etc etc, and some crap about update-alternatives - isnt that a debian specific thing? maybe a test for that distro would be better .

not sure why you removed bin/openfire after all these years, I didnt see anything in changelog about it, infact 5.0.0 docs still reference bin/openfire

Sorry, we are reverting back to 4.x and staying there for time being.

[the_alexis]

Guus, it seems that update from 4.9.2 to 5.0.0 (at least on Debian 12) breaks the openfire.service autostart. After reboot there are no errors in logs and the service is stopped.
Got this fixed by servicectl enable openfire.service

[guus]

@the_alexis

Got this fixed by servicectl enable openfire.service

Several people have mentioned this. I wonder if it has to do with the systemd-related changes that were applied in this release. That’s all a bit above my paygrade, though. @stokito @akrherz do you have any idea what could be causing this, and if we can fix this in future releases?

[stokito]

@the_alexis @guus thank you for letting me know. The built .deb package was built incorrectly.
I added more details here Jira

Meanwhile as a workaround you can execute: sudo systemctl daemon-reload; sudo systemctl enable openfire; sudo systemctl restart openfire.

This is a CI problem that should be fixed ASAP. For details see OF-2526 .github/continuous-integration-workflow.yml upgrade Ubuntu pacakges by stokito · Pull Request #2875 · igniterealtime/Openfire · GitHub

[guus]

We have just released Openfire 5.0.1! This release fixes a couple of issues that were found, like the malfunctioning Launcher.

[Carmack]

Congratulations!
HTTP file upload plugin no need anymore, correct?