I realize that this is probably a 'tomcat-user'
question, but since my intention is towards dev
efforts, I hope no one minds my posting it here.  If
necessary I'll post it to the users list.  I've run
into 3 issues described below.  Of them, #3 is the
most important to me and I really need to get it
resolved rapidly.  Hopefully in all cases I'm just
being an idiot and someone here can nudge me with the
obvious answers. :-)

I'm having trouble figuring out how to setup Tomcat in
the following particular manner:

I've installed Tomcat 3.2.1 into /opt/local/tomcat and
have set TOMCAT_HOME=/opt/local/tomcat.  However I
have a need to keep my actual application completely
separate from the above installation.  (This is not an
unusual idea: keep all application-specific data,
scripts and configuration independent of the COTS
installation).  My application is thus, for example,
installed in APP_HOME=/opt/demo.  I've created a
server.xml file for the application and I start tomcat
using the option "-f /opt/demo/conf/server.xml".  So
far so good.

Issue#1:
The comments in the server.xml file say that by
setting the "home" attribute to the <ContextManager>
element, that "...webapps/, work/ and log/tomcat_logs/
will be relative to this...".  So I set this attribute
to home="/opt/demo".  However, because the tc_log,
servlet_log and JASPER_log are all defined outside the
scope of the <ContextManager>, I soon find that by
default, tomcat still writes it's logs back to
TOMCAT_HOME/logs/*.  There does not seem to be a
single attribute in server.xml that can tell tomcat to
route all Logger output to have a different root
directory (i.e., I'd prefer to write to
APP_HOME/logs/*).  So I am forced to edit the 'path'
attribute of every Logger element to have an absolute
path like so : path="/opt/demo/logs/tomcat.log".

Q: Wouldn't it be easier to have a 'home' attribute on
the <Server> element that would be used as the base
for all relative paths in nested elements (i.e.
<Logger>, <ContextManager>, <Context>, etc.)  And even
better, wouldn't it be nice to be able to set that at
the command-line with a an option?  That would make it
much easier to reuse server.xml settings across
multiple deployments.  Basically, I think tomcat needs
to have the ability to clearly separate the
TOMCAT_HOME installation from the configuration and
data for a particular application.  Not doing so is
kind of like assuming that every user wants to store
all his MS Word documents into C:/Program
Files/Microsoft/Word/documents/ (or wherever the MS
Word application is installed).

Issue#2
Having set the <ContextManager home="/opt/demo" ...>
attribute, Tomcat does seem to be finding the work and
webapps directories correctly.  And it also seems to
create certain output, such as the
"tomcat-apache.conf"  file correctly inside the
"/opt/demo/conf/" directory.

Q: While there are attributes (workDir, path) for
changing the names used for the scratch directory and
the location of a webapp context, there seems no way
to change the name or location used for the conf/
directory.  It is 'fixed' as relative to the home
path.  Since configuration data is often deployment
specific, I would greatly appreciate the ability to
direct tomcat to use a particular directory for conf
(for example if I need to deploy to both linux and nt
I might want to specify APP_HOME/conf/linux/ for one
and APP_HOME/conf/nt/ for the other.).  If this
capability already exists, could someone please
explain to me how to invoke it?


At any rate, given the above, I am now able to run
tomcat and launch, compile and run JSPs using the
default jasper JspServlet.  I am also able to invoke
classes I've included in the CLASSPATH just fine.  I
still have some issue with referencing classes with
the default JasperLoader but I think this is because
the ClassPath pulled from the init-params is not set. 
I'm not to worried about that one.

Issue#3:
The documentation in the "Tomcat - A Minimalistic
User's Guide" says: "Tomcat lets the user define
default web.xml values for all context by putting a
default web.xml file in the conf directory.".  This
sounds reasonable, as there needs to be some global
registration of such servlets as, for example, the
JspServlet.  So, I promptly placed a copy of web.xml
in my APP_HOME/conf directory and edited it to change
the servlet class used for JSPs.   I first tried doing
this by simply replacing:

    <servlet>
        <servlet-name>
            jsp
        </servlet-name>
        <servlet-class>
            org.apache.jasper.runtime.JspServlet
        </servlet-class>
        ....
    </servlet>

with:

    <servlet>
        <servlet-name>
            jsp
        </servlet-name>
        <servlet-class>
            com.my.package.JspServlet
        </servlet-class>
        ....
    </servlet>


At this point, I would expect that tomcat would send
all *.jsp requests to the 'jsp' servlet which should
use my class as indicated above for servlet.  However,
it does not.

At this point, I try making a variety of changes to
the web.xml file, including registering my servlet
class under a different name, changing url pattern
servlet mappings and none of them seem to have any
affect!  I also tried putting the web.xml file into
TOMCAT_HOME/conf instead, but that too does not seem
to have any affect.

Q: How do I get Tomcat to recognize the changes I make
to the default web.xml file?  Basically, I need to be
able to change the servlet class used for *.jsp.

Question #3 above is the most important to me.

If anyone can help me out here, I would greatly
appreciate it.  Am I running into bugs already fixed
in Tomcat 3.3 or 4.0?  I will move to one of those
builds if necessary, but that is not a preferred path
because I don't like to tell my customers I'm
deploying them with experimental code!  :-)

Thanks,

Dr. Mel Martinez
Senior Software Architect
G1440, Inc.
[EMAIL PROTECTED]




__________________________________________________
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]

Reply via email to