In pull request https://github.com/igniterealtime/Openfire/pull/217 Randy Layman introduced a new feature where Openfire modules were no longer hardcoded to their interface, but rather loaded by configuration through a newly added modules.xml
Although the implementation is sound, the feature doesn't work out for me. There is added complexity in maintaining the new modules.xml file, which can introduce problems when upgrading from earlier versions (we've seen a couple of instances when users upgraded to the new Openfire 4.0.0 beta-1 - this primarily seems to affect Windows-based installations).
Obviously, we could fix the upgrade scripts, but it's questionable if the new feature is worth the added complexity. The exact some functionality is offered by adding a custom XMPPServer.java implementation through an overlay.
In pull request https://github.com/igniterealtime/Openfire/pull/217 Randy Layman introduced a new feature where Openfire modules were no longer hardcoded to their interface, but rather loaded by configuration through a newly added modules.xml
Although the implementation is sound, the feature doesn't work out for me. There is added complexity in maintaining the new modules.xml file, which can introduce problems when upgrading from earlier versions (we've seen a couple of instances when users upgraded to the new Openfire 4.0.0 beta-1 - this primarily seems to affect Windows-based installations).
Obviously, we could fix the upgrade scripts, but it's questionable if the new feature is worth the added complexity. The exact some functionality is offered by adding a custom XMPPServer.java implementation through an overlay.
We should revert the new modules.xml feature.