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"
