>At 06:51 PM 11/30/2004, Jacob Kjome wrote:
>
>>I don't have the code to look at right now, so let me see if I'm understanding
>>you. You are suggesting that we can eat our cake and have it too. If the
>>passed in selector doesn't have the default repository set for it, then we
>>would fall back to the existing default repository (Hierarchy) from the
>>default
>>selector. If this is what you are saying, then yes, I concur.
>
>I made small changes to the RepositorySelector interface and to LogManager
>as discussed in my previous message. It should all work as expected.
>
Hi Ceki,
Unfortunately, I think you are still missing my point. The changes to the RepositorySelector interface are good. The change to the LogManager is a bit mysterious. I guess it is trying to protect against overriding the default logger repository of custom selectors which initiate a default repository in their constructor? Because that's the only way the default repository would actually exist in selectors instantiated within the static initialization code of LogManager. I guess that might be a legitimate check? Can't hurt either way. However, it doesn't address my original point at all, though I can use the same code change from the static initialization code within the LogManager.setRepositorySelector() for the same effect there, which is what I was trying to point out in the first place. To make it abundantly clear what I am talking about, look at the change I just committed. I'm positive this is correct and it fixes all the null pointers which, BTW, cause all apps in Tomcat to cease to work. It is clearly the right thing to do. If you really disagree, you can always back it out, but I can't see why you would want to.
Bottom line is that external initializing code should never ever be able to bring down every app in the server by simply forgetting to set a default logger repository on the custom selector. We shouldn't override a default logger repository that has been set, but we should definitely make sure it doesn't stay null if it wasn't set. And the default repository of choice is the same one that was on the previous selector. That way, the transition is seamless. Anyway, take a look, and try this under Tomcat-5.5.4, not Tomcat-5.0.xx. Also, the problem would never show itself if you started up by passing the selector name in via the -D parameter on the command line. It would only occur in the case where the default selector was being used and then some initializer code called LogManager.setRepositorySelector().
Jake
>
>--
>Ceki G�lc�
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
