Re: LoggerStore

Peter Donald wrote:
> Hi,
> 
> Don't have your last email here but I just went through the changes and I 
> like. One thing you brought up was naming. I still prefer 
> ExcaliburLoggerStore and ExcaliburLoggerStoreFactory because that avoids any 
> future naming problems. 
> 
> It would be useful to gradually move back some Excalibur logging stuff to 
> LogKit. If that was to happen then we would have a name clashe because we 
> would want to name that LogKitLoggerStore if you know what I mean?

I understand what you're trying to get at - but I'm not it's the most 
linear path.
Ultimately, we want to have something called LogKitLoggerStore in which
LogKit also contains its own configuration - much like log4j or jdk14.
When the configuration will be moved to LogKit, we'll be able to swap 
out the LogKitLoggerManager and use LogKit's own config.
But the name of the class should remain the same - simply the 
implementation changed.  And perhaps the name of the factory changed
to reflect the new constructor (ie without the LoggerManager).

make sense?


> Also I changed it so that you don't upcast to a DefaultContext in the 
> SimpleLoggerStoreFactory as that violates Avalon contracts. If you don't 
> specify a context it will create one with current working dir added.
> 

Removed since now handled in SimpleLoggerManager

> Also - what do you think of allowing the user to specify a classname of 
> LoggerManager as a property that the LogKitLoggerStoreFactory will use if 
> there is not already a LoggerManager in config. It will basically try to 
> instantiate an instance of class using no arg constructor. Like?

yep - done.  If no LoggerManager in config, first looks for classname 
under key LogKitLoggerStoreFactory.LOGGER_MANAGER and then defaults to
LogKitLoggerManager.







-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5