> > In 3.3, the logs are corectly set relative to
> > TOMCAT_HOME.
> and should be implicitely written to paths relative to
> the application 'home', not into TOMCAT_HOME. This
> is simple OO partitioning of responsibilities.
Ok, this is a clear example of what's wrong with the current
status - there are 2 directories that can be set on ContextManager,
one is "home" and the other one is "installDir".
The env. variable is used to set home.
If one is set and the other not - both share the same value.
InstallDir is the one used for jar files ( and all "shared" files ).
home is supposed to be used for the local instance.
( the model is again a shared installation - /usr/local or /opt/tomcat
and each user having it's own config and set of applications ).
That's just a particular use case, and even for that it's too complex.
By using explicit paths we can accomodate more use cases and be
very clear about what goes where.
> 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
No need, it's already done ( and in 3.2 too ).
( I have no idea who did it - it's not me, and I was
quite surprised to find it there :-)
Any file named server-foo.xml will be read and used
as addition to server.xml.
In 3.3 you can use <serverXmlReader> to read additional
files in arbitrary locations.
Part of the current proposal is to formalize that
and use explicit directives for what gets read.
> > 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?
The first milestone will happen soon, it's only in
the nightly builds and it's not yet completed (
i.e. some of the paths are now configurable, but
not all and not in all modules ).
One of the goals for 3.3 release is to have all those
small things that makes configuration easy ( as
usability enhancements ).
> Q1: Why does it say in the documentation that
> conf/web.xml is used as a default? Needs to be
> corrected.
I agree.
> Q2: More importantly, I'm still left with: How do I
> configure the use of a different servlet to handle
> *.jsp requests?
In 3.3 - in JspInterceptor you have "useJspServlet" and
"jspServlet" that allows you to specify it on a global
level ( or per context ! ).
This is strongly discuraged - as it'll be much slower than
using JspInterceptor's optimizations.
If your jsp processor does something special, you can
bundle it with your application and use the web.xml
( from WEB-INF ) to set it. Then your app will work
on any container the way you expect.
> 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?
Again - you can do it in a portable way ( using web.xml
in your application ) or tomcat-specific, by replacing
StaticInterceptor.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
