How can I debug a JSP exception

You've posted the exception, which gives the line number in the JSP Java code.  Look at the generated Java code at that line number and that should give you a good idea of what is failing.

In my experience, doEndTag errors are caused by incorrect tag specification in the JSP code.  Attributes could be wrong, a tag could be missing the end tag, that sort of thing.  Debugging tags is a pain, but looking at the line in the generated Java code is the start.

"Look at the generated Java code at that line number and that should give you a good idea of what is failing."

The name of the .jsp file is aib-layout.jsp i can only find a .class file for this jsp i can't find the .java file. If I decompile this class file do i get the .java file? I have attached the file for you to look at.
Also when you say that the line number should good you a good idea of what is failing, what line number? is it line 1661?
_csX1681919883aib_5F_layout.java:1661?


layout.txt

The generated Java code is in a special directory.  If you search under your servlet engine's work directory for any file named _csX1681919883aib_5F_layout.java you will find it.  In Tomcat 5, the file would be here:
$tomcat_home\work\Catalina\www.mydomain.com\_\org\apache\jsp\
(forward slashes if you're working in Unix).

The servlet engine needs to put the generated .java file somewhere, and compile it from there.  Runtime exceptions come from the java source code, so the error message gives you the line number from that source file.

I'm using websphere 5-1 as my appserver. I ran the following search and found nothing...
find . -name "*.java" > /data/WebSphere/jspfile.txt
I ran this from the root directory on  our unix server. I have attached the file for you to look at but there is no mention of our compiled java files.
I ran:
find . -name "*.class" > /data/WebSphere/classfile.txt
and this did output the compiled jsp files as .class files. and gave the according directories.
classfile.txt
jspfile.txt

Okay, maybe Websphere doesn't keep the generated java files.  You found the .class file, right?  It's in your classfile.txt above:
/opt/WebSphere5-1/AppServer/temp/cmsprep3/OpenMarket/OpenMarket/cs.war/jsp/cs_deployed/

This documentation says that you have to set a parameter to make Websphere keep the generated .java files for jsp pages:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rweb_generated_javafiles.html
http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.support.waszos40.doc/html/JSP/swg21169723.html

Here is great documentation on ways to set keepgenerated to true in Websphere:
http://kaushalksinha.blogspot.com/2009/03/websphere-portal-how-to-get-generated.html

Basically you can do it several different ways:
1) with WebSphere Studio Application Developer, in the deployment descriptor, under Extensions, add a new jsp attribute with name="keepgenerated" and value="true"
2) Use JSPBatchCompiler to compile the JSPs for an already deployed webapp:
JspBatchCompiler -enterpriseapp.name enterprise_app_name -webmodule.name web_module_name -cell.name cell_name -node.name node_name -server.name server_name [-filename jsp_name] -keepgenerated true
3)Edit the ibm-web-ext.xmi located in WEB-INF file for the installed Web application.  Edit file in WebSphere_Home/config folder Do NOT edit the file in WebSphere_Home/InstalledApps.  Add the line as shown below, after the webApp element in the same file:
name="keepgenerated" value="true"

Hi,

Yes I found the class file. I have attached it. If i decompile the class file should I get the .java file?
And then be able to look for the line number?

I had to remove the .class from the end of the file name as the site doesnt permit uploading class files. If you could append ".class" to the file I uploaded. Maybe my decompiler is decompiling it incorrectly because I cannot find the line 1661 in the decompiled class file.

aib-layout

Well, the best solution would be to get your Websphere server to save the .java file with the keepgenerated parameter.  Have you tried that?

If not, then it would be interesting to try decompiling the .class file to get a .java file.    The problem is that I don't think the line number in the exception will line up.

So, if you're using a decompiled java file, take the line number with a grain of salt.

As I said in my first answer, the likely problem is a tag that is incorrectly specified in your .jsp file.  If the exception does not happen all the time, then the incorrect specification must be related to the data used in the file -- say a null parameter, or an if statement that conditionally puts in a tag.

The problem with debugging a tag is that it is very difficult.  You have some control over the .jsp file, but none over the tag.  You can try putting in a lot of logging messages around the tags that you think are suspect, and see how many are written just before the exception.

I'm not sure that i would be able to turn on this "keepgenerated parameter" in our production environment anytime soon. Changes to production usually take a while to be implemented, but I could do it in my test environment. However would this be the sufficient? The code is the exact same, does this aib-layout.java file have multiple compiles or is there likely to be just one aib-layour.java file.
Like the layout.jsp file is used at the top level of our site, so depending on what page your in the parameters feeding into the aib-layout.jsp will be different. Will it compile a new aib-layout.java file for each permutation of the parameters? Or will it just be one .java for the all.

Also  what does the " _csX1681919883" mean before in the file: _csX1681919883aib_5F_layout.java


In regards to your first answer about there being an incorrect tag specification I checked our tag library document  and there is an incorrect attribute we are using. I have changed it now, so hopefully this will fix the problem. But it would be uselful if i could get a copy of the .java file from our test server to see if this line number is pointing at the incorrect tag attribute we are using. As the majority of the time the code works fine, it just breaks every now and again.

Thanks for your help.