Openfire 4.0.0 Released

Almost 4 weeks ago, we released a beta of Openfire 4.0.0. Now, it’s time for the real thing.

Openfire 4.0.0 is now available for immediate download. The Beta has been run in production by developers for some time, and we believe this is the best ever Openfire release, containing many new features and fixing dozens of bugs. It marks the culmination of a real resurgence in Openfire development.

We advise all users to plan on upgrading; the 3.10 branch will not be receiving anything other than critical fixes. The new 4.0 branch will be the focus for bug fixes, and the trunk is now 4.1.

Many of the plugins available from Ignite Realtime: Openfire Plugins will only work on 4.0.0, and will therefore require this upgrade.

You can download the new release from: Ignite Realtime: Downloads

A changelog is here: Openfire Changelog

SHA-1 Checksums are:

Platform
SHA-1 Checksum
Filename
Mac OS X
854b9c781da9de4c34af208341a1b1e60aa7508f
openfire_4_0_0.dmg
Debian / Ubuntu
3fde5503a3b82465c120432072f453af0338eb35
openfire_4.0.0_all.deb
Redhat / CentOS
18c2471fb08a995ac04c3ca7bbd57ae267e7b22b
openfire-4.0.0-1.i386.rpm
Windows
a966a87bfb9a03ef3a02724613b4d501202bb34f
openfire_4_0_0.exe
Source (ZIP)
db30258ffb99218c9b1749b7aab8404bc01a9330
openfire_src_4_0_0.zip
Source (UNIX)
130e67f15b36cb23918e14db8e458bc1cb9ad190
openfire_src_4_0_0.tar.gz
ZIP
92091acaeeaab33a218625149d1b81265ef4de99
openfire_4_0_0.zip
Tarball
12aee2c4eb9cbd08eeb3fc15fd08aaf47484d5a2
openfire_4_0_0.tar.gz

5 Likes

Hello

Thank you very much for updating openfire

A couple of weeks ago I update from 3.10.3 to the beta 4.0.0

Today I’m trying to update from beta to final release of 4.0.0, but a get this error:

(Our server is mounted on Centos 7)

rpm -Uvf openfire-4.0.0-1.i386.rpm

Preparing packages…

package openfire-4.0.0.beta-1.i386 (which is newer than openfire-4.0.0-1.i386) is already installed

Any suggestions ??

Its an RPM issue, just force update it. rpm -Uvh --force openfire-4.0.0-1.i386.rpm

1 Like

The --force option did the trick.

Thank you

Is there an easy to read list of improvements with this major release other than the changelog? There’s 97 issues listed in there and skimming it doesn’t easily summarize “many new features” or explain why it’s the best release ever.

@Chris H Jira, our issue tracker, offers all kinds of features to browse, filter and order issues. Perhaps that’ll be of help to you. Have a look at Release Notes - Jive Software Open Source to get started.

I’m not sure if it’s happening just to me, but even if I update the plugin list in web admin console, I just see less than 10 plugins. :frowning:

This is with Openfire 4.0 installed? If you are using an older version, you will see a much smaller list.

@Marcelo Terres / The specified item was not found. Thank you for reporting this. I have been able to reproduce the problem. We are working on a fix. Progress can be tracked in this JIRA issue: [OF-1038] List of available plugins is missing entries. - Jive Software Open Source

The issue with missing plugins is fixed. It turned out to be a problem related to caching which is done on the website that hosts the plugins (I have migrated the original JIRA issue to [WEB-36] List of available plugins is missing entries. - Jive Software Open Source).

Your instance of Openfire should eventually download a new list of available plugins. To speed up this process, delete the update.lastCheck system property (in the Admin Console: Server -> Server Manager -> System Properties)

1 Like

I’m with you, buddy. mine has 9-installed plugin plus 6-available plugins. Total of 15-plugins. Openfire has total 35-plugins. I guess it shows only those plugin compatIble with 4.0.0.

Thanks, Guus.

if you have time; please check this out;

2016.01.12 13:37:32 org.jivesoftware.util.Log - error drawing PDF footer: http://127.0.0.1:9090/plugins/monitoring/images/pdf_generatedbyof.gif is not a recognized imageformat.

always shows up each time you view statitics report.

Just tried to update to 4.0.0 from 3.10.3 (Running on Centos 7.2)

The RPM installs fine and the service starts but none of the TLS/SSL settings work so users cannot login nor can I access the Admin Page on port 9091

It seems to be unwilling (?) to import my keystore and truststore settings (all fine and verified with keytool and works on 3.10.3 still)

I’ve had to roll back for the time being

Just wondering if anyone else has had similar issues

@Gatt 4.0.0 does include a number of changes related to TLS as well as store management. As of yet, we haven’t had any other reports of problems though. Are there relevant messages in the log files?

Ok I’ve managed to get the console to connect over SSL (there was a trailing slash in my xmpp.socket.ssl.keystore and xmpp.socket.ssl.trsuststore properties - removing that resolved that, but clients are still unable to connect

Under TLS/SSL Certificates there are no values under Indentity Store for:

  • XMPP Client Stores
  • BOSH (HTTP Binding) Stores

The keystore shows up under the other settings though

I’m also seeing this in the error log:

==> error.log <==

2016.01.12 14:42:54 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to error while processing message: </stream:stream>

java.lang.NullPointerException

*** at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:153)***

*** at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceive d(DefaultIoFilterChain.java:690)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)***

*** at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapte r.java:109)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)***

*** at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flus h(ProtocolCodecFilter.java:407)***

*** at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:236)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)***

*** at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)***

*** at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)***

*** at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)***

*** at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(Ordere dThreadPoolExecutor.java:769)***

*** at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(Order edThreadPoolExecutor.java:761)***

*** at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThr eadPoolExecutor.java:703)***

*** at java.lang.Thread.run(Thread.java:745)***

@Gatt Thank you for the feedback. Good to hear that you solved part of the problem.

The Exception in your logs is a problem. I’ve created this issue in our issue tracker for it: [OF-1042] NPE in stanza handler (after failed TLS?) - Jive Software Open Source

It appears to manifest itself only after TLS fails. As a workaround, you could try disabling TLS completely (to see if clients can connect without encryption).

I have also created an issue for the trailing-slash issue: [OF-1043] Certificate stores fail to load when property includes trailing slash - Jive Software Open Source

Thanks, though just to clarify for OF-1043 as I may have confused slahses!

I originally had /resources/security/keystore which did not work
changing it to either a full path (
/opt/openfire/resources/security/keystore
) or to resources/security/keystore) was the resolution

I’ll try and disable TLS for now and let you know if that works

I was just thinking that OF-1043 didn’t make much sense. Indeed, you need either a absolute path, or a path relative to the directory in which Openfire is installed. I don’t think that this was any different in earlier releases of Openfire though.

Yeah sorry about that!

Disabling TLS/SSL works and I can connect for now!

Good. We’ll work on a fix for the original problem, but in the time being, you can at least serve your clients again.