IBM®
Skip to main content
    United States change      Terms of use
 
 
Select a scope:    
     Home      Products      Services & industry solutions      Support & downloads      My account     
alphaWorks  >  Java technology  >  

Class Finder Toolkit for Websphere Application Server

Two command line tools for determining all the run-time JARs, zip files, and directories for a given class inside WebSphere Application Server.


Date Posted: May 6, 2004
OverviewRequirements Download FAQs Forum Reviews

Update: June 22, 2004

On Windows, wswhich can handle WAS installation folder with the space in it. Also, wswhich will save search history in .wswhich_history.

What is Class Finder Toolkit for WebSphere Application Server (WAS)?

Class Finder Toolkit for WAS consists of two command line tools for determining all the run-time JARs, zip files, and directories for a given class inside WAS.

These two utilities are as follows:

  • dcl (dump classpaths) dumps run-time classpaths in XML for a given J2EE module, such as petstore.war. Working on top of JMX SOAP connector, it can work with a local WAS node or a remote one, with WAS Base version or ND version, and with WAS security on or off.
  • wswhich can take an XML-produced from dcl and examine all the classpaths defined in the XML, including JARs, zip files, and directories for a given class. In addition, wswhich can be also used to locate a class among WAS's system-level classpaths, which belong to JRE and WAS extension classloader, even when WAS is not running.

How does it work?

This toolkit helps users to quickly resolve ClassDefNotFound and VerfiyError or any other classloader-related problems that occured at run time. For example, if one has packaged a different (usually newer) version of XML parser (Xerces) than the one used by WAS 5, one might run into VerfiyError, depending on where and how one deploys the newer XML parser. Solving this kind of classpath problem in the WAS run time is tricky without any tools. Class Finder Toolkit for WAS can examine all the classpaths at run time for the problematic module and show which one contains the conflicting class. Then, with an understanding of how WAS classloaders works, one can usually solve the problem more quickly.

About the technology author(s):
Victor Yang works for IBM Toronto Lab as a contractor. He graduated with an MSCS degree from Georgia Tech in 1994. Since then, he has worked for numerous companies including IBM, Sun Microsystems, SunLife, CIBC, S1, and AT&T. Mr. Yang is a Sun-certified programmer and Web component developer. He is also active in writing for IBM DeveloperWorks articles. Mr. Yang can be reached here.

Download now Download now

Related technologies

For platform(s):
Windows, Java, UNIX

For topics:
MBean, Websphere Application Server


Related resources

WebSphere Application Server zone

developerWorks Java technology zone

IBM Systems Journal

 

    About IBM Privacy Contact