Rodney,
You probably want to add these methods to your Log interface to avoid expensive
parameter constructions:
boolean isDebugEnabled()
boolean isInfoEnabled()
boolean isEnabledFor(Priority priority) // probably not possible to add
Regards, Ceki
At 21:44 02.08.2001 +0200, you wrote:
>At 13:44 02.08.2001 -0500, Waldhoff, Rodney wrote:
>>> After taking a cursory look at the code I would suggest
>>> to stick with NOPLog and Log4jCategoryLog. Moreover, you
>>> probably want to delegate the category look up to log4j
>>> instead of maintaining your own hashtable/hashmap. Not
>>> only will this be faster but also safer. Just my 2c, Ceki
>>
>>Thanks Ceki.
>>
>>The second suggestion follows from the first. As long as SimpleLog exists,
>>there is some need for the cache of logs in LogSource, otherwise you'll get
>>a distinct instance of SimpleLog, even if it has the same name/category.
>
>Right. Having multiple instances of SimpleLog for the same name would be unacceptable.
>
>>(Well, that's not a critical problem, but it seems less efficient,
>>especially if we were to add synchronization per log category.) Not caching
>>the log instances would exchange memory for a little bit of time, but I'm
>>assuming clients will maintain a static or instance variable referencing the
>>Log instance and hence the makeNewLogInstance would be invoked quite rarely.
>
>Assuming that makeNewLogInstance would be invoked quite rarely is reasonable. I don't
>understand your point about adding synchronization per log category.
>
>>I'm not sure what you mean by "safer", but I you're more in tune with the
>>way log4j operates than I am. Would it make sense to not cache the logs
>>that are instances of Log4JCategoryLog?
>
>I was about to write that there was no need to cache instances Log4JCategoryLog but
>that is not necessarily true because you do not want multiple instances of
>Log4JCategoryLog lying around event if they wrap the exact same
>org.apache.log4j.Category instance.
>
>>What's not safe about the alternative? I typically store a static final reference
>to the log4j
>>Category anyway and that would seem to be more or less equivalent. Is there
>>some danger in that practice I'm not seeing?
>
>Yes and no. As long as there is no Category.remove operation you are safe. However,
>if and when Category.remove operation is introduced your wrapped category would be a
>dangling category living outside the normal hierarchy. As things stand today, there
>is no Category.remove operation and I don't think it would be introduced anytime
>soon. Regards, Ceki
>
>
>--
>Ceki G�lc� - http://qos.ch
--
Ceki G�lc� - http://qos.ch
