I’ve been working on trying to make Openfire integrate nicely with a vBulletin setup. This will allow communities to have a very nice, full featured instant messenger setup. I’ve run into a bit of a stumbling block, though: Any user of my plugin would actually have to have the class files available at server startup, and making that work properly for the user seems difficult.
In looking into things, I have found that org.jivesoftware.openfire.auth.AuthFactory has a static method: initProvider. This method is declared as private.
My question becomes this: Why is it private? Why could a plugin not be allowed to call this method? I assume that a reason exists, but I have been unable to find it or figure it out on my own. If I make a patch that makes it (and other relevant methods for userprovider/etc) public, so that my plugin can register itself properly, would this patch be accepted?
The question of using a plugin as an AuthProvider has come up a few times before. If you do a search for “plugin provider” you can read about some of the issues that come up when trying to do what you’re proposing. This discussion is particularly relevant.
Hope that helps,
You are correct. I can see where people have accepted that they build a .jar, put it in the lib directory, and everything works. My only complaint with this method is that it seems like more work for an admin than it needs to be, plus it adds a requirement for a level of access that might not be desirable. To be precise, a person might well have admin access to Openfire, but not have file level access on the server to place the new .jar file.
That’s why I’m wondering why the initProvider() method(s?) are private. I couldn’t find a reason for that, so I can’t tell what would happen if I submit a patch that allows a plugin to provide a new AuthProvider.