tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arieh Markel <Arieh.Mar...@Central.Sun.COM>
Subject Re: Problem with current mechanism for initialization of Contexts
Date Wed, 01 Mar 2000 23:13:44 GMT

> From: costin@eng.sun.com
> To: tomcat-dev@jakarta.apache.org, Arieh Markel <Arieh.Markel@central.sun.com>
> Subject: Re: Problem with current mechanism for initialization of Contexts
> 
> > 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.

May be I was not clear enough in what I said.

If we want to make XmlMapper a general-purpose tool, then I argue the point
that it should not be limited to accept a File as an argument, but anything
that could be passed on to a Parser object, which is in essence, anything
from which an InputSource can be built from.

Not doing so, limits the utility of XmlMapper.

>  
> > 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.

Why should I limit myself instead of using a proven mechanism ?

My argument stems from the practical side of things:

   a. If Tomcat itself uses the server.xml config mechanism, then I conclude
      that it is well understood, and reasonably debugged.
      
   b. Thus, it is easier for me to dynamically generate such a file, and
      feed it in through the same mechanisms that Tomcat has at its
      disposal.
      

> 
> 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.

I guess we may agree to disagree.

We should be careful to dictate what is the way of doing things. Obviously
I am trying to use Tomcat in ways that were not predicted.  I would guess
that there will be many like me.

--

Thanks for your help.

I will try to follow up your suggestions.


Arieh
--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)


Mime
View raw message