I got the plugin working using the Apache Commons Codec bundled with the plugin server. The version bundled with the plugin server is ~8 years old (version 1.3). I submitted an enhancement request to update the Apache Commons libraries used by the plugin server.
I used the same arpluginserver.jar to compile and run the plugin, but the jar contains the apache commons jar files, which I replaced with the newer version, which caused the problem. The method org.apache.commons.codec.binary.Base64.encode changed from accepting a byte[] to String, or in the newer version it accepts either a byte[] or String, which I could see barfing things up with the plugin server. Axton Grams On Wed, Feb 15, 2012 at 11:22 AM, Ben Chernys <ben.cher...@softwaretoolhouse.com> wrote: > Just one thing I note (again, not being a java guy) but I see the SEGV on > VerifyControlRecord. I have seen this (esp.) on Solaris on earlier versions > when you mix up the compile and run library versions. If it's a plugin > server you're writing this is especially true and the releases must match > between the server and the app. The control record has changed in size over > the releases. > > Check your java versions down the java paths. > > Cheers > Ben > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton > Sent: February-15-12 17:44 > To: arslist@ARSLIST.ORG > Subject: Re: Java Plugin Server - Class conflict > > 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 <axton.gr...@gmail.com> 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.acce >> ss >> 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.pro >> perties >> 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 <lj.longw...@gmail.com> > 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:arslist@ARSLIST.ORG] On Behalf Of Axton >>> Sent: Tuesday, February 14, 2012 2:22 PM >>> To: arslist@ARSLIST.ORG >>> 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$DoubleMetaphoneResu >>> lt.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" > > _______________________________________________________________________________ > 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"
