powered by Jive Software

Merged monitoring/open archive plugins

Latest plugin attached below: Version 1.3.1-rc1

By merging the open archive plugin with the openfire monitoring plugin we’ve created a new monitoring plugin which has chat and group chat archiving (from monitoring) as well as XEP-0136 Message Archiving support (from open archive).

The base plugin is the Openfire Monitoring plugin.

Only issue is that the archive plugin is GPL2 licensed and the monitoring plugin is Apache licensed (right?). Best I can tell the two licenses combine fine:


We use the plugin internally but I’m happy to share the source (took some work integrating the two) if anyone wants it.


Work and a new baby got in the way of my best intentions, but despite being a little late we’re happy to let everyone know that the updated Monitoring plugin is in Openfire trunk.

We wanted to originally add the plugin as a separate Maven project since the Openfire Ant build is a touch archaic (but functional! ) However due to the way the Maven-Openfire Plugin works and an issue in DWR 1.1.3 (it does not resolve classes outside its own lib folder) we had to put the new Monitoring plugin src in the Openfire trunk and compile it the Ant way.

The upshot of this is that all the graphing and statistics pages work just fine.

A change to the database schema of the Monitoring plugin was made to support the XEP-0136 spec. We’ve tried our very best to handle the database upgrade for all the supported DBs as best as possible.



Any bugs please contact me or ideally file in JIRA (I believe you can file them against leonroy).


Following confirmation from Stefan Reuter and Ignite I can confirm that the new merged plugin is indeed under the Apache license.


Monitoring plugin 1.3.1-rc1 closing the below bugs:

  • OF-646 - Reverts XmppDateTimeFormat integration which broke querying via XEP-0136.
  • OF-664 - Monitoring archive shows null in room chat logs.
  • OF-667 - Monitoring plugin bad SQL for upgrade

Some of the plugins broke compatibility with Openfire 3.6 and 3.7. The new version of the plugin is now compatible with Openfire 3.6 and 3.7.

http://issues.igniterealtime.org/browse/OF-611 Is still pending, I know some of you who upgraded to 1.3.0 have missing messages but fear not there is no data loss. It’s still in there.

Once I have time I’ll release 1.3.2 which will safely restore those messages.


Thanks for offering the contribution. We are always looking for subversion committers at ignite. Would you like to maintain your plugin on ignite’s infrastructure?


If you see any licensing issues I am happy to contribute the open archive code unter Apache license. I chose GPL when I wrote it mainly because all other Openfire projects where on GPL at that time.


Yes please I have been waiting for it ever since I knew about it. It would make a great contribution to the community.

A big thank you for contributing it back

Hi Stefan, that would be great since we personally find companies are much more willing to use software if it’s licensed under the Apache License.

No problem, expect to see more (in drips and drabs ) over the coming months.

Hi Daryl, I’d be happy to maintain it on Ignite’s repo although it’s not a huge deal for us to expose our SVN to the world.

Only issue with moving to Ignite’s SVN that I can think of is that the whole plugin has been migrated over to Maven. I’ve seen talk of moving to Maven on the Ignite mailing list so be a pity to take a step backwards and shoe horn the plugin into the existing openfire/trunk/src/plugins folder.

Let me know the credentials/folder for the Ignite SVN, or whatever you and the community prefer. Ideally a separate folder for the plugin (ie. like with the asterisk-im plugin).

Are there any objections against github or similar? It’s so much easier to fork a project and contribute back than via svn…

Github is the place to be. The only reason why some of us still use svn on code.google.com instead of ignite svn or even github is that it jumps the queue on google search


I am all for moving ignite’s svn to github. Lets see if I can get the ball rolling on that.


I am not in favor of moving to GitHub. Although I readily agree that it’s a more up-to-date SCM, I do not believe that the benefits of moving to GitHub outweigh the downsides of such a move.

My primary concern is that this would move our code from our servers to a third party. Even though we’re creating open source software, I’d like to avoid adding this dependency.

Apart from that, I wonder if the many (likely small, but annoying) issues that result from such a move outweigh the actual benefits that we have. I’m considering that although in theory a lot more is possible after a move to GitHub, in practice not nearly all of these possibility would actually be used. For me, the cost/benefit ratio doesn’t tip over to the benefit side.

k, i’ve updated the license:

https://github.com/srt/openarchive/commit/4247b05393755d7e51f2def70f30596f4c8d9b 7a

1 Like

I think the immediate question is where to host plugins (openfire & spark) and other revisable resources that are contributed projects and then become part of the community.

Like Guus, I don’t think there are benefits to moving the core projects. If it is not broken, then let’s go fix some thing else Jive Software provides good infastructure support. No point adding a third party.

I am going to continue to mix and match google-svn and github depending on the project and its requirements.

Incidentally, there are at least two or three forks of openfire 3.7.1 in Github. I use of them because it has implemented supports for CORS which I need in some of my projects.

Hi Dele, the CORS patch went into svn trunk this week Hopefully it works!


Daryl, Thanks for the info. I will give it a test and report back.

It did not work in Chrome until I changed these two lines (82/84) in HttpBindManager.java

public static final String HTTP_BIND_CORS_ALLOW_METHODS_DEFAULT = "PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST"; public static final String HTTP_BIND_CORS_ALLOW_HEADERS_DEFAULT = "Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control";

Thanks for much for pushing this change. I can now go back to official SVN.

Thanks, sent this change into svn as well.

Okey doke, sounds like keeping the new monitoring plugin in Ignite’s SVN might be most straightforward, let me know the SVN redentials you’d like me to use.

Thanks, will private message you shortly with that.


Is it alright to use this plugin with a clustering setup? Could you paste the link where I can check out the code?

Best Regards,

Stevenson Lee