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

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

On Oct 25, 2009, at 16:48 , Konstantin Litvinenko wrote:

> Stephen Roderick пишет:
>> The reason I had to replace the default hierarchy maintainer is  
>> that I
>> need to build our own Category objects, which are derived from
>> log4cpp::Category. The easiest method up front was to copy/paste the
>> hierarchy maintainer and change just
>> HierarchyMaintainer::_getInstance. Do you have any recommendations on
>> how to do this in a better manner than just replacing the entire
>> class? Has anyone considered use of a Factory pattern, or something
>> similar?
>>
> Why do you need you own Category class? What is wrong with existing?

I need to add and additional capabilities to the category object, to  
provide one end of a real-time buffer.

>> I opted to change only LoggingEvent (and small amount of other
>> necessary code) to use the real-time allocatable strings, rather than
>> change all of log4cpp. This means that from a user point of view,  
>> they
>> really only see std::string. Does this seem reasonable?
> So you want to modify only core of log4cpp and write your own  
> appenders
> to do real-time friendly logging?

Actually, no. We derive from log4cpp::Category and extend it to use a  
buffer of log4cpp::LoggingEvent entries. Attached to this buffer are  
one or more Appender components, each of which contains an appender  
internally. The category side is real-time, the appender side is not.  
This is being integrated within a real-time robotics framework called  
Orocos (http://orocos.org/). Our Category object contains a reference  
to the real-time buffer, as well as overriding Category::callAppenders 
() to push to the port instead of directly calling the appenders. This  
provides the separation between the real-time and non-realtime parts  
of the system. Orocos deals with creating the ports and associating  
things correctly.

So with the changes I'm proposing, the hiearachy maintainer needs to  
create derived Category objects, and LoggingEvents must use a real- 
time allocator (based on TLSF) to be useable within the real-time,  
Category side of the system. Once everything is in the non-realtime  
part of the system (ie within appenders and layouts), we no longer  
care about real-time and can revert to std::string and the default  
(very non-realtime) memory allocator.

I hope this explains the situation better.

Cheers
Stephen