tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cos...@eng.sun.com
Subject Re: Problem with current mechanism for initialization of Contexts
Date Wed, 01 Mar 2000 20:16:02 GMT
> With regards to the problem above.
> 
> I think I have come up with an alternative solution to resolving the
> runtime determination of the docBase/home on the server.xml file.
> 
> Here is what I intend to do:
> 
> On util.xml.XmlMapper, add the following methods:
> 
> 	public Object readXml (Reader rdr, Object root)
> 	
> 	public Object readXml (String str, Object root)
> 	
> The InputSource class, accepts a Reader or a String argument in its
> constructor.
> 
> In this manner, my program can read-in the server.xml 'template' file, from
> the location where it exists, perform appropriate string replacements and be 
> successfully initialized.

There is a simpler solution - don't use Tomcat.java or the XML file at
all.  
Or use the server.XML file only to configure the connectors.

Tomcat.java is very simple and you can extend/replace it - in your case it
seems the right solution. 

Replacing strings in server.xml seems like a hack to me - it may work, but
it's better to use the APIs - and we tried to provide all the APIs
for what you need ( since we need the same APIs for admin !).

Changing XmlMapper in this way doesn't sound right.
 
> Such a solution allows for applications to hold their server.xml in
> formats other than explicit files (think of having them as constants,
> properties in resource files, etc).

That was one of the design goals for tomcat. We want to be able to embed
tomcat in systems that use different configuration systems ( like JNDI in
J2EE ) - and the solution is to use APIs.

server.xml is the configuration format for tomcat standalone. Don't use it
for embeded - use your own system and create an adapter.

Tomcat.java is just an adapter that will set up tomcat from
server.xml-type config. 
 
> It would be a valid solution, for example, for embedded systems where
> there may be limitations of filesystem access.

Yes, but I don't think it's the best solution.

Costin


Mime
View raw message