tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carreira, Jason" <>
Subject RE: config diag, etc
Date Tue, 10 Aug 1999 17:54:47 GMT

> -----Original Message-----
> From: James Todd []
> for what it is worth, i'm completely on the same page. i
> don't want to unintentionally preclude using some ?advanced?
> api's as time permits (hence my 1-pager) but i do think
> we have critical mass to start fleshing this little gig
> out with some "out-of-the-gate" principles and first deliverables.
> i'm all for patterns. i agree with your recommended narrowed
> use of uml. i tend to draw the "rolled up class diagrams" (not
> sure what it is actually called) and not worry too much about
> gettting all the fields right or cardinality nailed down initially.
> here's a recap of what i think are the initial ?constructs?
> we're aiming for:
> 	http - to - cgi (eg servlet) service
> 		focus on "get" requests initially
> 		(eg client obtains read-only config
> 		data)
> 		data format could be:
> 			xml (not necessarily the same xml
> 			format as defined by the config file)
> 			serialized objects
> 	config manager/broker process (logic)
> 		config reader (url, xml parser)
> 	xml config format (dtd)
> this should be the bare minimum yet provided a pretty
> compelling bang-for-the-buck perspective.
> within tomcat, there is a light-weight "startup" program
> which effectively is acts a a tightly coupled config broker.
> it uses the ProjectX parser distributed by sun at the moment.
> as i see it, this piece of logic could be factored out to a
> "client independent" broker service quite readily.
> cool,
> - james

I agree that this is a good place to start, but I think we also need to
think about the dynamic config service APIs sometime before the code-drop so
that the ability to receive config change callbacks and update the internal
config without restarting can be built into the Tomcat code... I don't
really have any clue how far out the code-drop is to say whether this is
something that can wait, or if it's something that needs to be addressed


View raw message