On Mon, Nov 23, 2009 at 11:32 AM, Martin Pepin <[email protected]> wrote: > Hi, > > I am getting an unresolved symbol in the Openfire presence plugin when I try > to get a reference to the Openfire Kraken plugin instance. > > The kraken plugin class is contained in a "packed" version in this main > /opt/openfire/plugins/kraken.jar file. When Openfire starts it extracts the > main kraken.jar file contents into a new /opt/openfire/plugins/kraken > directory which contains a set of jar files that I need to refer. More > precisely the /opt/openfire/plugins/kraken/lib/plugin-kraken.jar file so > that I can get a reference to the KrakenPlugin class instance and make API > calls on it. Unfortunately the plugin-kraken.jar is not accessible in > kraken.jar when I make file main/sipXopenfire/build.xml point to > /opt/openfire/plugins/kraken.jar because plugin-kraken.jar.pack is packed > inside kraken.jar. But if I change build.xml to point directly to > /opt/openfire/plugins/kraken/lib/plugin-kraken.jar once the > /opt/openfire/plugins/kraken/… directory is created by starting Openfire at > least once, then the Kraken plugin reference is resolved. > > File: XmppAccountInfo.java > > import net.sf.kraken.KrakenPlugin; > > PluginManager pluginManager = > XMPPServer.getInstance().getPluginManager(); > krakenPlugin = (KrakenPlugin)pluginManager.getPlugin("kraken"); > > -bash-3.2$ jar tvf /opt/openfire/plugins/kraken.jar | fgrep > plugin-kraken.jar > 227512 Thu Sep 03 20:29:20 GMT-05:00 2009 lib/plugin-kraken.jar.pack > > ========================================= > I can see 3 possible solutions and would appreciate your opinions: > > Solution #1: > > Create a softlink in the sipx-openfire plugin that would point to the kraken > jar file(s) we need. This makes the presence of the Kraken plugin mandatory > otherwise the loading of the XmppAccountInfo class will fail when no > plugin-kraken.jar is present. Using direct API calls on the kraken plugin > instance avoids making XML-RPC calls and mimics the behavior of the Kraken > web component. > > -bash-3.2$ ll /opt/openfire/plugins/sipx-openfire/lib > lrwxrwxrwx 1 sipxchange sipxchange 34 2009-11-23 11:01 plugin-kraken.jar > -> ../../kraken/lib/plugin-kraken.jar > -rw-r--r-- 1 sipxchange sipxchange 243106 2009-11-23 10:21 > sipx-openfire-plugin.jar > > Solution #2: > > Copy the kraken jar files we need to reference and package them under the > /opt/openfire/plugins/sipx-openfire/lib directory. This will resolve the > symbol but cause two jar files to reference the same classes. I suspect that > having two versions of the same class might lead to two separate > implementations that could be refered to. > > -rw-r--r-- 1 sipxchange sipxchange 367472 2009-11-23 11:12 > /opt/openfire/plugins/sipx-openfire/lib/plugin-kraken.jar > -rw-r--r-- 1 sipxchange sipxchange 367472 2009-11-19 13:13 > /opt/openfire/plugins/kraken/lib/plugin-kraken.jar > > Solution #3: > > Do not reference the KrakenPlugin symbol and use XML-RPC calls to the Kraken > Plugin. This approach is a lot less efficient but removes the hard > dependencies and coupling between the presence and kraken plugins. > > Thanks, > Martin
Softlink the jar file to /opt/openfire/lib Maybe not as elegant as you would like it to be. Regards Ranga > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
