Hi, during exploring the OpenFire’s code, I found another problem. I want to use my own AuthProvider - it’s easy to set this provider in settings (xml or directly in db using of web interface). There are several build-in providers (like JDBCAuthProvider), but I need something more custom, so I decided to write my own provider. I hope it’s nothing strange to use my own class.
But. I can’t deploy the code as a plugin, because all plugins are loaded AFTER the server bootstrap, (after XMPPServer::loadModules()), so at the bootstrap time, the library could not be found…
I understand, that it’s a bit more complicated as plugins may register listeners on some core modules, so we need these modules to be initialized already… So, the sollution could be: add another phase… Something like:
1/ loadPlugins (only create the plugin classes, load libs, etc.)
2/ load/init all core modules (RosterManager etc)
3/ initPlugins (register plugin’s listeners to modules etc.)
as soon as you have written your own provider you will likely create a jar file and add it to the Openfire lib directory. So Openfire should be able to find and load your new provider during startup without problems.
Actually, great care is taken to differentiate the classpaths of plugins from those of Openfire itself. If we wouldn’t do this, things would hook into eachother at a pretty low level, quite likely preventing you from ever unloading a plugin again (other than shutting down the system).
Another problem in changing the startup order as you proposed is that in the current order, plugins can rely on several services (the modules) after the plugin is loaded. In your suggestion, this assurance isn’t there. This opens the door for nasty bugs.
I’d like to keep the order of component/plugin loading as-is, as it provides additional safety. If a developer needs access deeper in the internals of Openfire, he’s likely to know what he’s doing - and able to modify Openfire more structurally than through the Plugin API.