Custom OfflineMessageStrategy

Openfire Openfire Dev
1

For my usage of Openfire I want to implement a custom OfflineMessageStrategy that is basically store or bounce – if the message is flagged as no-store then I want to send the bounce message but if the message can be stored then I want to let it be stored (basically another else if block in OfflineMessageStrategy.storeOffline).

The problem I’m seeing is how to inject my code. OfflineMessageStategy is a module and it appears that modules are defined in XMPPServer’s code and loaded before plugins, making it difficult to inject my changes in. I would like to make my changes without modifying Openfire so that I can continue to upgrade Openfire without having to patch the source every time.

So I have two questions:

  1. Am I missing something and there is a different extension point that I can accomplish this?

  2. Would a patch to make the loading of modules controlled by a config file be welcomed? Something like populate a set with the existing names, then load a modules.xml file from the conf directory, then iterate the set and load module for each. There would also need to be a solution for the implementation class being different from key in the map (probably just an overloaded loadModule method).

Thanks,

Randy

2

In case anyone stumbles across this in the future, pull request has been submitted to address this and should be part of a future Openfire release. You can track the pull request at https://github.com/igniterealtime/Openfire/pull/217

3

We reviewed the proposed approach for XML-based module configuration, but have decided against it for several reasons:

  1. It is difficult to maintain the module configuration, as it hides important implementation details such as handler class names, etc.
  2. It proved to be disruptive to existing implementations (not fully backward compatible)
  3. We have an existing solution for this type of customization using custom overlays

The PR #217 has been reverted via PR#455. Refer to OF-1005 for additional information.

4

Flash forward a couple of months. Randy’s PR was accepted, but I’m proposing to roll it back (here: https://github.com/igniterealtime/Openfire/pull/455 ).

No matter what the outcome, here’s a different approach to tackle the original problem. Openfire: Database Installation Guide describes how pretty much any any file in the Openfire source tree can be overwritten before compilation (as a bonus, you can do that from outside of the source directory, when you provide a simple argument to the buildscript). Originally intended to replace look-and-feel, this now works equally well with source files. Additionally, support was improved in release 4.0.0.

5

also: what he said.