Spark 2.5.0 SparkPlug development migration

Is there a document describing how to migrate a SparkPlug to Spark 2.5.0 (from 2.0.8, for example)?

Here are some problems I’'ve had so far:

  • main class is now org.jivesoftware.launcher.Startup instead of org.jivesoftware.Spark (required for running in and IDE)

  • Exception: “java.lang.NoClassDefFoundError: javax/media/Renderer”. Perhaps this is a benign log?

  • Exception:

org.dom4j.DocumentException: C:\Documents and Settings\kevin\Spark\xtra\emoticons\Default.adiumemoticonset\Emoticons.pli

st (The system cannot find the path specified) Nested exception: C:\Documents and Settings\kevin\Spark\xtra\emoticons\De

fault.adiumemoticonset\Emoticons.plist (The system cannot find the path specified)

at org.dom4j.io.SAXReader.read(SAXReader.java:266)

at org.jivesoftware.sparkimpl.plugin.emoticons.EmoticonManager.addEmoticonPack(Emo ticonManager.java:207)

at org.jivesoftware.sparkimpl.plugin.emoticons.EmoticonManager.(EmoticonManager.ja va:98)

at org.jivesoftware.sparkimpl.plugin.emoticons.EmoticonManager.getInstance(Emotico nManager.java:78)

at org.jivesoftware.sparkimpl.plugin.emoticons.EmoticonPlugin.initialize(EmoticonP lugin.java:43)

at org.jivesoftware.spark.PluginManager$1.run(PluginManager.java:398)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)

at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:27 3)

at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:17 3)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

  • Now uses Smack 3.0.0. This should be noted in the Changelog.

  • Offline version includes JSE 6. This should be noted in the Changelog.

Message was edited by: mrpantsuit

Message was edited by: mrpantsuit

Also, it seems the ClassLoader strategy has changed. Previously, Plugin#initialize() was called with PluginClassLoader as the context ClassLoader; now it’‘s JiveClassLoader, which doesn’‘t seem to know about my plugin’'s classes.

I changed my initialize() method to temporarily change the context ClassLoader to PluginClassLoader until it returns. Now I’'m getting this:

Apr 3, 2007 4:15:52 PM org.jivesoftware.spark.util.log.Log error

SEVERE:

java.lang.ExceptionInInitializerError

at org.springframework.core.io.DefaultResourceLoader.(ClassUtils.java:65)

… 18 more

Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@1bef1ac for org.apache.commons.logging.impl.Log4JLogger

at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl .java:432)

at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java: 525)

… 22 more

Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger

at java.lang.Class.getDeclaredConstructors0(Native Method)

at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)

at java.lang.Class.getConstructor0(Unknown Source)

at java.lang.Class.getConstructor(Unknown Source)

at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl .java:429)

… 23 more

I suspect this is one of the usual JCL class loading problems (http://www.qos.ch/logging/classloader.jsp), but I have been unable to fix it.

I’‘ve read that Commons Logging 1.1 attempts to resolve some of these problems. Perhaps Spark could migrate to this new version, which should be easy as it’'s fully backwards compatible.

Okay, I think I’'ve figured out why Plugin#initialize() is now being called by JiveClassLoader instead of PluginClassLoader.

Workspace#loadPlugins() used to load the plugins (PluginManager#loadPlugins()) using a SwingWorker, which had the side effect of setting the context ClassLoader (CCL) of the Swing thread to PluginClassLoader. When Workspace.java was changed to use TaskEngine instead of SwingWorker in revision 7571, that side effect was lost. And since PluginManager#initializePlugins() actually invokes the plugin initialization later in the Swing thread, Plugin#initialize() is NOT called with CCL=PluginClassLoader.

This raises the question: Should the Swing thread’'s CCL be PluginClassLoader? If not it will cause hassles for plugins that do any kind of dynamic class loading or resource lookups.

Message was edited by: mrpantsuit

I’'m enjoying this lively conversation with myself, but does anyone from the Spark team care to comment?