Re: [Log4cpp-devel] Modifying log4cpp to support realtime systems

[S R. <kiw...@ma...>]

On Oct 26, 2009, at 09:10 , Konstantin Litvinenko wrote:

> 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");

Agreed.

> 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.

That is one option. Another option might be

     static HierarchyMaintainer* _defaultMaintainer=0;

     HierarchyMaintainer& HierarchyMaintainer::getDefaultMaintainer() {
         static HierarchyMaintainer defaultMaintainer;

	// use default maintainer if it is not already set
	if (! _defaultMaintainer)
		_defaultMaintainer = & defaultMaintainer;

         return *_defaultMaintainer;
     }

    void HierarchyMaintainer::setDefaultMaintainer 
(HierarchyMaintainer* d) {
	_defaultMaintainer = d;
    }

This allows the application to override the default maintainer  
programmatically.  Or is this a kind of  "static module initialization  
logic" that you are trying to avoid?
Stephen