Hi. I have a weird problem and I'm hoping someone has seen something like it. I was using NetBeans to develop a simple Spring 2.5 MVC web application and using Tomcat 6.0.20 for my server. For weeks everything had been going well. Then, from Netbeans, I would try to deploy and run the project and I would get the deploying message and that was it. NetBeans isn't hanging but ... the web application didn't deploy. And the logs didn't give any indication of any errors.
I wound up using the windows services to stop another instance of 6.0.20 that I run all the time. I can use NetBeans to build the webapp and then I copy the files to the other instance and start. From this instance, I *was* able to access the application, get error messages, etc. but I can't debug using this setup and it's a little strange.
Sounds just like Eclipse. I try not to run a server, either Tomcat or any App Server directly in my IDE. While it is a neat feature and automatic deployment. I found it easy to set up Tomcat in its own directory and point to the build directory of my project and then run "mvn package" in my project and I am just as good and fast.
Because, in many cases the IDE's "framework" of how it runs things can get messed up and you spend time fixing IDE problems and not app problems. For instance, I tried using Eclipse to run Tomcat and I would always have to Clean, Restart Eclipse etc to finally get the in memory model to clean itself and actually deploy the app.
Thanks for the good advice. I am close to a solution on this. The problem was definitely caused by a mistake on my part. I think I refactored/renamed class and while NetBeans is good, it's not perfect. I should have checked over all the code.
So I have gotten past the problem but I want to come back and write up a crisper explanation.
One problem in general is that because of DI, the IDE doesn't know which classes will be instantiated. So it does the best it can checking your code but it's not as bullet proof as when was everything complied together without Spring. Using DI is still the way to go, but more of the burden of making sure the code is correct shifts back from the IDE to the developer.