Ok. I found the issue with ComponentManagerFactory.getComponentManager(). It stops working in plugins that have whack.jar. This is new behavour in 3.11 and not sure of the origin. Could be the PR or something else. However, I have bigger issues as Jitsi videobridge has generated a few severe errors.
Looks like ofmeet is going to be stuck with 3.10 for a while.
java.lang.LinkageError: loader constraint violation: when resolving method “org.eclipse.jetty.servlet.ServletHolder.(Ljavax/servlet/Servlet;)V” the class loader** (instance of org/jivesoftware/openfire/container/PluginClassLoader) of the current class, org/jivesoftware/openfire/plugin/ofmeet/OfMeetPlugin, and the class loader (instance of org/jivesoftware/openfire/starter/JiveClassLoader) for the method’s defining class, org/eclipse/jetty/servlet/ServletHolder, have different Class objects for the type javax/servlet/Servlet** used in the signature
at org.jivesoftware.openfire.plugin.ofmeet.OfMeetPlugin.initializePlugin(OfMeetPlu gin.java:196)
I will revisit this later in the future when this PR gets sorted out
Thanks for the tip @CSH, unfortunately, it is becoming more complicated than just removing the jar files. smack.jar has org.xmlpull.xxxxx embedded which is also available through Openfire core. In addition, I still have SEVERE errors coming out of Jitsi videobridge. I am not loving this PR at all
Many of the plugins I develop for a living are like the Jitsivideobridge plugin integrating Openfire with many other Java applications. I need the Plugin ClassLoader to be tolerant of duplicate classes as I can’t afford to repackage the container jar files for various reasons.
I appreciate that you are trying to improve compatibility and increase security between plugins, but a side effect of your change is that there is an issue between the Jive ClassLoader and the PluginClassLoader and this is causing problems for me in ofmeet plugin unless this was caused by another PR different from yours and which case, I apologise.
I am quite happy with the current behaviour of the plugin classLoader in OF 3.10.2. It provides enough isolation between plugins for me and when I want to reuse classes between plugins, I use the “parent” feature.
I develop openfire plugins for a living and have not seen any reason so far to change the current behaviour. This PR as it currently stands in OF 3.11 will generate me a lot of unwanted and undesired additional work and could force me to maintain my own fork of Openfire and compatible plugins going forward.
@Dele Olajide can you provider smark version or source in ofmeet plugin?
Now I found this exception:
java.lang.LinkageError: loader constraint violation: when resolving method “org.jivesoftware.openfire.SessionPacketRouter.route(Lorg/dom4j/Element;)V” the class loader (instance of org/jivesoftware/openfire/container/PluginClassLoader) of the current class, org/jivesoftware/smack/XMPPConnection$OpenfirePacketWriter, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/jivesoftware/openfire/SessionPacketRouter, have different Class objects for the type lement;)V used in the signature
Thanks for your ongoing contributions. I appreciate your efforts to make Openfire better!
Note that plugins are designed to use the internal Openfire APIs and as such must be trusted to cooperate with other internal components (such as not shutting down the JVM, polluting the file system, etc.). If you prefer to have a more secure alternative for building extensions for Openfire, I suggest you consider the External Component API (via Whack). There are several helpful resources for writing external components, such as the following: