Also what I do not understand is that, eclipse is trying to start tomcat 6.0.29 which is not at all installed. I guess eclipse uses this embedded tomcat. But where the heck do I find it? I guess if I could find the tomcat location, then I could copy the spring instrument class loader to its lib path and that should solve my problem above.
Eclipse doesn't in the purest literal sense run Tomcat.
Instead, that function is achieved by an Eclipse plug-in, which launches an embedded Tomcat server.
There are at least two ways to do that. The most popular way is via the WTP Tomcat plugin, which comes pre-installed with the J2EE spin of Eclipse. To say that I loathe and despise it it to ignore the fact that I fall down on the floor shouting and screaming and foaming at the mouth whenever it is mentioned.
Another common way is to use the Tomcat plug-in from sysdeo. While it does not integrate into the "Run on Server" menus and other WTP controls and configurations, it also doesn't do a foul job of replicating a complex real-world Tomcat runtime like WTP does. It uses your Tomcat configurations directly instead of making hidden incomplete copies that have to periodically be manually refreshed. Whoops. pardon while my blood pressure returns to normal.
Attempting to run Tomcat via Maven within eclipse is not a practice that I would recommend. The actual Eclipse plugins integrate into Eclipse's debugging system automatically. Maven, on the other hand, is primarily expecting to run with no IDE present, and not to favor a particular IDE such as Eclipse, NetBeans, IntelliJ, or JDeveloper.
For that reason, I use Maven within Eclipse to build my artifacts, but the actual running and debugging of my webapps is done by using the sysdeo Tomcat plugin.
An IDE is no substitute for an Intelligent Developer.
Ok. The Sysdeo plugin comes pre installed in eclipse Juno. Fine!
I have a multi-module maven project. The final build is a war file that is contained in the web project. This web project in turn has dependencies of the other modules which are jar files. I have converted this web project as a dynamic web project so that eclipse could work with it. But when I start tomcat, I do not see the other dependencies at all. In fact there is no lib folder in my maven web project as this will be filled by maven build. Is there any suggestion as to why the web app would not be deployed with the tomcat sysdeo plugin.
I opened up the Tomcat Preferences (Window/Preferences/Tomcat) and set the following in the JVM Settings/Append to JVM Parameters:
I placed both Spring weaver jars in that directory.
I don't mess with "Dynamic web project" because I'm not sure how well that works when the web project isn't running under WTP's version of Tomcat nor how well it correlates with Maven's directory structure requirements. Instead I just do a standard Maven web project and have Eclipse execute the maven "clean compile war:war" set of goals. Since I have my Tomcat webapp Context set up to point to the project's maven target directory, which contains the WAR in both exploded and WAR file format, Tomcat runs using that.
As far as I can tell "Dynamic web project" means "Project hacked up to work with WTP". And since Ich hasse WTP sehr, I don't use "Dynamic web project" at all. All I use is the basic IDE-independent Maven webapp (WAR) project format, although I usually run the "eclipse:eclipse" goal to get Maven to auto-generate the Eclipse ".project" and ".classpath" files for me so I don't have to set it all up manually. That, however, is something I only do once, since I save those files along with the source under version control, as they are user-independent files.
If you are confused about the Spring Agent and the Spring waever, you may rejoice in knowing that you belong to the same club that I do. I read a lot of documentation, and some of it conflicts, but this is what I ended up with that works. Until the Spring people break it or a JVM is released that can adopt the necessary aspect-oriented enhancements in a cleaner matter. Oder etwas. Or something.
Anyway, here are the actual files in my Tomcat 6.0.18 lib directory. They seem to work OK in Tomcat7, too:
The agent, like all agents (on on good days I can remember what a JVM agent actually is), must be explicitly configured into the JVM. And on really good days, I can even remember why it must be so configured. I think it's because it hooks into the core classloader code.
The weaver is sufficient to be in the normal classpath, so it doesn't require an explicit configuration or activation. Everything it needs it gets from the application's Spring configuration.
Could you please let me know where do I specify the context path such that the docBase points to my target folder? Do you mean the context.xml file which is found under the Servers tab that lists the servers that I have added to eclipse? I was under the impression that the context.xml and server.xml files are generated for every clean and publish cycle of tomcat.
I managed to get this done. But then comes the next question. What about hot deployment? I make some changes to my sources and when I want to see those changes in my jsp page, I have to restart tomcat again. Is there a simpler way without restart? Another eclipse plugin?
Hot deployment is usually more trouble than it is worth. That is especially true for Tomcat6 using the enhancements you want, as chances are very good that the entire Tomcat server will go kaput on a PermGen Space error.
PermGen space is a special memory pool that by default is about 128K and it tends not to get freed up when a new deployment is done. Since Tomcat can restart fairly rapidly, I usually find it easier not to hot-deploy.
A few conditions apply, however. For data files like page templates, where no new classes need to be loaded and my debugging is being done against an exploded WAR generated by Maven, I can do a "mvn -o war:exploded" and update just those files without restarting. That is handy for tweaking the layout of pages.
On the other hand, anything that has to do with the low-level database resources almost cannot be done without restarting Tomcat, since otherwise critical code done only at application startup will not run. You would have to manually stop the webapp, redeploy, then restart the webapp. And then you'd still be at risk for PermGen issues.