PK85322: SLOW DEPLOYMENT OF APPLICATIONS WITH MULTIPLE JAVA CLASSES MIGHT OCCUR ON WEBSPHERE APPLICATION SERVER VERSION 7.0
APAR status
-
Closed as documentation error.
Error description
The following problem occurs with IBM WebSphere Application Server Version 7.0: When you specify a module at a Java EE 5 level (web.xml @2.5, ejb-jar.xml @3.0), the deployment process for the module metadata requires a new step to scan the Java annotations data from classes that are packaged in the module. For a Web module, that includes both the classes that are packaged directly within the Web archive (WAR) file under the WEB-INF/classes directory and the classes that are packaged in Java archive (JAR) files within the WAR file under the configured "lib" directory. The extra processing step requires time is proportional to the number of classes to be scanned. For applications that contain a large number of classes, this scanning process can add a substantial amount of time to the deployment process. Thread dumps will show the following symptoms: ---------------------------------------------------------------- 4XESTACKTRACE at com/ibm/ws/amm/commonarchive/AnnotationsProcessorImpl.merge (AnnotationsProcessorImpl.java:108) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/WARFileImpl processAnnotations(WARFileImpl.java:297) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/WARFileImpl getDeploymentDescriptor(WARFileImpl.java:243) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/WARFileImpl getStandardDeploymentDescriptor(WARFileImpl.java:486) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/EARFileImpl getDeploymentDescriptor(EARFileImpl.java:450) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/EARFileImpl getDeploymentDescriptor(EARFileImpl.java:431) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/EARFileImpl getDeploymentDescriptor(EARFileImpl.java:470) 4XESTACKTRACE at org/eclipse/jst/j2ee/commonarchivecore/internal/impl/EARFileImpl rollUpRoles(EARFileImpl.java:1313(Compiled Code)) ----------------------------------------------------------------
Local fix
First, the solutions assume that a move to a Java EE5 level is necessary. If the module level can be kept at a pre-Java EE5 level, the extra annotations scanning will be completely avoided. Second, if a module is upgraded to a Java EE5 level, and if the module is known to have no annotations, there is a "metadata-complete" flag in the module descriptor that disables annotations processing for the module. With this option, annotation scanning is bypassed, while Java EE5 values may still be placed in the descriptor file. For an application which is being migrated but for which no annotations have been added, the use of "metadata-complete" is recommended. http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp? topic=/c om.ibm.websphere.base.doc/info/aes/ae/urun_rapp_metadata_lockdd. html <?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.5" xmlns="http://Java.sun.com/xml/ns/Javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://Java.sun.com/xml/ns/Javaee http://Java.sun.com/xml/ns/Javaee/web-app_2_5.xsd" metadata-complete="true"> <display-name>Sample_App</display-name> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> Third, if metadata-complete cannot be set, then if possible, it is advised to restructure the application to place utility jars which are known to contain no annotations information into shared libraries. These are not scanned for annotations. Fourth, move the .jars in the WEB-INF\lib up to the root of the ear.
Problem summary
**************************************************************** * USERS AFFECTED: This APAR affects customers that are * * experiencing a slow response when they * * deploy applications to IBM WebSphere * * Application Server Version 7.0. * **************************************************************** * PROBLEM DESCRIPTION: The deployment of large Java * * Platform, Enterprise Edition (Java * * EE) 5 applications to WebSphere * * Application Server Version 7.0 is slow. * **************************************************************** * RECOMMENDATION: * **************************************************************** The length of time that it takes to deploy a Java EE 5 application to WebSphere Application Server Version 7.0 depends on the number of Java classes in the application that contain annotations. WebSphere Application Server scans these annotations when an application is deployed.
Problem conclusion
The Information Center for WebSphere Application Server Version 7.0 will be augmented with information on how to decrease the amount of time that that it takes to deploy an application The "Metadata for module settings" topic will be updated to include the following information on annotations: Annotations are a standard mechanism of adding metadata to Java classes. You can use metadata to simplify development and deployment of Java EE 5 artifacts. Prior to the introduction of Java language annotations, deployment descriptors were the standard mechanism used by Java EE components. These deployment descriptors were mapped to XML format, which facilitated their persistence. If you select to lock deployment descriptors, the product merges Java EE 5 annotation-based metadata with the XML-based existing deployment descriptor metadata and persists the result. When applications contain a large number of Java classes, the deployment processing time for the annotations can increase. To minimize the performance impact, you can use one of the following methods: - Determine whether the module needs to use Java EE 5. If the module does not need to use Java EE 5, the annotations within the Java classes are not scanned. - Use the metadata-complete attribute in the module descriptor if the module uses Java EE 5 and it does not contain any annotations. This attribute disables the annotations processing for the module, but Java EE 5 modules might still be placed in the descriptor file. If you are migrating your application, but you are not adding annotations, consider using this attribute value. - Restructure the application to place the utility Java archive (JAR) files into shared libraries if those JAR files do not have annotation information. Consider this method if you cannot set the metadata-complete attribute. - Move the JAR files in the WEB-INF\lib directory to the root directory of the enterprise archive (EAR) file. Nested archives, such as a JAR file that is within a Web archive (WAR) that is within an enterprise application archive (EAR) file, are very cumbersome to search through because of the multiple levels of compression. You can find more information on the metadata-complete attribute in the "Metadata for module settings" topic in the Version 7.0 Information Center. Note: Periodically, we update the documentation in our information centers. Thus, the changes might exist in the current documentation before you read this text. To access the latest on-line documentation, go to the product library page at http://www.ibm.com/software/webservers/appserv/library and select the version and product that is appropriate for your WebSphere Application Server environment. The modified documentation will be available in the June 2009 update to the Information Centers.
댓글 없음:
댓글 쓰기