Fix (APAR): PK88962 Status: Fix Release: 7.0.0.7,7.0.0.5,7.0.0.3,7.0.0.1,7.0 Operating System: AIX,HP-UX,IBM i,Linux,Solaris,Windows Supersedes Fixes: CMVC Defect: PK88962 Byte size of APAR: 71929 Date: 2010-04-20 Abstract: A NoClassDefFoundError may occur during an application deployment or update operation, even for a properly packaged application. The error can cause incomplete assignment of metho Description/symptom of problem: PK88962 resolves the following problem: ERROR DESCRIPTION: When performing a partial application update, when the update is to modules having dependencies on other modules, a NoClassDefFoundError exception can occur. Generation of this exception causes a warning message to be display, for example: +++ Warning +++: Fri May 15 13:23:46 EDT 2009 java.lang.NoClassDefFoundError: com/ibm/commerce/content/facade/AttachmentFacade at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java(Compiled Code)) ... lines omitted from the stack ... at org.eclipse.jem.java.impl.JavaClassImpl.getExtendedLookupIterato r(JavaCl assImpl.java:364) at org.eclipse.jem.java.impl.JavaClassImpl.collectMethodsExtended(J avaClass Impl.java:236) at org.eclipse.jem.java.impl.JavaClassImpl.getMethodsExtended(JavaC lassImpl .java:533) at org.eclipse.jem.java.impl.JavaClassImpl.listMethodExtended(JavaC lassImpl .java:957) at com.ibm.ws.management.application.client.util.getMethods(util.ja va:309) at com.ibm.ws.management.application.client.EnsureMethodProtectionF or20EJBH elper.prepareTask(EnsureMethodProtectionFor20EJBHelper.java:98) at The key symptom is a NoClassDefFoundError and a stack showing calls through types in the package "org.eclipse.jem.java". The exception has most often arising in a call from EnsureMethodProtectionFor20EJBHelper. LOCAL FIX: None PROBLEM SUMMARY * USERS AFFECTED: All users of IBM WebSphere Application Server PROBLEM DESCRIPTION: A NoClassDefFoundError may occur during an application deployment or update operation, even for a properly packaged application. The error can cause incomplete assignment of method protections. RECOMMENDATION: When this error is seen, and if method protections are important for the application deployment, two actions are recommended: The error may be a result of an incompletely or incorrectly packaged application. The error may be the result of incorrectly specified class-path in application modules or support jars. To tell if the error is the result of either of these two cases, the application packaging should be reviewed and corrected. This case can occur during application deployment, and can occur during an application update. The error may be a result of a lack of visibility to required prerequisite classes. In particular, this error has been seen frequently when an EJB class has a super type, parameter, or exception type which is located outside of the EJB jar which contains the EJB class. The error results when an application operation, for example, a partial update operation, does not have visibility to the prerequisite classes. To tell if this is the case, review the application structure and note if any class dependencies cross jar file boundaries. The consequence of this case is most often missing or incomplete method protection assignments. For this case, to avoid the error, perform a full application update instead of a partial application update. As a work-around, following the application installation or update operation, review the deployed should be reviewed, and updates should be made to complete method protection assignments, if necessary. Corrective actions are not necessary if method protection is not important to the application deployment. Also, corrective actions are necessary in cases where default method protections are assigned The error message is displayed as a result of a failure to reflect class information for a Servlet or enterprise bean class while processing application metadata. IBM WebSphere Application Server uses the Java Eclipse Model (JEM) to reflect Servlet and Java Enterprise Java Bean (EJB) class information. For several reasons, as described in this note, reflection of the class information may fail. A failure to reflect the class information usually causes some but not all class information to be generated. Of several types of class information, including the inheritance tree, field, and method information, the most significant is method information. For enterprise beans, the incomplete listing of EJB methods can cause the incomplete assignment of protections to those methods. If method protection is not important to the application deployment, there is no important consequence. Also, if default method protections are provided, there is no important consequence: Runtime processing of the methods will assign the correct method protection. However, if method protection is important, and no default assignments are provided, the error is important. Corrective action must be taken, as described in the recommendations section. As noted above, the error message is displayed as a result of a failure to reflect class information. The reflection of class information is performed when processing application and module metadata. Reflection is performed in three cases: 1) Reflection of class information is performed during a new application deployment. 2) Reflection of class information is performed when reviewing an existing application deployment. 3) Reflection of class information is performed when making an update to an already deployed application. The failure can occur for several reasons. The most frequent and most notable case is case (2.4). This case is easy to trigger when performing a partial update operation. The reasons for the failure can be: 1) A corrupt java class file will cause a failure. 2) A missing java class file will cause a failure. 2.1) A java class file can be missing because of an error in the packaging of the application which is being processed. 2.2) A java class file can be missing because of incorrect placement of utility libraries in the application, or because of incorrectly specified class-path elements in application modules or utility jars. 2.3) A java class file can be missing because it exists in a shared library, and these are not available to be loaded during application deployment. 2.4) A java class file can be missing because a partial update is being performed to an already deployed application. For example, when a single module is updated to an application which contains other modules or utility jars. In this case, only the files for the update are available to be loaded. A dependency of the module being updated which reaches a utility jar of the application which is not present in the update will not be visible to the update operation. However, the update will still attempt to process the classes of the module, and will fail because of the failure to reach the prerequisite class. This case (2.4) occurs because of a permanent limitation of the processing of application updates. During the update processing, only the subset of the application which is being updated is available for processing. PROBLEM CONCLUSION: The information display for the error to reflect java class information has been updated to be more appropriate for all cases: Because the error may lead to a failure to assign method protections, and this is a serious error, a warning message is displayed in all cases. The warning provides a reference to this APAR PK88962. Because the error also occurs in many cases where there is no consequential problem, to minimize log output in these cases, a stack is only displayed when FINER logging is enabled for the logger "com.ibm.config.eclipse.wtp". The fix for this APAR is currently targeted for inclusion in fix packs 6.0.2.39, 6.1.0.29, and 7.0.0.9. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980 Directions to apply fix: Fix applies to Editions: Release 7.0 _X_ Application Server (Express or BASE) _X_ Network Deployment (ND) __ Edge Components __ Developer Install Fix to all WebSphere installations unless special instructions are included below. Special Instructions: None NOTE: The user must: * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V7.0.0.0 or newer of the Update Installer. Certain iFixes may require a newer version of the Update Installer and the Update Installer will inform you during the installation process if a newer version is required. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 1) If your iFix is delivered as a single file with a .pak extension, Copy the .pak file directly to the maintenance directory. If your iFix is delivered as a single file with a .zip extension, unzip the file into the maintenance directory. 2) Shutdown WebSphere Application Server. Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) For IBM i users, use the update command to install and uninstall the interim fix. The IBM Information Center can provide additional details, if needed, on the use of this command. http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-iseries&topic=rins_update. For non-IBM i users, launch the Update Installer and click the Next button on the Welcome page. 4) Enter the directory path of the installation location of the WebSphere product you want to update, and click the Next button. 5) Select the "Install maintenance package" operation and click the Next button. 6) Enter the directory path of your maintenance directory where you have the maintenance packages (.pak files) and click the Next button. 7) The Available Maintenance Package to Install page should list all maintenance packages (.pak files) that it finds in the directory path provided in the previous step. The Update Installer will select the correct maintenance packages based on your system configuration and will not allow an invalid combination to be installed. Please keep the Update Installer recommendations and click the Next button and continue with the installation of the maintenance package. To determine why some maintenance packages have been identified as not applicable, see description in log found in /logs/tmp*/updatelogs.txt 8) For all platforms except Windows. In pre-install summary panel, use the "verify permission" feature to verify the user has permissions to apply updates to files associated with the selected maintenance. Correct any file permissions before clicking next to start the install. 9) Restart WebSphere Application Server. Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Application Server. Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere Application Server. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere Application Server. Additional Information: