Vadim Nasardinov writes: > On Thursday 18 August 2005 18:07, Florent BENOIT wrote: > > I applied the change (+ some doc) in the current CVS head of > > Monolog. > > The patch is a tad suboptimal. > > http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/monolog/monolog/src/org/objectweb/util/monolog/wrapper/javaLog/LoggerFactory.java.diff?r1=1.12&r2=1.13 > > > The reason java.util.logging.LogManager only keeps weak references to > the loggers it manages is in order to avoid a resource leak. If the > application chooses not to retain a hard reference to a logger, then > the LogManager should not prevent the unneeded logger from getting > GC-ed. Makes sense. > > The exact same logic applies to Monolog's LoggerFactory. It should > not keep hard references to loggers it creates. It is up to the > calling application to retain a reference if the app wishes to avoid > the cost of creating a new logger instance every time it needs one. > > Where does that leave us? Andrew ran into the above problem in an old > version of Carol. Recent versions do not have this problem for the > simple reason that Carol no longer uses Monolog. It's been > Monolog-free since March 15 (good job, Florent!): > > http://www.objectweb.org/wws/arc/carol-commits/2005-03/msg00078.html > > However, if we want to patch Monolog for those remaining parts of > Jonas that continue to depend on it, then someone should take a closer > look at whether or not the following class should be responsible for > retaining hard references to loggers it creates: > > org.objectweb.util.monolog.file.monolog.PropertiesConfAccess > > This responsibility should most certainly not be born by the > LoggerFactory class. I don't think that makes sense, because PropertiesConfAccess might well die before the clients call LoggerFactory.getLogger(). The method getLoggerFactory() calls PropertiesConfAccess.load(), which does new PropertiesConfAccess().read(prop, mf, mf, mf); so, the instance of PropertiesConfAccess is dead even before the method LoggerFactory.getLogger() returns. Andrew.
