Reducing annotation searches during application deployment
Enterprise applications that contain many classes and are
enabled for annotations processing (are not marked as metadata-complete
)
take extra time to deploy. Extra time is necessary to scan application
binaries for annotations that were introduced by Java™ EE 5. If there are no additional options
to limit which classes are scanned, when scanning is enabled for a
module all classes in the module must be scanned. A scan of all classes
is necessary even when only a small subset of classes within a given
module has annotations.
Before you begin
Fast bytecode scanning technology is used to improve deployment performance. However, better deployment performance is achieved by limiting which classes are scanned for annotations.
When a module is marked as metadata-complete, it applies to an entire module. Marking the module as metadata-complete cannot be done when annotation processing is necessary. Additionally, marking the module as metadata-complete prevents the scanning of a module, which causes problems for web modules that use EJB or web service annotations.
JAR files of web module archives (WAR files) might be moved to the application library folder. However, moving the WAR files might not be possible since doing so can break web module encapsulation, or because multiple modules that require different JAR files are present.
To overcome these limitations, and to reduce deployment time, IBM® WebSphere® Application Server provides options for limiting which classes are scanned for annotations.
Install an application that supports Java Platform, Enterprise Edition (Java EE) 5 or later on a product server. If deployment is unreasonably slow and you plan to deploy the application again in the future, and if the application contains modules that are enabled for annotation processing, complete a procedure in this topic to reduce the number of classes that are scanned for annotations.
About this task
The product provides a configurable filtering function to reduce the number of classes that are searched for annotations. You can identify which modules or Java packages to ignore for annotations processing through four properties: (or manifest attributes):
- Ignore-Scanning-Archives
- Ignore-Scanning-Packages
- Include-Scanning-Archives
- Include-Scanning-Packages
The properties can be specified either in amm.filter.properties in app_server_root/properties, or can be specified as manifest attributes.
- com.ibm.ws.amm.scan.context.filter.archives
- com.ibm.ws.amm.scan.context.filter.packages
- com.ibm.ws.amm.scan.context.include.archives
- com.ibm.ws.amm.scan.context.include.packages
Use these options to limit which classes are scanned for annotations. Performance is improved proportionally to the number of classes that are removed. Remove from processing any classes that contain no annotations data.
Usually, filtering is done on whole archives. A frequent filtering case is to filter utility JAR files included in a WAR that contains no annotations data.)
The
Ignore-Scanning-Archives and Ignore-Scanning-Packages properties are
used to specify the subsets of classes to be ignored during annotation
processing. All classes in archives that are specified by Ignore-Scanning-Archives
are
skipped during annotation processing. All classes in packages that
are specified by Ignore-Scanning-Packages are also skipped during
annotation processing.
The Include-Scanning-Archives and Include-Scanning-Packages properties are used to specify the subsets of classes to be scanned during annotation processing. When either property is specified, only those classes that are included are scanned; any other classes are ignored.
The property values provide both coarse and fine-grained control over the scope for annotations processing, with Ignore-Scanning-Archives providing coarser control than Ignore-Scanning-Packages, and similarly Include-Scanning-Archives providing coarser control than Include-Scanning-Packages.
The syntax for all four properties follows the comma-separated value convention. No wildcard or regular expressions are permitted and values are case-sensitive.
The use of both the include and exclude properties at the same time is unusual, but it is supported. When an include property is specified with an exclude property, classes are selected for processing when they are included and not excluded. If both Ignore-Scanning-Archives and Include-Scanning-Archives are specified, a class is scanned during annotation processing, but only if the class is within an archive that is specified by Include-Scanning-Archives, and not within an archive that is specified by Ignore-Scanning-Archives. Similarly, if both Ignore-Scanning-Archives and Include-Scanning-Packages are specified, a class is scanned during annotation processing, but only if the class is within a package that is specified by Include-Scanning-Packages and not within an archive that is specified by Ignore-Scanning-Packages.
Options that are specified using the amm.filter.properties file are global to the profile. All applications that are encountered by processes that are launched by that profile use the specified options. Options that are specified as system properties are global to the process on which the properties are set. All applications that are encountered by the process use the specified options.
- Application (EAR file)
- Module (WAR/RAR/JAR file)
- Web fragment (JAR file)
Manifest attributes that are specified at multiple scopes are additive. Options that are specified by using amm.filter.properties, system properties, and manifest attributes are additive.
The default set of values can be changed by an administrator or augmented by using one of the following steps.
Procedure
What to do next
Install the application again. If deployment continues to be slow, specify more modules and Java packages to ignore.