After a long and arduous search about why debugging is not working out in Eclipse, it has to do with Tomcat server.
And now I am advised to use remote dubugging.
After, I can't understand why I need to use remote deugging since mine is just a personal project in a local machine and 'remote' has the connotation that I am working at a machine in a WAN setting something like that.
I hope someone can point me to some resources why there is a need to do remote debugging cos I searched the internet but just can't find any useful explanations.
Kindly correct me if I am veered from the right track in this debugging stuff. Tks again.
It seems you think that "remote debugging" can only refer to code running on a different machine. That's not the case. Normally when you debug code in Eclipse, you're debugging code which runs in a JVM which is closely connected to the JVM in which Eclipse is running. Eclipse is written so that it can do that. But apparently, from what you say, Tomcat's JVM isn't connected to Eclipse in that way and hence you have to use a different debugging technique. Which somebody is calling "remote" debugging. This has nothing to do with your idea that it has to be on a different machine.
The debugger isn't actually part of Eclipse. Every JVM has a built-in debugger and it's accessed via a network connection. IDEs such as Eclipse really just provide a user-friendly front-end to that debugger.
When they use the term "remote debug" in Eclipse, what they actually mean is that you'll be running your debugging session with manually-supplied debugger connection information (such as an alternate network port for the debugger). Yes, it can be used to debug apps on remote machines (or to run debugging between multiple local JVMs), but the important thing here isn't what machine the app is on, it's that you specify the network connection to the JVM yourself. That's not the case for "normal" debugging when using an app-specific plugin, where the remote connection to the JVM's debugger is done for you and you don't have to manually connect to the debugging session independently of starting the debugger and app.
What the real problem likely is is this: The J2EE spin of Eclipse has a pre-installed plugin called WTP which can run Tomcat debugging (among other things). However, it does so abominably. The plugin makes an incomplete copy of the Tomcat configuration files and caches them in a place that has to basically be hit with a hammer at times to get updates to the Tomcat configuration to also update the cached partial configuration. The problem is, sometimes people (especially me!) need to customize Tomcat above and beyond what the WTP plugin allows for. Which is why I despise WTP and prefer the sysdeo/mongrel plugin for running Tomcat instead. The sysdeo plugin was designed to run Tomcat using the same configuration that you'd be using if you ran Tomcat without Eclipse.
So the reason you've been told to run "remote debugging" might be simply to avoid the issues relating to WTP. In which case sysdeo/mongrel might be just as useful and somewhat simpler to operate than actually running under the Eclipse Remote Debugging profile. That is, of course, assuming that the release of Eclipse you are running (and the release of Tomcat) is supported by mongrel. The plugin has had a somewhat shaky support history, alas.
Or you might actually need to do some things that require full control of the debugger connection, in which case full Remote Debug features might be in fact the only way to do.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.