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 Thu, 02 Mar 2000 00:53:39 GMT
Thanks for your response.

I am now in the process of rewriting my initialization class to use
some of your suggestions.

Will let you know how I make progress.

--

Arieh

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

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