Berin, I'm workng on the ContextManager code right now, and I think a different approach is needed.
Right now we have two ways to set up a logkit config (for example): Pass in a finished configuration, or load one from a URI. If you load one from a URI, that will call getComponentManager(), which will instantiate a component manager. Then you have setComponentManager( ComponentManager manager ), and suddenly you have a mess of methods that must be called in a certain order. I propose to do away with all setXXX methods from ContextManager and have it work this way: You pass in an optional root context and override context. Period. The override context is processed by the ContextManager. The ContextManager creates a childContext = new DefaultContext (rootContext); And then uses the information in overrideContext to populate the childContext. For example, if the override context has a "container.logManager" entry, this entry is copied over to childContext unchanged. If not, ContextManager looks for container.logManager.config in overrideContext and uses it to set up a LogKitLoggerManager. If that isn't present, it looks for a container.logManager.configURI, loads configurations from that and sets up a LogKitLoggerManager. If that isn't present it will look in the root context for a container.logManager, and if that isn't present, set up a LogKitLoggerManager with defaults. This way, we can control the order in which the defaults are applied. What do you think? /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
