On Sun, 5 Aug 2001 10:48:31 -0700 (PDT), [EMAIL PROTECTED] wrote:
>> More generally, can anything from webl.xml be put in server.xml inside
>> a Context tag's scope?
>
>No, and that's premeditated :-)
Okay.
>Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one
>of the ways to configure tomcat ( there is absolutely nothing in tomcat
>that cares about server.xml except a small module that happens to read
>it). Tomcat doesn't care how is configured - it can be ServerXmlReader
>module, or it can read the modules from a properties file or from an LDAP
>server.
Well, suppose one wanted to use something else instead of or in addition
to the ServerXmlReader module. Would one need to hack Tomcat to do it?
>Web.xml on the other side is a clearly specified format. If something can
>be done in web.xml, it should be done there.
Well, here's the problem I see with web.xml: It comes as part of a war
file. Okay, well and good. But it seems to me that the servlets in a given
war have some context that is war-specifc but in some cases the
context is going to be site-specific (eg the name of a printer to use or
a file path to use to access data or the name of a JDBC database
source and so on). Well, shouldn't a war contain nothing that is
site-specific? I mean, isn't it the whole idea that a war is like a
redistributable application?
So how to provide context to servlets when that context is site-specific? This seems
like a really
basic need.
>But of course, that's just how "proper jakarta-tomcat" works - i.e. how
>the current set of modules operate. This is what we provide and support -
>for anything fancy you can write your own modules, the way you want them.
>It would be trivial to enhance ContextXmlReader - the module that deals
>with <Context> definitions - to support what you want ( but I'm -1 on
>adding any such enhancement to tomcat3.3 - we already have more than we
>need, the 'proper' tomcat should have 1/2 of the modules it has today ).
I can appreciate that. Then I need another solution to my problem.
What do you think of these ideas:
1) Create a directory that is relative to webapps that is not under webapps where
settings for a given
war can go in some settings file.
so
%TOMCAT_HOME%/webapps/reportsystem
would be matched
%TOMCAT_HOME%/settings/reportsystem/
Then in the web.xml one could do:
<context-param>
<param-name>reportsettings</param-name>
<param-value>"../../settings/reportsystem/rptconfig.xml"</param-value>
</context-param>
and after installing the war one would create a relevant file:
%TOMCAT_HOME%/settings/reportsystem/rptconfig.xml
In the initializatoin of a servlet one would then need to do:
String ReportSettingsXMLPath =
this.getServletContext().getInitParameter("reportsettings");
Then have the servlet's init method open and parse the xml file at
ReportSettingsXMLPath in
order to get this out of it:
<context-param>
<param-name>pdf-out-path</param-name>
<param-value>""reports/graphics"</param-value>
</context-param>
The idea is to have the web.xml point to a relative path that is outside of the
subdirectory where
the war gets expanded. This location should be a location that wouldn't get
overwritten by war file
overwrites. The first time a war file is
2) Similar to the previous item but instead is there some way for the web.xml to have
an include
to go get a file that is relative to it htat would insert the original xml snippet so
that the originally
desired info could be put into the servlet context?
I don't know XML well enough but I don't think file includes can be done like this
without XSLT and
I'm guessing that isn't used in reading web.xml.
The class that reads in web.xml would need to be able to recognize and deal with a
relative
include path to some file pathed relative to web.xml or to the curr dir that the
web.xml reader uses.
Then that relative pathed file would have this in it:
<context-param>
<param-name>pdf-out-path</param-name>
<param-value>""reports/graphics"</param-value>
</context-param>
Basically, I need some way tell a web.xml where to find resources that isn't an
absolute path since
it has to be portable to different operating systems and sites.
>> If one does this and it works then a further question: Suppose the
>> web.xml defines the pdf-out-path and then the server.xml/apps-XXXX.xml
>> redefines it again for the same context. Will the
>> latter value _replace_ the former value?
>
>It's up to you and your module. Again, IMHO whatever can be specified in
>web.xml should be specified there.
>
>Tomcat3.3 ( and 3.2 ) already removes another odity - the "default"
>web.xml that generated so many bugs and mess in 3.1. If you want your
>application to be portable, make sure it has all the information it needs
>in its web.xml - anything you put in apps-XXX.xml, server.xml, etc is
>specific to tomcat3.x and will be lost if you move your app to a different
>container.
That's unfortunate. Okay, so I need another approach to this.
