To start with, this is probably an odd change request and I have held off asking as it probably has very limited utility outside my particular usecase. However, the changes I had to make to the base are so minor, I figured I would at least float it.
We connect multiple openfire servers running on isolated networks using middleware components (AMQP message queues) to move the messages from one server to another. We have a plugin that handles moving the messages to the message queues on the sending side and picking them up on the receiving side. While we were able to get 99.9% of the code in a plugin, there were some small changes that we had to make to the server code in order to get the packets to our plugin.
We use full domains (to enable our middleware to know which server instance to deliver the packet to) which normally would route the message to the server-to-server code (routeToRemoteDomain) but I made small changes to two of the source files to enable our plugin to be registered with the full domain AND to route message packets to the plugin when appropriate.
Files changes:
InternalComponentManager.java
RoutingTableImpl.java
Before going into any more detail, is anyone open to adding this to to trunk? The biggest change I think would probably be in InternalComponentManager where the Plugin interface might need some sort of flag method to indicate it wants to be registered as a full domain rather than a subdomain? I simply look at the plugin name in my simple customization. Then in RoutingTableImpl, just check the localRoutingTable for a route by that domain (in the final else in method routePacket) and if found, process it.
It may be way too narrow a usecase for the main server code but any thoughts?
Thanks for your offer to share code. I’d suggest providing a patch (diff -u) against current svn trunk and we can take a look at it to offer an evaluation.
What if you used IQ messages with unique namespaces for each domain as envelopes and the Openfire IQ Router to recieve/send your payload messages from your plugin?
XMPPServer server = XMPPServer.getInstance();
AmqpIQHandler = new AmqpIQHandler();
server.getIQRouter().addHandler(AmqpIQHandler);
It might sound too simplistic for what your needs, but it could work without re-engineering Openfire plugin interface to become domain aware.
Otherwise, what if you created dummy client sessions from your plugin to recieve/send messages for each domain? That would handle normal server-to-server federated messages.
Thanks for taking the time to reply Daryl. I could make the changes and provide a patch. I’m no where near an expert on the Openfire code so I don’t even know if what I suggested is the best way to solve the problem. After thinking about it, changing the plugin interface to have a flag method would break every single plugin out there and require a code change and recompile which is clearly a bad idea.
I’ll think about it some more; maybe there is a better design that doesn’t require changing the interface.
Thanks for taking the time to reply Dele. I’ll look into that and see if it would work. I’m not an Openfire expert so it will take me a little while to research it.
If you want to see both methods I mentioned in action, look at the source code for the jitsi-videobridge plugin for Openfire. It uses the IQHandler interface to intercept rayo IQ messages sent to the server with namespace “urn:xmpp:rayo:colibri:1”
The other method of creating dummy openfire sessions like bots is used to create focus agents that send rayo events to users and respond to any replies.
This is fairly old but I wanted to revisit. We are very interested in getting this capability into the main server code which is to be able to register plugin components as full domain handlers. I’m looking through the code trying to find areas where this would be a problem and so far it seems relatively safe and easy.
I propose to add a marker interface that could be implemented by a plugin which would tell the InternalComponentManager to register the plugin component as a full domain handler rather than subdomain. Then the RoutingTableImpl would be able to send the packet through the routeToComponent logic by calling hasComponentRoute and, if true, sending the packet to the plugin and the plugin would handle it.
This seems fairly trivial to implement but I’m not 100% sure it doesn’t have side effects. Would it be possible to get a patch that did this into the main development line?