Costin - Thanks a ton for your reply. Very helpful.
--- [EMAIL PROTECTED] wrote:
> 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".
>
This sound great. I am a big proponent of explicit
configuration (with implicit defaults, of course).
>
> 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.
>
Shouldn't they be by default set relative to the
application home? I.E. if we have one install of
tomcat on the system, (TOMCAT_HOME =
/opt/local/tomcat) and we have two different
applications on the box (using, perhaps different
ports) with different server.xml files and
ContextManager 'home' attributes), the log output
should be consider 'of the application' in each case
and should be implicitely written to paths relative to
the application 'home', not into TOMCAT_HOME. This
is simple OO partitioning of responsibilities.
> If nobody objects to the config changes I'll also
> add the ant-style syntax
> for ${properties}, so you'll have more flexibility.
No objection. Sounds like a good idea. The
${property} syntax is consistent with the Security
Manager policy file format as well. I've implemented
it in my own application's configuration file scheme.
Down the road an include mechanism would be a good
idea to add as well (i.e. add a server.xml element
<server-include> which could take a path (or even a
URL) to an external config file that could be imported
into the DOM). Having built this sort of thing
before, I realize this not trivial (recursion,
protocol for conflict resolution, etc.) but the value
is high.
>
> 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 )
Is this available in the current 3.3 milestone or
nightly builds?
>
>
> 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.
>
That sounds great. At least I now know what is (not)
going on! :-)
Q1: Why does it say in the documentation that
conf/web.xml is used as a default? Needs to be
corrected.
Q2: More importantly, I'm still left with: How do I
configure the use of a different servlet to handle
*.jsp requests?
> 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.
>
Okay, so it sounds like I need to reconfigure the
StaticInterceptor module. And I would do this... how?
Is this possible on 3.2.1 or do I need to go to 3.3
for this? Could someone point me in the right
direction here?
Thanks again for your help.
Mel
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
