Troubleshooting
Problem
When starting an IBM Application Server Liberty Profile (all versions), application discovery attempts to resolve manifest class attributes of the application. That resolution is necessary for the application to locate resources during normal operations. Both class loading and static resource retrieval use the resolved manifest class path. When a manifest class path fails to resolve, the warning message "SRVE9967W" is displayed, once for each manifest class path element which did not resolve. The warning message may indicate a serious problem which should be corrected. The warning message may indicate a harmless problem which may be corrected, but which also may be ignored. When the warning occurs, diagnostic steps should be taken to determine if the problem is severe or is harmless. If the problem is severe, correct steps must almost always be taken. If the problem is harmless, corrective steps may be taken (to prevent the message from being displayed), or, the problem may be ignored. Most often, the warning indicates a problem of an application which is being processed. Less often, the warning indicates a code problem of the application server. The warning message "SRVE9967W" is specific to the IBM Application Server Liberty Profile. However, the underlying problem -- the failure to resolve a manifest class -- also occurs for other IBM Application Server profiles. The discussion relating to the underlying problem is applicable to all IBM Application Server profiles.
Symptom
The primary symptom is the display of the warning message "SRVE9967W", possibly several times, once for each manifest class path element which fails to resolve. The message displays the manifest class path element which failed to resolve and displays the name of archive which contains the unresolved manifest class path element.
The message is displayed during application discovery, typically, during server startup. Application discovery also occurs when an application is added as a drop-in application, or when processing is done to react to updates made to an already discovered application (when files are added or removed from the application's file set).
The warning message does not prevent the application from being run. However, at a later time, secondary symptoms may appear. Most frequently, the application will fail with a ClassNotFoundException. Less frequently, the application may fail to service a request because static content cannot be located. A failure to locate static content often results in a failure of application function.
Secondary symptoms also include less immediately visible but still severe problems: If the application contains more than one copy of a resource, with the precendence between the copies decided by the ordering of manifest class path elements, the failure to resolve one element of a manifest class path may result in the wrong copy of a resource from being used. Use of the wrong copy of a resource often results in a failure of application function.
The appearance of secondary symptoms usually indicates that the problem is severe. Almost always, the application should be updated to correct the problem.
The application may run showing no secondary symptoms. That may indicate that the manifest class path element is not necessary to the application, meaning, the warning is harmless and may be ignored. However, the absence of secondary symptoms might instead indicate that the function which requires the unresolved manifest class path element has not yet been exercised, in which case the problem would be severe and should be corrected.
As an example of a severe problem, enterprise application "MyApp" with web module "MyWeb" specifies a manifest class path with three elements, "MyUtil1.jar", "MyUtil2.jar", and "MyUtil33.jar". The enterprise application "MyApp" contains the three utility JARS "MyUtil1.jar", "MyUtil2.jar", and "MyUtil3.jar". In this example, the manifest class path element "MyUtill33.jar" does not match the actual JAR file "MyUtil3.jar":
MyApp.ear\
MyWeb.war\
META-INF\MANIFEST.MF
Class-Path: MyUtil1.jar, MyUtil2.jar, MyUtil33.jar
MyUtil1.jar
MyUtil2.jar
MyUtil3.jar
When discovering "MyApp", because of the mismatch, a "SRVE9967W" warning is displayed:
SRVE9967W: The manifest class path MyUtil33.jar can not be found in jar file MyWeb.war or its parent.
Note: Depending on the version of the IBM WebSphere Application Server Liberty Profile, the following message may instead be displayed:
SRVE9967W: The manifest class path element MyUtil33, of archive MyWeb.war, could not be resolved.
Later, during application processing, class references from MyWeb.war to MyUtil3.jar will fail to resolve, leading to a ClassNotFoundException.
For this example, either the manifest class path element "MyUtil33.jar" should be changed to "MyUtil33.jar", or the JAR file "MyUtil3.jar" should renamed to "MyUtil33.jar".
As an example of a harmless problem problem, enterprise application "MyApp" with web module "MyWeb" specifies a manifest class path with four elements, "MyUtil1.jar", "MyUtil2.jar", "MyUtil3.jar", and "ExtraUtils.jar". The enterprise application "MyApp" only contains three utility JARS: "MyUtil1.jar", "MyUtil2.jar", and "MyUtil3.jar", with "ExtraUtils.jar" having at one time been present, but since that time having been merged into "MyUtil3.jar":
MyApp.ear\
MyWeb.war\
META-INF\MANIFEST.MF
Class-Path: MyUtil1.jar, MyUtil2.jar, MyUtil3.jar, ExtraUtils.jar
MyUtil1.jar
MyUtil2.jar
MyUtil3.jar
When processing "MyApp", because of the "ExtraUtils.jar" element fails to resolve, a "SRVE9967W" warning is be displayed:
SRVE9967W: The manifest class path ExtraUtils.jar can not be found in jar file MyWeb.war or its parent.
In this example, all of the classes previously present in "ExtraUtils.jar" are present in "MyUtil3.jar". No ClassNotFoundExceptions will occur in relation to the warning. As a corrective step, The "ExtraUtils.jar" element is obsolete and should be removed. Or, the manifest could be left as-is and the message can be ignored.
Cause
The problem is caused by a mismatch between a manifest class path and the actual contents of the enclosing application. More specifically, either, a manifest class path element is incorrect, or, a referenced resource is missing or in an incorrect location. A manifest class path element may be incorrect because of a syntax error in the manifest file, most often causing the manifest class path to be truncated.
See the following for a discussion of manifest class path attributes. Of particular note: Manifest class paths are processed only for application library JAR files, application utility JAR files, and module files (EJBJAR, WAR, RAR, CLIENT JAR), while manifest class paths of enterprise application files (EAR), and JAR files within web module and connector files (WAR, RAR) are not processed; Manifest class paths of application utility JAR files are processed if they are reached by a class path of a module file; Manifest class path element resolution is relative to the logical structure of the enclosing archive, regardless of where the archive is placed on disk; resolution is relative to the relative placement of the archive the immediately enclosing archive.
Harmless cases of the problem occur typically in two scenarios: First, a third party utility JAR is included in an application, with the JAR specifying a manifest class path with elements which are unused by the application. Second, as above, with a manifest class path entry made obsolete by adjustments made to the packaging structure of an application.
Background:
Java archive include JAR files, which can be EJBJAR files, Application Client JAR files, Web Fragment JAR files, and simple utility JAR files. Java archive file types also include Web module archives (WAR files), Connector archives (RAR files), and Enterprise Business archives (EBA files). Enterprise Application archives (EAR files) are also a type of java archive files.
Java archives should always contain a manifest file at path "META-INF/MANIFEST.MF". (The java specification requires that a manifest be present, however, almost all tooling tolerates the absence of a manifest.
A manifest contains a collection of main attributes, and collections of attributes for entries of the enclosing archive. A manifest is a UTF-8 encoded document. See various documentation for the full manifest specification, for example:
http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html
A manifest may specify a class path using a "Class-Path" main attribute. Per the linked documentation:
"Class-Path: The value of this attribute specifies the relative URLs of the extensions or libraries that this application or extension needs. URLs are separated by one or more spaces. The application or extension class loader uses the value of this attribute to construct its internal search path."
Manifest class path values for java archives which are used in a JavaEE packaging unit (for example, an EAR, WAR, EJBJAR, or RAR file) have a specific meaning according to the JavaEE specifications:
A manifest class path of an EAR file is not used in the JavaEE specification.
A manifest class path of a module archive (EJBJAR, WAR, RAR, or application client JAR file) is used to set the class path of the module archive, with manifest class path elements resolved relative to the location of the module archive. Resolution is relative to the logical structure of the enclosing module archive, regardless of how the module archive is placed on disk. Resolution is relative to the placement of the module archive within the application archive. This is significant because module archives, while usually placed at the root level, may also be placed in subdirectories relative to the enclosing enterprise application archive.
A manifest class path of a JAR file which is a library JAR file (has a path under WEB-INF/lib) of a web module archive file (WAR file) is not used in the JavaEE specification. This is the case whether or not the library JAR file is interpreted as a simple utility JAR file or is interpreted as a fragment archive. Similarly, a manifest class path of a JAR file which is in resource connector archive (RAR file) is not used in the JavaEE specification.
A manifest class path of a JAR file in the application library folder (usually "lib", but configurable to a different value) *is* resolved. A manifest class path of a JAR file which is reached as utility JAR when resolving another manifest class path *is also* resolved.
Environment
All environments which use the IBM WebSphere Liberty Profile can encounter this problem.
Diagnosing The Problem
To diagnose the problem, verify the warning message details against the actual content of the application. Also, note if secondary symptoms occur.
If secondary symptoms occur and are related to the warning message, the problem is severe and corrective steps are almost always necessary. If secondary symptoms do not occur, the problem might be severe, but might also be harmless.
Examination of manifest class path values requires one or more steps of unpackaging (expanding) the enterprise application archive. For example, to examine the manifest class path of a web module archive (WAR file), first the top level enterprise application archive (EAR file) is unpacked. Second, the manifest file (META-INF/MANIFEST.MF) of the web module archive is extracted from the WAR file. The manifest file has the class-path attribute displayed as plain text, for example:
Class-Path: MyUtil1.jar, MyUtil2.jar, MyUtil3.jar, ExtraUtils.jar
When examining a manifest class path, look both for mismatches between the manifest class path elements and the application contents, and for errors in the text of the class path. Manifest class path values are frequently placed incorrectly in the manifest file, with the most usual result being a truncation of the manifest class path value.
Examination of the application contents requires unpackaging of the enterprise application archive (EAR file). As manifest class path elements are only processed on archives which are children of the top level enterprise application, only the top level enterprise application archive needs to be unpackaged.
When matching manifest class path elements against the application contents, make sure to adjust for the relative location of the archive enclosing the manifest in question. Usually, the problem is for a manifest of a module archive, and, usually, module archives are placed immediately beneath the top level enterprise application archive. However, module archives may be placed in subdirectories relative to the top level enterprise application archive, and an adjustment will be necessary.
For example, enterprise application "MyApp" places web module "MyWeb" in directory "MyWars". The enterprise application contains two copies of utility jar "MyUtil.jar", one copy at the root level, and one copy in the "MyWars" directory. The web module "MyWeb" contains a manifest class path which references the utility jar file "MyUtil.jar":
MyApp.ear\
MyUtil.jar
MyWars\MyWeb.war\
META-INF\MANIFEST.MF
Class-Path: MyUtil.jar
MyWars\MyUtil.jar
Resolution of the manifest class path element "MyUtil.jar" resolves to the copy in the "MyWars" directory. If the application were packaged with a copy of "MyUtil.jar" only at the root level of "MyApp.ear", the "MyUtil.jar" class path element would fail to resolve and the warning would be displayed.
Resolving The Problem
In certain cases, the warning message may be ignored. In other cases, the application must be updated to correct the problem. Either, the manifest class path element must be updated, or, the application packaging structure must be updated.
The specific corrective action depends on why the class path element cannot be resolved. These are the most common reasons:
1) There is a mistake in the text of a manifest class path element (possibly because the element value is incorrect, but also possibly because of a syntax error in the manifest text).
2) The target resource is not available in the enclosing application.
3) There is a mistake in the name of the target resource as packaged within the enclosing application.
4) The target resource is present at a different location than is referenced by the manifest class path element.
For these typical scenarios, these actions are recommended:
1) Adjust the manifest class path, either to correct a mistake in the text of a manifest class path element, or to adjust the manifest class path element to use to the actual location of the target resource. Correct any syntax errors in the manifest text.
2) Add the target resource with the correct name and location to the enclosing application.
3) Adjust the target resource, either to correct a mistake in the name of the resource, or to move the resource to the correct location.
Updates to a manifest must maintain the manifest with correct syntax, and is possible with a variety of tools. For standard steps to update a manifest file using the java "jar" command, see:
http://docs.oracle.com/javase/tutorial/deployment/jar/modman.html
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21681388