bit of a newb question possibly, I have setup my dev environment in Eclipse and everything is working OK. I have a servlet which I adapted from the userService plugin which in eclipse compiles but when I try to build it complains about the import statement for the org.jivesoftware.openfire.plugin.BroadcastPlugin class. A code extract below:
So when I run the build I get an error message in the console like so:
_
C:\Dave\MyProject\development\operfire_src\openfire\src\plugins\myplugin\src\jav a\com\myprojectopenfire\plugin\myplugin\MyServlet.java:16: package org.jivesoftware.openfire.plugin does not exist
As I mentioned, in eclipse it compiles OK with no problem referencing this class but the ant build fails. If I remove the references to BroadcastPlugin class the ant build works fine and I can run my servlet.
I’m afraid I don’t have much knowledge of ant so any help would be very much appreciated.
in general a plugin don’t have other plugins in there build path. In Eclipse you can easy modify your build path that it compiles with no errors, but using ant with the official build.xml is a good way to see if the classpath is correct. I have a similar question, but I saw your thread too late and that’s why I startet a thread at http://www.igniterealtime.org/community/thread/34013.
You have to load classes of other plugins dynamically using the class loader, because you have to be prepared that other plugins you dependent on are not installed. You also have to deal with the case that a newer version of you dependency is released. What does happen if the interface is changed?
However, I would take a look into Openfire’s source where it does load plugins. A good point to start would be org.jivesoftware.openfire.container.PluginManager.loadPlugin() and possibly org.jivesoftware.openfire.container.PluginClassLoader.
@drh:
If you only want to use the BroadcastPlugin…wouldn’t it be much easier just to include this directly in you plugin? It’s just one single class and you don’t have to deal with all the problems described above. Just make sure it is located in another distinct package, to avoid problems if both plugins are installed. Also you should not claim the source of the BroadcastPlugin as your own, but that should be clear…
A simple way for you would be to provide your API as library and place it in each plugins lib-directory. It’s possible that the class loader is intelligent enough to detect if the same library is loaded multiple times.
Thanks for your answers. I get unfortunately a ClassCastException when I cast an implementation of an interface from a libary in a different plugin. So the only way that I see is the manual handling of objects and access of methods by describing the name and parameter types in the runtime. I hoped for a better way to realize it, but it’s a way to go forward.
it seems I didn’t read the plugin developer guide carefully. Here is described:
When a plugin has a parent plugin, the parent plugin’s class loader will be used instead of creating a new class loader.
This is exactly what I was looking for. Both techniques have their advantages and disadvantages, it’s nice to have a choice.
Sorry to bring up an old topic, but I’m trying to do the same now, use my plugin to access another plugin.
I tried putting the required plugin jars in the lib folder of my plugin and got the casting problem Guenther mentions.
Tried the loadClass method of PluginManager but to cast that generic class to make it useful I still had to import the thing I was casting to, so same problem.
Did you guys figure a way to get plugin to plugin interaction?