> >However I wonder, to avoid Logger subclassing, why not make it final? > >But it was just a thought... > > Logger class is not final because Logger sub-classing allows very > important enhancements such as security or transparent logging domains. > Domains are a "secret" feature planned for log4j 1.3. > > The important point to note is that these sub-classes do not change > the Logger interface, that is the set of methods available to the > user. Sub-classing Logger by adding new logging methods is strongly > discouraged because code written for such loggers will simply not run > in environments where the enhanced Logger sub-classes are used. (I am > thinking of Application Servers and Servlet Containers.) > > Does it make any sense?
I'm missing the point. Code will run fine anyway. This is java, not C++ and (dynamic) linking is done at runtime, not at compiletime. If I extend from Logger class, e.g. MyLogger, code referring to MyLogger methods will run fine with log4j 1.999 version in which there will be a EnanchedLogger class extending from Logger. If you want to preserve public interface, you can (must) use java Interface concept. If you want to make new improvements and make it available to users, you can (must) extend your old interface. Application written for old interface are preserved and will runs fine: backward compatibility is granted. Who wants to use new enanchements will refer to new Interface. Best regards, Giuseppe. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
