HTTP 404 Troubleshooting.

Troubleshooting:

Verify that the Web server is responding

Verify that the application server is started

Verify that the application is started

Collect data

If the type of error is not apparent to you or you did not obtain the URL

information, collect the following diagnostic data:

Errors displayed by the user browser, including the URL that failed.

SystemOut log data for the application server

If your application is deployed to a cluster, you might need to collect the logs

from each active server in the cluster

Web server access and error logs

If you are running an IBM HTTP Server, see “IBM HTTP Server, HTTP Server

(powered by Apache) log files

_

Analyze data:

The two key determinations that you can make from the diagnostic data are:

The URL that failed.

Where the failure occurred (Web server, plug-in, application server)

Analyze the diagnostics in the following order:

The browser error display

1.     The page cannot be displayed

2.     JSP error or JSF error

3.     Failed to find resource

4.     File not found

5.     WebGroup/virtual host not defined

The errors displayed by the browser can indicate the failure type and URL that

failed. This might be enough information to resolve the problem.

.SystemOut  Errors

To analyze SystemOut, search for:

1.Web container messages: SRVExxxxE or SRVExxxxW messages

2.JSP messages: JSPGxxxxE or JSPGxxxxW messages

3.JSF messages: JSFGxxxxE or JSFGxxxxW messages

4. Error messages that are related to the application startup

If the failure occurs in the Web container, SystemOut has the most informative

error messages. These might be displayed by the browser also, depending on

the error handling of the application. If no error messages are seen in the

JVM logs, the request most likely did not reach the application server

Web server log

Search for 404 status codes in the access log

A log entry in the NCSA format looks like this:

Remote_host- - date_time "request" status_code bytes

For 404 errors:

1. Search for “404” in status_code.

2 Note the remote_host address, the date_time stamp, and the request URL.

Search for errors in the error log

An error entry in the error log resembles this example:

[date_time] [error] [client Remote_host] error_message

For errors in this entry:

. Search for “error.”

. Correlate the access log entry that you noted with the error log entry by

comparing the date_time and remote_host entries.

3. Note the error_message text

If no other error indications are found, look at the Web server log, which can

tell you the type of error (404 or 500) and the URL that caused the


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The Flow of Request happens from

Load Balancer >> Webserver >> Appserver >> DB

so the investigation for such issues should also follow the same routes .. ( well thats how i follow )

1) Try to check if the url is responding frm your end. ( this will eliminate if its specific to a user or its error for every one)

2) Check the Webserver if its running or not , If its not running start it

3) Check if the application server and application is running .. if not start it

4) Try to access the Aplication directly from the Appserver .. ie using the http transport port. ie wc_defalut .. ( this will identify if the error is due to App server or is with the Webserver/plugin)

5) check for the errors in the Appserver and web server logs

6) Check for the config in the plugin file to ensure that the url which is being hit is avaliable in the plugin-xml.cfg ( If it is not then it could be possible that the plugin was not regeneraed ad propagated after the deployment)

7) Enable the trace in the plugin-xml.cfg to understand in the plugin logs whether the plugin is forwarding the req to the appservers or not .

8) Lastly also check if the page which you are requesting is avaliable within the web modules

If you see one of the following messages, you
might have a problem with the virtual host
configuration: SRVE0255E: A WebGroup/Virtual Host to handle
url has not been defined. (V6.1) SRVE0017W: A WebGroup/Virtual Host to handle
url has not been defined. (V6.0) Error messages with prefixes JSPG, JSFG, or
SRVE have information about the error, including
the URL that caused the problem  

HTTP 404 Errors

HTTP 404 errors can have different underlying causes. Some examples of these

causes are:

External factors, such as a problem in the Web server

Configuration problems, such as an incorrect Web server plug-in or virtual

host configuration

Runtime problems, such as an application or application server not started

User or application problems, such as an incorrectly specified URL

ClassNotFoundExcptions

Class Not Found Exception and Class Loader

A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class. Given the name of a class, a class loader should attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a class file of that name from a file system. When a class loading request is presented to a class loader, it first asks its parent class loader to fulfill the request. The parent class loader, in turn, asks its parent for the class until the request reaches the top of the hierarchy. If the class loader at the top of the hierarchy cannot fulfill the request to load a class, then the child class loader that called it is responsible for loading the class. If the child is also unable to load the class, the request continues back down the hierarchy until a class loader fulfils it or aClassNotFoundException is produced by the last class loader. Each class loader is a child of the previous class loader. That is, the application module class loaders are children of the WebSphere extensions class loader, which is a child of the CLASSPATH Java class loader. Design and packaging of an application will determine the behavior of class loading. WebSphere provides the ability to change/modify the class loading behavior. WebSphere Class Loaders: WebSphere application server has 3 class loaders. Application server class loader The application server class loader policy affects all applications that are deployed on the server. Enterprise application class loader An application class loader is the parent class of an Enterprise application (EAR) and all modules within it. An application class loader groups enterprise bean (EJB) modules, shared libraries, and dependency Java archive (JAR) files associated to an application. Dependency JAR files are JAR files that contain code which can be used by both enterprise beans and servlets. Web module class loader A web module has its own Web application archive (WAR) class loader to load the contents of the web module, which are in the WEB-INF/classes and WEB-INF/lib directories. 1. Application server class loader Go to Servers –> Application Servers –> Server name Look for the above options. Classloader Policy Single: Applications are not isolated from each other. Uses a single application class loader to load all of the EJB modules, shared libraries, and JAR files which are contained in all applications installed into the JVM.Multiple: Applications are isolated from each other. Gives each application its own class loader to load the EJB modules, shared libraries, and JAR files. Class loading mode parent first: Sets the loading of classes to its parent class loader before attempting to load the class from its local class path. This is the default value for Class loading mode parent last: Tells the class loader to start with loading classes from its local class path before asking its parent. For each application server in the system, you can set the application class-loader policy to Single orMultiple. When the application class-loader policy is set to Single, then a single application class loader loads all EJB modules, dependency JAR files, and shared libraries in the system. When the application class-loader policy is set to Multiple, then each application receives its own class loader that is used for loading the EJB modules, dependency JAR files, and shared libraries for that application. Note: If you’ve multiple application running on the same server (JVM) and if their classes are conflicting each other or Also some times it can happen that, application classes may conflict with the WebSphere classes. then we change the class loading mode option from default. 2. Application Class Loader In general Enterprise applications (EAR) will have multiple web, ejbs or sometimes may include application client modules. Enterprise applications can also override settings within the contained modules deployment descriptors to combine or deploy them. By placing JAR files in the enterprise application instead of the global class path of an application server, they are also within the application and thus they get deployed along with the application. The concept is that an EAR file encapsulates all its required resources and hence it can be pre-configured using some java techniques. Go to Applications –> Enterprise applications –> Application name –> Class loading and updation you can see the above options Class loader order Classes loaded with parent class loader firstSets the loading of classes to its parent class loader before attempting to load the class from its local class path.Classes loaded with application class loader first Tells the class loader to start with loading classes from its local class path before asking its parent WAR class loader policy Class loader for each WAR file in application A separate class loader is assigned to each WAR file.Single class loader for applicationOne class loader is assigned to all WAR files. An application class loader loads classes from Web modules if the application’s WAR class-loader policy is set to Application. If the application’s WAR class-loader policy is set to Module, then each WAR module receives its own class loader. 3. Web module class loader Every web module will have 2 folders, WEB-INF/classes and WEB-INF/lib. The classes folder may contain Java classes within the web application. Then we can specify a class loader to looks at this folder to load those classes.  Remember these classes are only for that specific web module. Class loader order Specifies whether the class loader searches in the parent class loader or in the application class loader first to load a class. The standard for development kit class loaders and product class loaders is Classes loaded with parent class loader first. By specifying Classes loaded with application class loader first, your application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException or LinkageErrors if you have mixed use of overridden classes and non-overridden classes. Classes loaded with parent class loader firstIf set, the class loader searches the application’s class loader for the class.Classes loaded with application class loader firstIf set, the class loader searches within the WAR class loader first to load a class. Class-loader isolation The number and function of the application module class loaders depend on the class-loader policies that are specified in the server configuration. Class loaders provide multiple options for isolating applications and modules to enable different application packaging schemes to run on an application server Class loader isolation combinations Type of Isolation Application server Class loader WAR class loader Full Multiple WAR Partial Multiple Application Minimum Single Application you might be wondering, where is the 4th option (Application server class loader – Single + WAR class loader WAR). Once you set the application class loader to Single, there is only one class loader for entire server. That’s why this option was not mentioned  Tip: check the below link to learn about these policies with an example http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/crun_classload.html

Updating applications,Modules,files.

This topic describes how to update deployed applications or modules using the administrative console.

Updating consists of adding a new file or module to an installed application, or replacing or removing an installed application, file or module. After replacement of a full application, the old application is uninstalled. After replacement of a module, file or partial application, the old installed module, file or partial application is removed from the installed application.

Steps for this task

1. Update your application or modules and reassemble them using an assembly tool.

Typical tasks include adding or editing assembly properties, adding or importing modules into an application, and adding enterprise beans, Web components, and files.

2. Back up the installed application.
1. Go to the Enterprise Applications page of the administrative console. Click Applications > Enterprise Applications in the console navigation tree.
2. Export the application to an EAR file. Select the application you want uninstalled and click Export. Exporting the application preserves the binding information.
3. With the application selected on the Enterprise Applications page, click Update. The Preparing for application update page is displayed.
4. Under Specify the EAR, WAR or JAR module to upload and install:
1. Ensure that Application name refers to the application to be updated.
2. Under Update options, select the installed application, module, or file that you want to update. The online help Preparing for application update settings provides detailed information on the options. Briefly, the options are as follows:

Full application

Replaces the installed (old) application with the updated (new) application on the server

For

Full application, specify the path for the new .ear file. The path provides the location of the new .ear file before installation.

Single module

Adds a new module to, or replaces a module in, the installed application. Specify the path for the new Web module (.war), EJB module (.jar), or resource adapter module (.rar). The path provides the location of the new module before installation.

To replace a module, the value for Relative path to module (or module URI) must match the path of the module to be updated in the installed application.

To add a new module to the installed application, the value for Relative path to module must not match the path of a module in the installed application. The value specifies the desired path for the new module.

If you are installing a standalone Web module, specify a value for Context root.

Single file

Adds a new file to, or replaces a file in, the installed application. Specify the path for the new file. The path provides the location of the new file before installation.

To replace a file, the value for Relative path to file must match the path of the file to be updated in the installed application.

To add a new file to the installed application, the value for Relative path to file must not match the path of a file in the installed application. The value specifies the desired path for the new file.

The relative path to a file from the root of the application is the concatenation of the module path and the file path within the module.

For example, if the file is com/mycompany/abc.class within the module foo.jar, then the relative file path is foo.jar/com/mycompany/abc.class.

Partial application

Updates multiple files of an installed application by uploading a compressed file. Depending on the contents of the compressed file, a single use of this option can replace files in, add new files to, and delete files from the installed application. Each entry in the compressed file is treated as a single file and the path of the file from the root of the compressed file is treated as the relative path of the file in the installed application.

Specify a valid compressed file format such as .zip or .gzip. The path provides the location of the compressed file before installation. This option unzips the compressed file into the installed application directory.

To replace a file, a file in the compressed file must have the same relative path as the file to be updated in the installed application.

To add a new file to the installed application, a file in the compressed file must have a different relative path than the files in the installed application.

To remove a file from the installed application, specify metadata in the compressed file using a file named META-INF/ibm-partialapp-delete.props at any archive scope. The ibm-partialapp-delete.props file must be an ASCII file that lists files to be deleted in that archive with one entry for each line. The entry can contain a string pattern such as a regular expression that identifies multiple files. The file paths for the files to be deleted must be relative to the archive path that has the META-INF/ibm-partialapp-delete.props file. Refer to Preparing for application update settings for more information.

5. After you select an option, specify a path. Use Local file system if the browser and application files are on the same machine (whether or not the server is on that machine, too). Use Remote file system if the application file resides on any node in the current cell context. Only .ear, .jar, or .war files are shown during the browsing.
6. You can browse the entire file system of a node if the node agent or deployment manager is running on that selected node.
7. During application updating, application files typically are uploaded from a client machine running the browser to the server machine running the administrative console, where they are deployed. In such cases, use the Web browser running the administrative console to select EAR, WAR, or JAR modules to upload to the server machine.
8. In some cases, however, the application files reside on the file system of any of the nodes in a cell. To have the application server install these files, use the Remote file system option.
9. Also use the Remote file system option to specify an application file already residing on the machine running the application server. For example, the field value on a Windows machine might be C:\WebSphere\AppServer\installableApps\test.ear. If you are installing a standalone Web module, then specify the context root as well.
10. After the application file is transferred, the Remote file system value shows the path of the temporary location on the deployment manager or server machine.
11. If you selected the Full application or Single module option:
1. Click Next to display a wizard for updating application files.
2. Complete the steps in the update wizard.

This update wizard, which is similar to the installation wizard, provides fields for specifying or editing application binding information. Refer to information on installing applications and on the settings page for application installation for guidance.

Note that the installation steps have the merged binding information from the new version and the old version. If the new version has bindings for application artifacts such as EJB JNDI names, EJB references or resource references, then those bindings will be part of the merged binding information. If new bindings are not present, then bindings are taken from the installed (old) version. If bindings are not present in the old version and if the default binding generation option is enabled, then the default bindings will be part of the merged binding information. You can select whether to ignore bindings in the old version or ones in the new version.

12. Click Finish.
13. If you did not use the Map modules to servers page of the update wizard, after updating the application, map the installed application or module to serversor clusters.

Use the Map modules to servers page accessed from the Enterprise Applications page.

1. Go to the Map modules to servers page. Click Applications > Enterprise Applications > application_name > Map modules to servers.
2. Specify the application server where you want to install modules contained in your application and click OK. You can deploy J2EE 1.4 modules to servers on Version 6.x nodesor to clusters that contain cluster members on Version 6.x nodes only.

What to do next

If a changed application or module is deployed on a cluster, roll out the changes to all cluster members of the cluster on which the application or module is deployed. Click Rollout Update on the Enterprise Applications page to propagate the changed configuration on all cluster members of the cluster on which the application or module is deployed. Rollout Update sequentially updates the configuration on the nodes that contain cluster members.