Radhakrishnan J wrote: > Eclipse's Debug UI shows the breakpoints threadwise. If these executions > are happening over different threads, thats one way to tell the difference.
It's not the thread that's the issue - it's which _webapp_ it's currently executing. That's what the OP cared about - to stop in a particular class if it was being executed out of webapp1, but not in webapp2. Ofcouse thats true. I was just throwing in ideas to differentiate the executions. But yes that doesn't help you identify the webapp. The thread pool of HTTP connectors is shared by all webapps in a Tomcat instance, so merely knowing "which thread" hit the breakpoint is useless, unless you can also convey in some form what webapp it is currently executing the code for. If you dig enough you should be able to find this. My guess would be that there'd be some local variable of some tomcat class that'd could tell you which appliction is the thread working for. You should probably walk back thru' the call trace in your debugger and inspect the state of execution to find this. This information is not easily (perhaps not at all - I'm not an expert) available in the current JVMTI API (and definitely not in the JVMDI API), so the debugging agent won't be able to tell which webapp the code is executing at the moment. Servlet Engine, Webapp are all higher level notions. The JVMTI is "JVM" level feature. The out of the box debuggers are not "servlet-engine aware" or "webapplication-aware". The place to look for would be local variables within tomcat code. But again the assumption is that the tomcat classes have debug information available. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
