Internet
Explorer 5.x by default substitutes its own error page when a 500
level
(internal
servlet) error occurs. You can turn off this feature by selecting the
Tools | Internet Options menu item, and then selecting the Advanced
tab. A check box entitled “Show friendly HTTP error messages”
should be deselected to see full stack traces and any other data sent
by a servlet exception.
Sometimes,
the changes done in a JSP page just not get reflected and the output
continues to remain the same. This could happen due to several
reasons whose solution can be one of the following:
Delete
old copies of translated JSP servlets and classes.
The
JSP pages are translated into servlets and then re-compiled only
when the JSP page is newer than the servlet/class. Changes in
included JSP files are detected only by some JSP engines and may
not get reflected unless older ones are deleted.
Delete
serialized sessions.
An
older version of the class may be getting deserialized. Delete
older sessions present in /WEB-INF/sessions to handle this.
Restart
the Web server and servlet engine.
Does
all initializations.
Changes
in web.xml are reflected well only by doing a re-start of Web
Server.
Debugging
tools
like JDB are not of much help in debugging JSP because they operate
on generated servlet code which is a little complicated mixture of
Java, Scripts, Tags and HTML.
Capturing
Form Parameters
: It is good to make a function/JSP-page which will print all the
parameters for combos/text-fields/check-boxes before processing.
This usually helps a lot to fix the error.
Browser
Replacement
: The web browser can easily be replaced by a stand-alone console
program which just opens a socket and sends some requests. This
helps to eliminate the complexity of the browser and simplifies the
stand-alone testing of simple requests to the JSP page.
Web-Server
Logs
: Web-Servers have logs printed for much of the communication and
other actions. This can also be helpful at times. Also, servlets/JSP
can also write to this log object to aid the debugging.
Tracer
: A tracer can be put between client and server which acts both as a
proxy-server and a proxy-client i.e. it acts as a server for the
client and acts as a client for the server. It passes requests from
client to server and responses from server to client but dumps all
this to a log file too. This can considerably help in nailing down
the source of the problem.
Got a thought to share or found a bug in the code? We'd love to hear from you: