The intention ( in tc3.3 ) is to make all the configurations "explicit",
instead of using conventions like "webapps will be in home, libs in
install, etc".
Even in 3.2 we tried to allow a shared installation dir and multiple
work dirs ( i.e. you have one tomcat installed in /opt/tomcat, and each
user can run it with it's port and webapps ). This is not a "supported"
feature - i.e. it's not very well tested or documented.
For issue #1, it's a bug - logs are "special" in 3.2 and they were not
made relative to the home. The workaround is to use explicit paths.
In 3.3, the logs are corectly set relative to TOMCAT_HOME.
If nobody objects to the config changes I'll also add the ant-style syntax
for ${properties}, so you'll have more flexibility. Nacho started
a nice idea in the loggers ( adding a ${TIMESTMAP} ), and I plan to add
other pre-defined properties (like configdir, context home, context
workdir ).
Again - the current mechanism is indeed a bit confusing and complex, and
making it explicit will be a big step forward ( i.e. all paths will use
${tomcat.home}/logs/mylog.log )
> better, wouldn't it be nice to be able to set that at
> the command-line with a an option? That would make it
That's something I work on, but it's lower priority. ( better command line
support )
Issue #2 ( conf dir ) - again, in 3.3 most if this is configurable via
individual module options. For example the apache.conf is generated by a
module - and you'll be able to set the location to anything you want
( or any other properties that affect its behavior )
Henri proposed to make it simple to use Linux-style hierarchy ( with
all logs in /var/log, configs in /etc/tomcat, webapps in /var/tomcat,
etc). Apache also have a "layout" option.
Regarding Issue #3 - the web.xml is not used in tomcat3.2,
and will not be used in tomcat3.3. All the server config
is done using server.xml ( and the new context.xml ) files.
There shouldn't be any overlap between web.xml and sever.xml,
any setting that is part of web.xml should be part of
the web application's WEB-INF to make sure the app is
portable ( if you rely on any tomcat-specific default,
your app will work only on tomcat).
Server.xml sets server behavior. For example, the
conversion between .jsp and java is a server property.
The static interceptor is a server property. Everything
that is not defined in the web.dtd belongs in server.xml,
and it's specific to tomcat. What is defined in web.dtd
and the spec belongs to WEB-INF/web.xml.
> At this point, I try making a variety of changes to
> the web.xml file, including registering my servlet
Web.xml is not read - it's just a template you can
use for your applications.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
