Using the updated apache-commons-codec seems to cause the plugin server to issue a call that causes arserver to crash. Here is the stack trace from the plugin server:
Exception in thread "job-scheduler" java.lang.NullPointerException at org.apache.commons.codec.binary.Base64.encode(Base64.java:380) at org.apache.commons.codec.binary.BaseNCodec.encode(BaseNCodec.java:340) at com.bmc.arsys.arencrypt.f.try(Unknown Source) at com.bmc.arsys.arencrypt.f.encryptData(Unknown Source) at com.bmc.arsys.arencrypt.PasswordEncryption.encryptPasswordEx(Unknown Source) at com.bmc.arsys.arencrypt.PasswordEncryption.encryptPasswordEx(Unknown Source) at com.bmc.arsys.arrpc.xdr.ArRpcPassword.setPasswordStr(Unknown Source) at com.bmc.arsys.api.session.g.a(Unknown Source) at com.bmc.arsys.api.ProxyJRpc.loadRpcControlStruct(Unknown Source) at com.bmc.arsys.api.ProxyJRpc.ARGetServerInfo(Unknown Source) at com.bmc.arsys.api.ARServerUser.getServerInfo(Unknown Source) at com.bmc.arsys.api.ARServerUser.getServerVersion(Unknown Source) at com.bmc.arsys.api.ARServerUser.getServerVersionMajor(Unknown Source) at com.bmc.arsys.api.ARServerUser.usePrivateRpcQueue(Unknown Source) at com.newyorklife.remedy.plugins.extractor.Job.run(Job.java:154) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Which causes arserver to crash with this stack trace: Wed Feb 15 11:03:00 2012 11 Timestamp: 1329321780.4503 Thread Id: 76 Version: 7.5.00 Patch 003 200909292346 Apr 28 2010 14:12:04 ServerName: server Database: SQL -- Oracle Hardware: sun4u OS: SunOS 5.10 RPC Id: 15000 RPC Call: 73 (GLEWF) RPC Queue: 390621 Client: User Demo from Unidentified Client (protocol 14) at IP address 1.2.3.4 Logging On: API Escalation Filter SQL User Thread Stacks: ^@/path/to/ARSystem/bin/arserverd:DumpStackTrace+0x110 /path/to/ARSystem/bin/arserverd:SignalTrapProc+0x228 /lib/sparcv9/libc.so.1:0xd6fdc /lib/sparcv9/libc.so.1:0xcab70 /lib/sparcv9/libc.so.1:0xcad7c /path/to/ARSystem/bin/arserverd:VerifyControlRecord+0x7c8 [ Signal 11 (SEGV)] /path/to/ARSystem/bin/arserverd:0x47f81c /path/to/ARSystem/bin/arserverd:argetlistentrywithfields_14_svc+0xf4 /path/to/ARSystem/bin/arserverd:HandleRPCs+0x2c2f4 /path/to/ARSystem/bin/arserverd:WorkerThread+0xcb0 /path/to/ARSystem/bin/arserverd:RestartableThreadMain+0x88 /path/to/ARSystem/bin/arserverd:UnixThreadStartRoutine+0x17c /lib/sparcv9/libc.so.1:0xd6eb0 Guess I'm off to re-factor this class or write my own. Axton Grams On Wed, Feb 15, 2012 at 10:21 AM, Axton <[email protected]> wrote: > 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"
