lang=”en-us”>Debugging works quite well with SAP NetWeaver Developer Studio and that’s described in the article mentioned in the link above. However, you might be interested in some additional information that makes WebAS Java unique among all the J2EE Servers I know.
lang=”en-us”>Ever tried to debug a J2EE session on a production server? That is something very critical to do, as we know from long-term experience with application servers in general. Sometimes development and testing environments are just not enough, and issues with the software can only be found by really analyzing it running on the original production data in the production environment.
lang=”en-us”>Unfortunately for a J2EE environment, it’s known to run in threaded mode. The moment software reaches a breakpoint not only the desired software is halted at this point, but all other threads running on that process aka server, and all other requests issued by every single user of this server, will halt too.
lang=”en-us”>This is unacceptable for a productive environment; the larger it is, the more unacceptable. How do you resolve this?
lang=”en-us”>There is a solution. At this point it kicks in that every instance of Web Application Server Java (J2EE Engine) is a potential cluster, meaning it can run more than one server on the same host. As you might remember, requests to such servers are always moving through the Java Dispatcher. Once you put a server into debug mode (as described in the tutorial), Web requests marked by the Studio will be forwarded by the dispatcher only to a server in debug mode. Non-marked requests (normal ones) will be delivered to other servers on this host and processed in the normal way.
lang=”en-us”>Isn’t that cool?
lang=”en-us”>Besides this, the debugger works against all sorts of front end applications the Studio provides; Servlets, JSP, and of course Web Dynpro can be debugged with the NetWeaver Environment.
lang=”en-us”>Here’s a picture about the debugger and how it’s configured: