From: <log...@li...> - 2015-01-09 19:01:49
|
Hello Sorin, Thank you for your deep considerations. I agree that the graceful shutdown is missing in the library, though as weak excuse it is really rarely applied. Your a) seems pretty reasonable, I just have to check if it may cause any unexpected consequences. DeleteAllCategories call could be made public, it is just that categories and appenders are interconnected via pointers and therefore it probably will be better to have cleanup method that will take care of them both. Appenders might be shared. And not only at the instantiation time after reading properties file, but programmatically later too. The log4cpp lib does not make use of smart pointers, and it is not easy to determine whether particular appender is shared. I will dedicate some time to investigate it further, but if you have something already, please share your findings too. Regards, Alexander On Jan 8, 2015 2:13 PM, <log...@li...> wrote: > Hello, > > I would like to be able to initialise log4cpp from a properties file, to > shut it down, to reinitialise it from another properties file etc. > > In my opinion, there are two problems with this approach: > > 1. Leaking Appenders: The Appenders are not owned by the Categories when > the log system is initialised from a properties file. Therefore > Category::shutdown does neither close nor destroy the Appenders. I could > close them with Appender::closeAll but not destroy them. > > I could work around this problem by calling > Category::getCurrentCategories() and then for each Category > getAllAppenders() and then I destroy every Appender that is not owned by > the Category. This works if the system is initialised exclusively from > properties file as no Appender is owned by any Category. If, however, > one Appender was owned by one Category, but not by another, then I would > run the risk to destroy an Appender twice, once by my code and once by > the destructor of the Category that owns it. > > 2. Leaking Categories: I could destroy all Categories by calling > HierarchyMaintainer::deleteAllCategories(). One problem is that > HierarchyMaintainer is an internal class, as the comments say, so I > should not use it. Another problem is that deleteAllCategories() > destroys the Categories in _categoryMap but does not clear the map. > Thus, when the HierarchyMaintainer is destroyed automatically upon > program exit the HierarchyMaintainer destructor attempts to destroy the > already destroyed Categories and I get a segfault. > > I could work around this problem by implementing a > log4cpp::Log4cppCleanup class (exploiting the "friend class > Log4cppCleanup" feature in HierarchyMaintainer) and setting a shutdown > handler (HierarchyMaintainer::register_shutdown_handler) that executes > HierarchyMaintainer::_categoryMap.clear(). > > So all in all I get the behaviour I want, but I have the feeling of > forcing the lib. > > I would have preferred > > a) that deleteAllCategories cleared the _categoryMap. I think this is a > bug. > > b) that deleteAllCategories was exported via a call to Category. > > c) that there was a straightforward way to destroy all Appenders that > are not owned by the Categories. > > Best regards, > Sorin > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Log4cpp-devel mailing list > Log...@li... > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel > |