False impression #1:
JSP doesn't stand for Java Script Pages, it stands for Java
Server Pages. I'm guessing you've coded enough logic on your JSPs that the misintgerpretation was natural. And now you've discovered one of the reasons why placing logic on JSPs is discouraged. Because they're a royal pain to debug. It's
much easier to put logic in Java and reserve the JSPs for display output. And fringe benefits include scalability, maintainability, the ability to use HTML editors on the JSPs (J2Ps full of scriptlets drive HTML designers crazy), and likely more application security.
False Impression #2: Eclipse is not a
J2EE container, so it doesn't care or know about JSPs. To develop and debug J2EE apps in Eclipse, most people add some sort of J2EE support pluging to their Eclipse system, such as the sysdeo
Tomcat plugin. The exact location of the J2EE support directories will depend on which plugin you use and on any option overrides you might have applied to the plugin.
If you know where the compiled classes are going, and you insist on coding logic in your JSPs,
you should be able to add the class directory to your project properties.
I
have managed to set breakpoints in JSPs, but that's about all the details I can give, since I learned to keep my code out of the JSPs, so I don't need JSP breakpoints anymore. Since my favorite architecture these days is
JSF, the JSF-generated generated Java code is so nasty I prefer not to even try.