views:

479

answers:

2

I am getting a null pointer exception in jsp and I want to find out what line has the null variable so i can fix it. Is there any simple way to do this? The printStackTrace didn't seem to give me any relevant information.

Stack Trace:

java.lang.NullPointerException 
    at org.apache.jsp.data.index2_jsp._jspService(index2_jsp.java:176) 
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331) 
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329) 
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
    at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Method.java:616) 
    at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAsPrivileged(Subject.java:537) 
    at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) 
    at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:262) 
    at org.apache.catalina.core.ApplicationFilterChain.access$0(ApplicationFilterChain.java:192) 
    at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:171) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:167) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) 
    at org.apache.catalina.co
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) 
    at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:420)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
    at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) 
    at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) 
    at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) 
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) 
    at java.lang.Thread.run(Thread.java:636) 
+1  A: 

It's not pretty but you could go into the work directory and find the specified Java file (the converted JSP) and see what operations are on the specified line. Generally Tomcat will keep the source for the generated servlet around unless configured not to. It should at least help you find the error-point or the corresponding JSP line.

Hope this helps.

cjstehno
A: 

This is where it is been caused:

at org.apache.jsp.data.index2_jsp._jspService(index2_jsp.java:176) 

You probably already know, JSP's are compiled to a Java classes during startup or on first request. You can find them in the work directory of the appserver in question. Search for the file named index2_jsp.java and head to line 176. It's there where some object reference is been accessed while it is null and thus caused the NPE. You need to backtrack the particular line in the original JSP file and fix it there.

That said, this indicates that you're using scriptlets (the <% %> things) in a JSP file. This is considered poor practice. It's under each much harder to debug and naildown problems like this as you encountered yourself. In a well-designed web application you should not have any scriptlet in a JSP file. Use taglibs like JSTL to control the page flow and use EL (Expression Language) to access backend data. The remnant of raw Java code belongs in real Java classes, such as a servlet class to control, preprocess and/or postprocess the request/response and a Javabean to hold and transfer the data and so on.

Exceptions/errors in taglibs and EL are much better and clearer handled. Exceptions in real Java classes are in turn also much easier to backtrack and fix.

BalusC
I can't help but use scriptlets at this point, it's not my choice. the exception that is thrown is at line 170, and there's another try after that that contains 176, so I'm confused as to why it would say 176
Lye
The line number concerns the generated Java file, not the original JSP file.
BalusC