|
Problem |
This message was displayed in the browser,
indicating that a requested servlet failed to load. The "ncf" trace for
the Local Redirector Plug-in contains one of the following messages:
"Could not find required servlet class", or "<servlet_name> found,
but was corrupt" |
|
|
|
Solution |
Note:
For this document, we will use the following short forms:
.rooturi to denote:
deployedwebapp.<webapp_name>.rooturi=<root_URI_pattern>
.servletmapping to
denote:
webapp.<webapp_name>.servlet.<servlet_name>.servletmapping
.code to denote:
webapp.<webapp_name>.servlet.<servlet_name>.code |
The URL was received by the Plugin and matched against
a .rooturi=<root_URI_pattern> and .servletmapping=<URI_pattern> in was.conf. The next step would be to determine the actual
class file name and then load that class file.
This problem can be caused by an incorrect servlet
classname.
It is possible for the was.conf file to fail to code a
corresponding .code=servlet_classname statement to
match with the .servletmapping=URI_patternstatement. If that
happens, the plug-in will fail with this error message because it can't
find a name for the servlet class to be loaded. There are several reasons
why this may happen:
- You have migrated the Web application
to the Web container environment and have removed the class files from the
HFS, but you did not remove the definitions from the was.conf.
- The class file may simply not exist in
any of the directories or JAR files on the CLASSPATH.
- The CLASSPATH value may not include the
directory in which the intended class file resides.
- If the class is in a package, the
fully-qualified package name may not have been provided
correctly.
- Permissions somewhere on the
CLASSPATH directory search
are too restrictive to allow the Plugin to look for or read the
file.
- The class file was found, but was bad
because it was improperly transferred to the z/OS system (always use
binary mode when FTPing class files or JAR files), or the class file was
renamed after it had been compiled.
The error message on the browser is not explicit
enough to help determine the cause of this problem. However, the Plugin's
ncf trace is:
- Class not found condition:
Find the string "Failed to
load target servlet" in the ncf trace, then
scroll up a page or two. There you will see the following:
javax.servlet.ServletException: Servlet
Could not find required servlet class -
servlet_class_file_name
You must investigate the problem manually. That will
involve crawling through all the directories named on the CLASSPATH and
making sure the permissions are adequate (minimum: "read" on JAR and ZIP
files, and “execute” on directories) and that the class file name does
indeed exist somewhere in the directories. If the class file is in a JAR
file, then the JAR must be accessible via the CLASSPATH. Finally, if the class is
in a JAR file, and a package structure exists in the JAR, then the
fully-qualified name of the package must be provided on was.conf
file's.code= statement.
- Class found, but corrupt
condition:
Find the string "Failed to
load target servlet" in the ncf trace, then look
just beyond that string. You will find the following message:
javax.servlet.ServletException: Servlet [name]:
name was found, but is
corrupt:
It lists five things to check, including that the file
wasn't renamed after being compiled, and that the file had been
transferred using binary transfer mode.
The ncf trace does not get more specific than that. It
relies on you to manually investigate the cause of the problem based on
the hints it gives. Determine if the problem is "class not found" versus
"class found but corrupt" condition. Then determine the cause of the
problem. Then fix the problem (name directory on CLASSPATH, put class in
CLASSPATH, change permissions, etc.)
Related information
WP10295 in
www.ibm.com/support/techdocs |
|
|
|
|
|
|
|