IC57518: CLASSNOTFOUNDEXCEPTION WHEN USING THE WEBSPHERE MQ VERSION 7 JAVA/JMS CLIENT

WebSphere MQ V7.0 for i5/OS Fix Pack 7.0.0.2
WebSphere MQ V7.0 Fix Pack 7.0.0.2
WebSphere MQ V7.0 Fix Pack 7.0.1.1
WebSphere MQ V7.0.1 for i5/OS Fix Pack 7.0.1.1
WebSphere MQ V7.0 Fix Pack 7.0.1.2
WebSphere MQ V7.0.1 for i5/OS Fix Pack 7.0.1.2

APAR status

• Closed as program error.

Error description

• Customers using either WebSphere MQ Version 7 Java or Java
  Message Service (JMS) application may get a
  java.lang.ClassNotFoundException, with the top of the stack
  possibly containing:
  
   at java.net.URLClassLoader.findClass(URLClassLoader.java
     (Compiled Code))
   at java.lang.ClassLoader.loadClass(ClassLoader.java
     (Compiled Code))
   at java.lang.ClassLoader.loadClass(ClassLoader.java
     (Compiled Code))
   at java.lang.Class.forName1(Native Method)
   at java.lang.Class.forName(Class.java(Compiled Code))
   at com.ibm.msg.client.commonservices.cssystem.CSSystem.
     loadClassInternal(CSSystem.java:124)
   at com.ibm.msg.client.commonservices.cssystem.CSSystem.
     dynamicLoadClass(CSSystem.java:59)
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects all users of WebSphere MQ Version 7 who are
  connecting from a Java or JMS application to a queue manager,
  with a 1.4.2 level Java Runtime Environment (JRE)
  
  Platforms affected:
  All Distributed (iSeries, all Unix and Windows) +Java
  ****************************************************************
  PROBLEM SUMMARY:
  In a basic command line application, there are 3 classloaders
  in a hierarchy - the bootstrap classloader at the top, the
  extension classloader, then the application classloader. The top
  loads basic Java classes from the bootstrap classpath; the
  extension loads extensions for the jre/lib/ext directory; lastly
  the application classloaders runs using the standard CLASSPATH.
  Threads also have an associated classloader - the thread context
  classloader - which is usually the same as the application
  classloader.
  
  The failing thread here is the JmqiAsyncConsumer thread, which
  is used by applications connecting to a queue manager in
  BINDINGS mode. In WebSphere MQ Version 7, the queue manager
  implements true asynchronous consume functionality. Therefore a
  thread will originate in the queue manager, pass over through
  the JNI code into JMQI local (gets attached to the JVM as the
  JmqiAsyncConsume thread), and then goes on to deliver the
  message - via the onMessage() method - to the application.
  
  Replicating this scenario under JDK1.4.2 SR11 shows that this
  thread has NO thread context classloader - so in our 3 step
  classloading (thread context classloader, loading class's
  classloader and generic classloader) the first step is missing
  as there is no thread context classloader.
  
  Now, ordinarily, dropping back to the classloader of the loading
  class should work for applications started from the command
  line. But, in this case the Java code is actually being loaded
  by the Extension classloader, as the Java code is in
  jre/lib/ext directory.
  
  These two things means that the applications class is never
  actually loaded.
  

Problem conclusion

• Previously there were 3 steps to the attempted load of the
  class. This fix added an extra one - check the entire system
  classloader for the class we are looking for.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
                     v7.0
  Platform           Fix Pack 7.0.0.1
  --------           --------------------
  Windows            U200301
  AIX                U821414
  HP-UX (PA-RISC)    U820765
  HP-UX (Itanium)    U821296
  Solaris (SPARC)    U820766
  Solaris (x86-64)   U820880
  iSeries            tbc_p700_0_0_1
  Linux (x86)        U821407
  Linux (x86-64)     U821295
  Linux (zSeries)    U821294
  Linux (Power)      U820881
  
  The latest available maintenance can be obtained from
  'Websphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available, information on
  its planned availability can be found in 'Websphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WMQ WINDOWS V7

• Fixed component ID

  5724H7220

Applicable component levels

• R700 PSY

     UP