DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32536>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32536 ------- Additional Comments From [EMAIL PROTECTED] 2004-12-06 07:08 ------- I still think 2 is probably fine as a backstop, but I'm not sure I'd call preventing a NullPointerException an "imposition" as you described in proposal #1. To me, its expected behavior. After all, if the original default repository was configured with the user's full intention (by providing a config file in the classpath) that it be used for logging, why wouldn't they want it to continue to be used for logging? Why would we assume that they chose to discard it? I would think the act of providing a repository that isn't the current default would be the *only* way to "imply" intention for discarding the current repository. In fact, anything else should be considered an unexpected "side effect". Only true intention should change the existing default repository. Ceki has spoken about "side effects" and that we don't want to have hidden behavior that the user ends up counting on, but then changes as Log4j is redesigned or some other related aspect changes. The argument is valid, in principal. However, strict adherence to this is impractical. Imagine all the "side effects" Log4j, or any other piece of software, has right now. Imagine if we removed all these "side effects" and imposed them on the user. These types of "side effects" are better termed as "common sense, predictable defaults". I don't see why the current situation is any different. Proposal #1 is a common sense, predictable default. Speaking of "side effects", how's this for one? If things stay the way they are now and one wishes to attempt a transfer of the current default logger repository to a new selector to be istalled, there is no guarantee that the logger repository the user attempts to obtain will be that of the current default logger repository. Why you ask? Note the sample code below... RepositorySelector repositorySelector = new MyRepositorySelector(); repositorySelector.setDefaultRepository(LogManager.getLoggerRepository()); LogManager.setRepositorySelector(repositorySelector, new Object()); There's an assumption here that LogManager.getLoggerRepository() will return the current default logger repository. However, that is entirely up to the currently installed repository selector. The assumption holds true in the case of the DefaultRepositorySelector which only has one logger repository, the default. However, what if at some future date, we chose a different default selector such as a ContextClassLoaderSelector (unlikely) or the ContextJNDISelector (very possible)? LogManager.getLoggerRepository() would return the logger repository for the current context, not the default. Talk about "side effects". This one makes my proposal look entirely non-controversial. Of course we can fix this by providing another method on the LogManager class such as LogManager.getDefaultRepository() which, instead of this... public static LoggerRepository getLoggerRepository() { return repositorySelector.getLoggerRepository(); } would look like this... public static LoggerRepository getDefaultRepository() { return repositorySelector.getDefaultRepository(); } With that change, I'm done with this argument. I still think a good common-sense non-NullPointerException-causing default is perfectly fine and desireable, but I'd settle for being required to set it manually if I can actually have a guarantee that the logger repository I am retrieving from the existing respository selector is exactly what I expect it to be. This is impossible to know with certainty unless the LogManager.getDefaultRepository() method is added. I'll let everyone else hash out whether null pointers should be caught and rethrown with a clear message as a RuntimeException. Jake -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
