[Keith Fetterman]

Tonight, I discovered that I can debug JSP files directly. But, it doesn’t seem to be consistent. Sometimes when I set a breakpoint, the debugger doesn’t stop on the breakpoint. Other times it does. I know the code that has the breakpoint set should be executed every time.

I noticed that the breakpoints that get caught are identified with a blue circle with a check. The ones that don’t get caught are only a blue circle.

In the same JSP file I will notice that some Java statements will accept a breakpoint that will be caught, and other statements wont.

Why aren’t all the breakpoints in the scriptlets catchable? What are some statements different that others in the same file?

I am running Eclipse 3.0.1, MyEclipse 3.8.2 with the second quickfix. My application server is Resin 3. I am not deploying to the server. Instead, I have the server mapped to my development environment.

Thanks,
Keith

[Olov_Felton]

I have noticed a similar problem, but also found a way around it. For me, breakpoint set in jsp pages after the server has been started won’t work until I restart tomcat, but then they work as they are supposed to.

Running Eclipse 3.0.1, MyEclipse 3.8.2 second quickfix, Tomcat 5.

[Riyad Kalla]

Keith,
The breakpoints with the checkmark show you a class (or page) that the application server has confirmed it has loaded, if there is no checkmark, it means the app server does not have that class (page) loaded, but it still may load the page depending on your execution flow of the app.

I just wrote a little app that when I click a button, the page reloads and I set a breakpoint at a scriplet in the page… the breakpoint was hit every time. If you are able to reproduce this, sending us a sample project is the fastest way for us to knock this one out.

Also make sure you are using a 1.4 VM (the later the version, the better… 1.4.2_06 is the best for debugging) to run Eclipse and your app server. Also does Resin support the JSR 45 spec? That is required for successful JSP debugging.

[Keith Fetterman]

thanks. I will try this.

Yes, Resin 3.0.9 supports it but their may be a bug. I am checking with Caucho right now.

Does JSP debugging work in included JSP files? for example, if i set a breakpoint in cartInit.jsp which is included in another JSP file as specified below, will the breakpoint be caught?

<%@ include file="cartInit.jsp" %>

[Riyad Kalla]

Yes, we had a bug a while back (pre 3.8.1 I believe) that made breakpoints in includes flaky, but it should be working now.

[bjorn.ekengren@home.se]

Hello, I’m experiencing similar problems, I could get jsp debugging to work during the tutorial, but when I try to set breakpoints in my own projects they simply will not get set (no checkmark). I also discovered that setting breakpoints in the tutorial file it worked at some lines, but at others it didn’t.

I’m btw using resin 3.0.9-pro, eclipse 3.0.1 and Myeclipse 3.8.3

[Scott Anderson]

Bjorn,

when I try to set breakpoints in my own projects they simply will not get set (no checkmark)

First, please note that you won’t see a checkmark until the generated java class is loaded by the remote JVM when the page is first accessed. So, unless you’ve hit the page at least once with a browser, the checkmark won’t be displayed. If you have loaded the page in a browser and still don’t see the checkmark, please ensure that you’re setting a breakpoint on a line of Java code, not HTML or a tag. If that’s the case, do you have any other JSP’s in the workspace with the same name and relative path from the web root in any other projects?

[bjorn.ekengren@home.se]

Ok, well I tried the various options you suggest without any result. I do have two pages with the sam name (login.jsp), but at completely different relative paths from the web root. I also tried with some files with unique names without any success.

[Scott Anderson]

OK, are you launching the server in Debug mode with a 1.4.1+ JDK? What is different between the test projects you ran and this one? Can you pull one of the JSP pages from the test project into your current one and see if breakpoints still work in the test JSP file? This will show if it’s a JSP page-level problem or a launch/project problem.

[bjorn.ekengren@home.se]

I’m using jdk 1.4.2_02 and I’m launching resin in debug mode. I pulled a JSP from the test project (HelloWorld.jsp) to my current one and it works fine. The other way around however doesn’t. I also noted that I cannot set breakpoints at the first scriptlet part of the page:

<%
String path = request.getContextPath();
String basePath = request.getScheme()+”://”+request.getServerName()+”:”+request.getServerPort()+path+”/”;
%>

[bjorn.ekengren@home.se]

I have found that I can shrink the problem a bit. By editing the Helloworld.jsp in the following way:

<%
out.println(“Hello World”);
StringBuffer sb = new StringBuffer(” <br>”);
for (int i=0; i<sb.length(); i++){
out.print(sb.charAt(i));
}
out.println(“Hello World”);
%>

I have found that I can set a breakpoint at the first out.println(“Hello World”); but not the last one. How strange is that on a scale from here to Säffle ?

[Scott Anderson]

Actually, it’s not that peculiar. You see, each application server is responsible for providing a source map (under JSR-045) that maps the source lines in a JSP to the generated Java lines. We perform the reverse lookup to map from the breakpoint you set in the JSP source to the proper line using the map. However, some application servers don’t provide very good maps, while others optimize the generated Java code so much that very few lines are generated and a mapping line isn’t available, according to the source map. To verify this, how about trying to deploy your project on Tomcat 5 and testing breakpoints there. I think you’ll see the behavior is different because Tomcat 5 ships in a default mode of “debug” for JSPs. My guess is that Resin provides a source map but optimizes the generated code, thus making stepping problematic. However, there’s likeliy a way to tell Resin not to optimize the Java, but that’s outside my ken, unfortunately.

[Author]

Posts