From: Konstantin L. <to....@gm...> - 2009-10-26 13:10:25
|
On 26.10.2009 14:49, S Roderick wrote: >> 1. Create RT Category class. > > This is what we've done, but I doubt that you want an Orocos-specific class inside log4cpp? > :) Yes, we don't need that in log4cpp core. >> 2. Instruct somehow log4cpp to create RTCategory in HierarchyMaintainer . > > Yes! This is what I'm trying to figure out the best way to do it. It > would be nice to come up with a general method to do this for any > derived Category class, so that other projects can add functionality > that they might need. This led me to thoughts of a factory class to > create Category objects, or some way to override the default > HierarchyMaintainer instance at runtime. Ok. Than lets consider possible ways to do this. Main usage patter I use is: #include <log4cpp/Category.hh> static log4cpp::Category& logger = log4cpp::Category::getInstance("foo.bar"); So, if we add to HierarchyMaintainer additional methods: void set_category_factory(creator_function_t creator_function) { creator_function_ = creator_function; } std::auto_ptr<Category> make_category() { return creator_function(); } to setup and use some factory, we wan't be able use RTCategory in above use-case, except if we modify Category::getInstance to allow this: static log4cpp::Category& logger = log4cpp::Category::getInstance("foo.bar", "RTCategory"); where second parameter will be category type name, and HierarchyMaintainer will create specific Category object based on that name. If usage pattern do not involve static module initialization logic than proposed extension will allow users to have their own specific Category objects. What do you think? |