[eeperson]

Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications.

Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit?

Yes, hot code replacement is faster (although it comes with other tradeoffs). Why can't you do that with standalone Tomcat? What is unreliable about reloading? You can leak PermGen space if you don't finalize your threads properly, but why wouldn't you be running the latest code?

You're right about the web.xml file. I had forgotten about that. I can see why you might prefer to write that in Java code rather than XML.

[lmm]

> Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications.

With an embedded Jetty my app can just be a jar or set of jars. Tomcat has a directory structure and ships as a binary rather than a jar so I'd need to unpack it and worry about it being linked correctly for the target system.

> Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit?

I forget the name - catalina.xml or something? You can't just run ./tomcat -agent:myagent.jar. because it won't pass the arguments through to the JVM, unless that's changed.

[eeperson]

Tomcat is just a Java application. Its install is just a bunch of jar files with some shell scripts to simplify running them. If you look at an install you see that it is just running the Java class ' org.apache.catalina.startup.Bootstrap'. I'm not sure what linking you are worrying about.

For setting JVM arguments, I think you are thinking of 'setenv.sh' or 'setenv.bat'. These are shell scripts where you can set environment variables used when running Tomcat. This includes the standard 'JAVA_OPTS' to set VM arguments.