JSP compiler obfuscates generated servlet debug line numbers

Question

          Here's something that's been baffling me for a couple of days now.
          When WebLogic parses a JSP into servlet Java source, and then compiles the Java
          source into a class, it seems to perform a further step to obfuscate debug line
          numbers in the _jspService method. This converts the debug line numbers from Java
          source code line numbers into JSP line numbers.
          At first sight, this may appear to be useful- it means that when an exception
          is thrown then it references a line number in the original JSP rather than one
          in the generated servlet. However, it actually makes life more difficult when
          you consider included JSPs.
          Suppose you have a file loginresult.jsp, which uses @include to include a header.jsp
          and footer.jsp, both of which contain dynamic content. When WebLogic converts
          line numbers, it ignores the JSP that the code came from, so this causes a many-to-one
          mapping of line numbers. When an error occurs, the exception will tell you the
          line number that it came from, but it won't tell you which JSP caused it. The
          many-to-one mapping ensures a loss of information- and no way of retrieving the
          real line numbers.
          This is an even bigger nuisance when trying to debug JSPs- the debugger hops around
          in the generated servlet file without giving any clue as to whereabouts it really
          is in the code.
          My question is: is there any way of switching off this post-processor behaviour?
          One obvious way would be to locate the WebLogic class that does this post-processing,
          stub it out and run WebLogic with this class higher up in the classpath. But that's
          a last resort.
          Secondly, would there be any other impact in turning off this behaviour? Do other
          parts of WebLogic rely on this?
          Thanks in advance,
          Kevin.
          

Answer 1

Actually, this option turns line-number table replacement on and off, for example,
          with jsp like this:
          test.jsp
          <%
          throw new Exception();
          %>
          and weblogic.xml:
          <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
          Systems, Inc.//DTD Web Application 7.0//EN"
          "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
          <weblogic-web-app>
          <jsp-descriptor>
          <jsp-param>
          <param-name>debug</param-name>
          <param-value>true</param-value>
          </jsp-param>
          </jsp-descriptor>
          </weblogic-web-app>
          the stacktrace looks like this (note line number 2 - this is JSP line number):
          java.lang.Exception
          at jsp_servlet.__test._jspService(test.jsp:2)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
          at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
          at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
          at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
          at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          and with debug option turned off:
          <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
          Systems, Inc.//DTD Web Application 7.0//EN"
          "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
          <weblogic-web-app>
          <jsp-descriptor>
          <jsp-param>
          <param-name>debug</param-name>
          <param-value>false</param-value>
          </jsp-param>
          </jsp-descriptor>
          </weblogic-web-app>
          exception stacktrace looks like this (note that line number now is from generated .java file):
          java.lang.Exception
          at jsp_servlet.__test._jspService(__test.java:87)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
          at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
          at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
          at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
          at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          Kevin Thomas <[email protected]> wrote:
          > But this isn't useful, as you don't know which JSP the line number is referring
          > to! (did it come from the main JSP, or one of the files that it included?)
          > Turning debug off is not an answer- because that will lose other useful information
          > that is useful to the debugger.
          > Kevin.
          > "Dimitri I. Rakitine" <[email protected]> wrote:
          >>Actually, this is useful when you want to debug .jsp's and not generated
          >>..java files. Did you try setting 'debug' jsp-param in the weblogic.xml
          >>to
          >>false? I think it turns class postprocessing on and off.
          >>
          >>Kevin Thomas <[email protected]> wrote:
          >>
          >>> Here's something that's been baffling me for a couple of days now.
          >>
          >>> When WebLogic parses a JSP into servlet Java source, and then compiles
          >>the Java
          >>> source into a class, it seems to perform a further step to obfuscate
          >>debug line
          >>> numbers in the _jspService method. This converts the debug line numbers
          >>from Java
          >>> source code line numbers into JSP line numbers.
          >>
          >>> At first sight, this may appear to be useful- it means that when an
          >>exception
          >>> is thrown then it references a line number in the original JSP rather
          >>than one
          >>> in the generated servlet. However, it actually makes life more difficult
          >>when
          >>> you consider included JSPs.
          >>
          >>> Suppose you have a file loginresult.jsp, which uses @include to include
          >>a header.jsp
          >>> and footer.jsp, both of which contain dynamic content. When WebLogic
          >>converts
          >>> line numbers, it ignores the JSP that the code came from, so this causes
          >>a many-to-one
          >>> mapping of line numbers. When an error occurs, the exception will tell
          >>you the
          >>> line number that it came from, but it won't tell you which JSP caused
          >>it. The
          >>> many-to-one mapping ensures a loss of information- and no way of retrieving
          >>the
          >>> real line numbers.
          >>
          >>> This is an even bigger nuisance when trying to debug JSPs- the debugger
          >>hops around
          >>> in the generated servlet file without giving any clue as to whereabouts
          >>it really
          >>> is in the code.
          >>
          >>> My question is: is there any way of switching off this post-processor
          >>behaviour?
          >>> One obvious way would be to locate the WebLogic class that does this
          >>post-processing,
          >>> stub it out and run WebLogic with this class higher up in the classpath.
          >>But that's
          >>> a last resort.
          >>
          >>> Secondly, would there be any other impact in turning off this behaviour?
          >>Do other
          >>> parts of WebLogic rely on this?
          >>
          >>> Thanks in advance,
          >>
          >>> Kevin.
          >>
          >>--
          >>Dimitri
          >>
          Dimitri