IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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 number

    IC57518

  • Reported component name

    WMQ WINDOWS V7

  • Reported component ID

    5724H7220

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-08-06

  • Closed date

    2008-10-02

  • Last modified date

    2009-03-10

  • 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

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCPQ63","label":"APAR \/ Maintenance"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
10 March 2009