-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there,
the current way to get an instance of "Log" is using the LogFactory (getInstance(*) on the LogFactory instance). Actually this method performs caching of the "Log" instances so when you request a "Log" for the same name multiple times you will get the same instance as result. 1. A naive implementation of "getChildLogger" could simply use LogFactory.getLog(String) to construct the child logger what might cause confusion when the parent "Logger" instance was not created via the factory. But currently there is no way to see if the "Log" instance was created by the factory or not. 2. The other naive way is to directly create the child-logger instance via the Logger's implementation own String constructor. This solution would bypass the cache of the LogFactory. I think that version 1. is inacceptable. Version 2. would be okay but not elegant. The approach would underline that we will have two different approaches of how to use commons-logging: The current way where Log is enough and the "IoC" way where some container/framework will create an "initial" Logger and further loggers would be created via the "getChildLogger" method and injected to components, that themselves may create "child-child-loggers" via that method. The caching is not needed in this world, because it would be a design/code error if a logger with the same name is created multiple times. As I said going with version 2. is okay. Anyways I am still looking for the elegant solution 3. :) What I want to do is: Add a non-arg constructor to all Logger implementations that create the root logger instance. This constructor would be the one used by the IoC world (on suggestion via javadoc). Maybe I will store this information in a flag so I can decided how to create the instance returned by the "getChildLogger" method (e.g. choose between solution 1. or 2. according to the flag and copy the flag to the child instance). For the moment this is my solution 3. When I have a better idea I will let you know or you may let me know of your ideas... Further I was thinking that maybe even the other way round would be better - so the facotry would explicitly set the flag. But this might be tricky - for me it seems to be impossible without breaking compatibility with existing Log instances or doing very wired stuff. Additionally I will create an abstract implementation of the Logger Interface and extend this in all implementations instead of implementing the Interface (currently Log). This basic implementation can contain general code to prevent redundancies (e.g. the logic how to build the name of the child-logger). The (java)doc will tell NOT to directly implement the Log or Logger interface but extend that AbstractLogger class. This way we can easier add a new method to the Logger interface because we can have a default implementation in the AbstractLogger class for that method. So we do not break third-party code that we can not control. Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOvoNmPuec2Dcv/8RAn4fAJwIPXtgewaLIxPSjVoSkE0l+84MDgCfZx+3 ZModhpKea0NmKcHcKWNvIj4= =AdHH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
