Still the same issue with this particular class. I see the following in the plugin server logs when the plugin is initializing:
Caused by: java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.decodeBase64(Ljava/lang/String;)[B at com.xxx.remedy.plugins.extractor.Job.setPassword(Job.java:642) at com.xxx.remedy.plugins.extractor.Job.setFailsafeDefaults(Job.java:355) at com.xxx.remedy.plugins.extractor.Config.configureJobs(Config.java:56) at com.xxx.remedy.plugins.extractor.Config.<init>(Config.java:30) at com.xxx.remedy.plugins.Extractor.init(Extractor.java:51) ... 9 more The class path is set up with the directory that contains the jar that has this class first in the class path: $ pargs 23237 23237: ./java -Dpname=PluginSvrMain -server -Xms128m -Xmx512m -XX:PermSize=32m -XX:Max argv[0]: ./java argv[1]: -Dpname=PluginSvrMain argv[2]: -server argv[3]: -Xms128m argv[4]: -Xmx512m argv[5]: -XX:PermSize=32m argv[6]: -XX:MaxPermSize=32m argv[7]: -XX:+UseConcMarkSweepGC argv[8]: -XX:-UseParNewGC argv[9]: -Djava.library.path=/path/to/lib:/path/to/pluginsvr:/path/to/ARSystem/bin:/path/to/api/lib argv[10]: -Djava.awt.headless=true argv[11]: -Dhttp.proxyHost=nyproxy argv[12]: -Dhttp.proxyPort=80 argv[13]: -Djava.security.policy=/path/to/jmx/server.policy argv[14]: -Dcom.sun.management.jmxremote argv[15]: -Dcom.sun.management.jmxremote.ssl=false argv[16]: -Dcom.sun.management.jmxremote.access.file=/path/to/jmx/jmxremote.access argv[17]: -Dcom.sun.management.jmxremote.local.only=false argv[18]: -Dcom.sun.management.jmxremote.port=1234 argv[19]: -Dcom.sun.management.jmxremote.password.file=/path/to/jmx/password.properties argv[20]: -Dlog4j.configuration=/path/to/pluginsvr/log4j_pluginsvr.xml argv[21]: -classpath argv[22]: /path/to/lib:/path/to/pluginsvr:/path/to/pluginsvr/arpluginsvr75.jar argv[23]: com.bmc.arsys.pluginsvr.ARPluginServerMain argv[24]: -x argv[25]: server argv[26]: -i argv[27]: /path/to/ARSystem The jar in /path/to/lib is commons-codec-1.6.jar. This file contains the class that has the referenced method: $ jar -tvf /path/to/lib/commons-codec-1.6.jar |grep Base64 8314 Fri Dec 02 21:37:14 EST 2011 org/apache/commons/codec/binary/Base64.class 929 Fri Dec 02 21:37:14 EST 2011 org/apache/commons/codec/binary/Base64InputStream.class 939 Fri Dec 02 21:37:14 EST 2011 org/apache/commons/codec/binary/Base64OutputStream.class I think the problem is that the main jar (arpluginsvr75.jar) also contains this particular class: $ jar -tvf /path/to/ARSystem/pluginsvr/arpluginsvr75.jar |grep Base64 5468 Sat Jul 10 16:13:00 EDT 2004 org/apache/commons/codec/binary/Base64.class So that even though the jar file that contains the desired class comes first in the classpath, the classloader is loading the classes from the main jar (arpluginsvr75.jar) first. This has to do with the way the plugin server initializes, such that it uses it's bundled org/apache/commons/codec/binary/Base64.class over the one that comes first in the classpath. I changed the classpath to reference the jar instead of the path to the jar and this seems to have fixed the issue. I used the -verbose option for the JRE to see where it was being loaded from and now I see the following: [Loaded org.apache.commons.codec.binary.Base64 from file:/path/to/lib/commons-codec-1.6.jar] Thanks for the pointers. We will see if this breaks anything in the plugin server. Maybe it just be easier to write my own class to base64 encode/decode. Axton Grams On Tue, Feb 14, 2012 at 3:44 PM, LJ LongWing <[email protected]> wrote: > Axton, > I have experienced that if you have the same classes in multiple jar files, > that it uses the one that's in the classpath first, first. So...if you add > the newer versions of the classes in your jar first, then the plugin server > jar file, that I believe it should use the new ones before the old ones. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Axton > Sent: Tuesday, February 14, 2012 2:22 PM > To: [email protected] > Subject: Java Plugin Server - Class conflict > > I am trying to use Apache Commons Codec 1.6 in a plugin I am writing. > The plugin server jar contains these classes, though an old version > (too old to do what I would like to do): > > $ jar -tvf arpluginsvr75.jar |grep 'org/apache/commons/codec/' > 0 Sun Sep 20 09:23:16 EDT 2009 org/apache/commons/codec/ > 0 Sun Sep 20 09:23:16 EDT 2009 org/apache/commons/codec/binary/ > 0 Sun Sep 20 09:23:16 EDT 2009 org/apache/commons/codec/digest/ > 0 Sun Sep 20 09:23:16 EDT 2009 org/apache/commons/codec/language/ > 0 Sun Sep 20 09:23:16 EDT 2009 org/apache/commons/codec/net/ > 268 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/BinaryDecoder.class > 268 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/BinaryEncoder.class > 248 Sat Jul 10 16:13:00 EDT 2004 org/apache/commons/codec/Decoder.class > 391 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/DecoderException.class > 248 Sat Jul 10 16:13:00 EDT 2004 org/apache/commons/codec/Encoder.class > 391 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/EncoderException.class > 300 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/StringDecoder.class > 300 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/StringEncoder.class > 1190 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/StringEncoderComparator.class > 5468 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/binary/Base64.class > 2969 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/binary/BinaryCodec.class > 2624 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/binary/Hex.class > 704 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/binary/package.html > 1860 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/digest/DigestUtils.class > 708 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/digest/package.html > 2470 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/language/DoubleMetaphone$DoubleMetaphoneResult.clas > s > 14791 Sat Jul 10 16:13:00 EDT 2004 > org/apache/commons/codec/language/DoubleMetaphone.class > 5050 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/language/Metaphone.class > 2349 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/language/RefinedSoundex.class > 3286 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/language/Soundex.class > 1583 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/language/SoundexUtils.class > 674 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/language/package.html > 2661 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/BCodec.class > 4052 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/QCodec.class > 4511 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/QuotedPrintableCodec.class > 2435 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/RFC1522Codec.class > 252 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/StringEncodings.class > 4432 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/URLCodec.class > 696 Sat Jul 10 16:13:02 EDT 2004 > org/apache/commons/codec/net/package.html > 1022 Sat Jul 10 16:13:02 EDT 2004 org/apache/commons/codec/overview.html > 3283 Sat Jul 10 16:13:02 EDT 2004 org/apache/commons/codec/package.html > > The problem is that the plugin resolves and uses the classes in the > plugin server jar file, not the jar file I have referenced in my > plugin server configuration: > > <plugin> > <name>ARF.PLUGIN</name> > <type>FilterAPI</type> > <code>JAVA</code> > <filename>/path/to/plugin.jar</filename> > <classname>com.newyorklife.remedy.plugins.Extractor</classname> > <pathelement type="location">/path/to/javacsv.jar</pathelement> > <pathelement > type="location">/path/to/commons-codec-1.6.jar</pathelement> > <pathelement type="location">/path/to/mail.jar</pathelement> > <pathelement > type="location">/path/to/commons-lang3-3.1.jar</pathelement> > <userDefined> > <configfile>/path/to/config.properties</configfile> > </userDefined> > </plugin> > > Any ideas on how I can change the behavior of the classloader? Do I > need to use something like java.lang.classloader? > > Thanks, > Axton Grams > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
