Re: LoggerStore

Peter Donald wrote:
> Hi,
> 
> I just did some reworking of the code. Can you have a look and see if you 
> like? The one significant thing I have done is introduce a new class 
> InitialLoggerStoreFactory. It acts in a manner similar to JNDIs 
> InitialContext. 

Yep - I like it.  Very clean and portable.

A couple of minor comments on the reworking:
- Even though atm only Log4J has more than one configuration type, I had
envisaged that eg JDK14 might have an XML configuration soon
(and one could  actually write a configuration parser if one wanted).
So, since the types XML and PROPERTIES are quite generic, how about
moving them to the LoggerStoreFactory interface?

- Log4J Element configuration relies on the EntityResolver for correct 
configuration.  I've noticed you moved the buildElement function in the
test case and I have no objection as it is a utility function.
But I'd like to put in more evidence the need for the EntityResolver
in the Log4JLoggerStore.
How about adding it to the constructor, say
    Log4JLoggerStore( Element, EntityResolver)
and have the constructor verify that it is the correct EntityResolver?
I know it does not prevent someone from passing in an Element parsed
with another or no EntityResolver, but it does highlight its need to the 
API client.


Also:
- I've replace HierarchyUtil with the LogKitLoggerManager for the 
LogTargets cache.  I've posted the patch to the avalon list for the
LoggerManager.  Until then the build relies on a snapshot version of
excalibur-logger with the patch applied.
Could gump be disabled until that time or the snapshot jar be added to
gumpified build?


Cheers




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge