Len Wrote:
Unfortunately it's not that simple. Take for example the most common case, a
<Resource> definition for a JDBC database connection. The app writer has to
provide part of the definition (the resource name, e.g. "jdbc/myAppDB") and
the sysadmin has to provide another part (the address of the DB server).
When the application vendor is different from the installer/maintainer, the
context.xml has to be customized at install time.
That's true and I agree that it's handy that Tomcat has the ability to
copy the context.xml file from the war archive and allow that to be
edited. It fits the situation you describe nicely.
However, in a pure development situation, where I'm dealing with a local
Tomcat installation of which I'm my own system administrator and an
exploded deployment of which I'm both the developer and the user at that
point, this mechanism doesn't make a lot of sense and in fact is more of
a liability than an asset.
To me it all would make a lot more sense of there was an option to
disable this copying-and-holding of the context.xml. For exploded
development mode, this option could then be set to false and for
production mode it could be set to true.
Arjan
--
It's a cult. If you've coded for any length of time, you've run across someone
from this warped brotherhood. Their creed: if you can write complicated code,
you must be good.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
