Recommended approach to make plugins expose services to other plugins and what about IOC / DI in openfire?

Openfire Plugins
1

Hi there,
at our company over the years we have developed several plugins to give us Push functionality, Room and group management, translating system events to readable information and the like.
Sometimes, what was required was external access, and this we managed by exposing servlets, sometimes, XMPP clients required the services and we exposed IQHandlers or registered Interceptors.
But, for example, one of my latest developments was a functionality to allow web clients to quickly request the last message for each of their contacts in a single shot, and yes, I know, they could have fired off a MAM request for each contact, but that takes time and network.
This is of course a small missing functionality in XEP 313 and I’m not asking for the Monitoring plugin to go against the spec. and I wanted the resulting messages to fly off in good mam:1 fashion not to make any parsing changes client side. So I thought it out and determined I had two options.

  1. was to manually query the archive with another plugin using similar queries to what the monitoring plugin uses.
  2. Was to use the pluginmanager and reflection to invoke the MonitoringPlugin findMessages function and get the result.

This got me thinking though that both are rather fragile approaches, what if a new version of the monitoring plugin changes the table model? What if the plugin is updated and breaks the functionality that I am accessing through reflection?

So, given it would be beneficial for us, to be able to expose specific functionality across plugins without having to bother the network stack, is there a recommended approach? Is there a service container in use that I am unaware of, or could it be an interesting feature to add to openfire?

As usual, all suggestions and comments are welcome,
Paolo Manili

1 Like
2

You can improve on this solution, and remove the fragility: Plugins can define a “parent plugin” by adding an element named parentPlugin in the plugin.xml. The value of that element should be the name of the parent plugin (given as “foo” for the “foo.jar” plugin).

When a plugin has a parent plugin, the parent plugin’s class loader will be used instead of creating a new class loader. If you define ‘monitoring’ as the parent of your plugin, you can directly invoke the Java methods of the monitoring plugin - no nasty reflection needed.

1 Like
3

Thank you so much! That’s great, and I think I can use the same approach for some of our other plugins to remove bloat and redundancy :slight_smile: