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 23:47:29 GMT
> 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.

That's fine, we can extend XmlMapper to read from other input sources.

We can even add ant-like properties - that will probably also help 
special cases like yours. 

Both are features we can add later - but right now we want to fix bugs and
make everything stable, I don't think adding any feature is a good idea. 
If it's critical for you and you feel it's a bug - we can find a solution.

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

I was thinking that you already have a configuration mechanism - like 
JNDI ( LDAP, NIS, etc). 

If you don't have anything - XML is a very good solution. 
Even with XML - you may have other components in your application that
needs to be configured - or you may have a better syntax - server.xml is
limited to tomcat configuration right now.

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

If server.xml is good enough for you - just use it. You can also generate
the file before starting tomcat. 

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

My point was that this is something that was "predicted", in fact it's one
of the important design goals we had in mind. 

We tried to make the configuration independent of the rest of tomcat in
order to allow applications to embed tomcat.

server.xml still has some limitations and it's not ( IMHO ) the best way
to configure tomcat. I think it's too early to treat server.xml as a
"standard" or even "stable". We need a lot of feedback on the general
organization, we want to make it extensible, etc.

Costin




Mime
View raw message