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 01:34:35 GMT

[ I said earlier ]
> 
> 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.

So, I was able to start the embedded webserver.

I ran into a couple of issues.

. ContextManager needs to be inserted to Context prior to invoking
  other methods.
  
  	Context ctx = new Context().setContextManager (cm);
  	
  
  This, since the 'log' method of Context, relies on logging through the
  ContextManager.log method.
  
  I am wondering whether this should be caught, by checking whether the
  ContextM variable in Context has not been set.
  
Arieh


> 
> --
> 
> 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)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

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