log4cpp-devel — technical discussions about the development of log4cpp

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

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

On Oct 26, 2009, at 13:35 , S Roderick wrote:

> On Oct 26, 2009, at 13:09 , Konstantin Litvinenko wrote:
>
>> On 26.10.2009 15:43, S Roderick wrote:
>> [.........huge skip.........]
>> Roderick, I understand all your wishes and can propose followed
>> solution:
>>
>> 1. We add ability to set up creator for categories in
>> HierarchyMaintainer
>> 2. You write you own RTCategory that derived from log4cpp Category
>> and meet all your requirements -
>> you hide from usage all functions that receive std::strings and
>> expose those that receive rt_strings.
>> 3. To use log4cpp in usual manner user should setup default creator
>> as RTCategory creator and do
>> following when obtaining reference on RTCategory:
>>
>> class foo
>> {
>>   public:
>>     foo() :
>> logger_
>> (static_cast<RTCategory&>(log4cpp::Category::getInstance("foo")))
>>     {
>>     }
>>
>>   private:
>>     RTCategory& logger_;
>> };
>>
>> Please, comment this.
>
> This all sounds reasonable, but let me look at it some more.
>
>> As for rt allocator in HierarchyMaintainer that is really hard and
>> likely impossible, because I
>> don't know how to rewrite HierarchyMaintainer::_getInstance in a way
>> that it become rt. It uses
>> std::string and I see no way how to avoid std::string creation...
>
> Fair enough.
>
> Thanks!
> Stephen

How do the two attached patches look to you? The first patch provides  
1) above, while the second patch is needed for some of the other points.

Let me know what you think and what you would like to see changed.

Thanks
Stephen

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

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

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

> On 26.10.2009 15:43, S Roderick wrote:
> [.........huge skip.........]
> Roderick, I understand all your wishes and can propose followed  
> solution:
>
> 1. We add ability to set up creator for categories in  
> HierarchyMaintainer
> 2. You write you own RTCategory that derived from log4cpp Category  
> and meet all your requirements -
> you hide from usage all functions that receive std::strings and  
> expose those that receive rt_strings.
> 3. To use log4cpp in usual manner user should setup default creator  
> as RTCategory creator and do
> following when obtaining reference on RTCategory:
>
> class foo
> {
>    public:
>      foo() :  
> logger_ 
> (static_cast<RTCategory&>(log4cpp::Category::getInstance("foo")))
>      {
>      }
>
>    private:
>      RTCategory& logger_;
> };
>
> Please, comment this.

This all sounds reasonable, but let me look at it some more.

> As for rt allocator in HierarchyMaintainer that is really hard and  
> likely impossible, because I
> don't know how to rewrite HierarchyMaintainer::_getInstance in a way  
> that it become rt. It uses
> std::string and I see no way how to avoid std::string creation...

Fair enough.

Thanks!
Stephen

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

[Konstantin L. <to....@gm...>]

On 26.10.2009 15:43, S Roderick wrote:
[.........huge skip.........]
Roderick, I understand all your wishes and can propose followed solution:

1. We add ability to set up creator for categories in HierarchyMaintainer
2. You write you own RTCategory that derived from log4cpp Category and meet all your requirements - 
you hide from usage all functions that receive std::strings and expose those that receive rt_strings.
3. To use log4cpp in usual manner user should setup default creator as RTCategory creator and do 
following when obtaining reference on RTCategory:

class foo
{
    public:
      foo() : logger_(static_cast<RTCategory&>(log4cpp::Category::getInstance("foo")))
      {
      }

    private:
      RTCategory& logger_;
};

Please, comment this.

As for rt allocator in HierarchyMaintainer that is really hard and likely impossible, because I 
don't know how to rewrite HierarchyMaintainer::_getInstance in a way that it become rt. It uses 
std::string and I see no way how to avoid std::string creation...

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

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

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

> On 26.10.2009 14:49, S Roderick wrote:
>
>>> 3. Collect all events (not LogingEvents) in a rt buffer and send  
>>> they
>>> into a sink - serialize and send to socket for example.
>>> 4. On other side of sink you may have some listener that receive,
>>> deserialize and invoke log4cpp with preconfigured nonrt
>>> categories/appenders to do real logging.
>>
>> We actually just send LoggingEvents through the buffer. What  
>> benefit do
>> you see with sending events that are not LoggingEvents? Aren't they
>> going to contain the same data?
>
>    Can you tell me more about 'send LoggingEvents through the buffer'.
> From my point of view to decouple rt part from non-rt you should send
> these event away from rt part in rt manner. Than you should receive it
> in non-rt agent and replay.

Below is the function in the derived RTCategory class. It uses a  
log4cpp::LoggingEvent that has rt_string instances, instead of  
std::string. The "log_port" object is a reference to a real-time  
buffer of log4cpp::LoggingEvent instances, which is implemented and  
managed by Orocos. This port has already been setup during the non- 
realtime configuration part of the application.

void Category::callAppenders(const log4cpp::LoggingEvent& event) throw()
{
     if (log_port.ready())
     {
         log_port.Push(event);
     }

     // let our parent categories append
     if (getAdditivity() && (getParent() != NULL)) {
         getParent()->callAppenders(event);
     }
}

This is completely hard real-time as long as a) LoggingEvent uses  
rt_string, and b) you don't run out of memory (which is an entirely  
separate discussion we're having at the Orocos project). But  
fundamentally, the real-time-ness of the above is provided by Orocos,  
as long as a) holds.

>> As part of this, you would need to
>> completely override all the logging functions in RTCategory to take
>> rt_string objects instead of std::string.
>
> No, you shouldn't.

Well, yes and no. All calls that end up in the above  
Category::callAppenders() function that can be called from real-time,  
must _not_ use std::string. So I think you have to change all  
log4cpp::Category functions that end up calling
logUnconditionally2(), to take rt_string instead of std::string.

>
>> It seems like we would be
>> completely replacing the Category and LoggingEvent classes, where as
>> with my current implementation we build a slightly different
>> LoggingEvent class, and we override just a couple of functions in the
>> RTCategory class. One of my primary aims going in to this was to  
>> reuse
>> as much of log4cpp as possible.
>
> You need to override only one function - _logUnconditionally2 because
> all other logging functions uses only this one to actually log  
> something.


Like I said earlier, my intent was to reuse as much of log4cpp as  
possible, rather than ending up writing my own. So I opted to put the  
Category and logging functions in the real-time part of the system,  
and everything else (ie appenders and layouts) in the non-RT part. I  
use Orocos' existing real-time buffers in between the two parts. A  
log4cpp::appender lives inside an Orocos::Appender, which manages  
taking data off the buffer and giving it to the log4cpp::appender. The  
user's RT code logs on categories just like normal.

Consequences of this

1) LoggingEvent uses rt_string instead of std::string (to support a)  
above)

2) all log4cpp Category functions used to log must take rt_strings  
instead of std::strings. This also means that logUnconditionally() and  
logUnconditionally2() take rt_strings.

3) the user application must create all categories at the start of  
runtime. They can not be created on the fly (unless we further modify  
HierarchyMaintainer to use a std::map with a real-time allocator -  
quite doable, but I wanted to avoid that, if possible). This  
constraint is overall not a big deal (IMHO) to real-time users, as we  
are used to pre-allocating anything anyway.

Hope this helps
Stephen

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

[Konstantin L. <to....@gm...>]

On 26.10.2009 15:20, S Roderick wrote:

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

  This way is actually the same as I propose except its for 
HierarchyMaintainer. And no, you can't solve my problem in any other way 
  except directly specify what exactly category object you need. There 
is no way to install some function that will be invoked before any 
static object initialization to initialize _defaultMaintainer.
And I think you don't need to replace HierarchyMaintainer. You only need 
  to add ability to create you Category objects on requests and this can 
be accomplished in the way I wrote in previous post.

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

[Konstantin L. <to....@gm...>]

On 26.10.2009 14:49, S Roderick wrote:

>> 3. Collect all events (not LogingEvents) in a rt buffer and send they
>> into a sink - serialize and send to socket for example.
>> 4. On other side of sink you may have some listener that receive,
>> deserialize and invoke log4cpp with preconfigured nonrt
>> categories/appenders to do real logging.
> 
> We actually just send LoggingEvents through the buffer. What benefit do 
> you see with sending events that are not LoggingEvents? Aren't they 
> going to contain the same data? 

    Can you tell me more about 'send LoggingEvents through the buffer'. 
 From my point of view to decouple rt part from non-rt you should send 
these event away from rt part in rt manner. Than you should receive it 
in non-rt agent and replay.

> As part of this, you would need to 
> completely override all the logging functions in RTCategory to take 
> rt_string objects instead of std::string.

No, you shouldn't.

> It seems like we would be 
> completely replacing the Category and LoggingEvent classes, where as 
> with my current implementation we build a slightly different 
> LoggingEvent class, and we override just a couple of functions in the 
> RTCategory class. One of my primary aims going in to this was to reuse 
> as much of log4cpp as possible.

You need to override only one function - _logUnconditionally2 because 
all other logging functions uses only this one to actually log something.

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

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

[Konstantin L. <to....@gm...>]

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?

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

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

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

> S Roderick пишет:
>> 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.
> Yes. Thanx.
> If I correctly understand all you wishes you need to collect and send
> all logging events into some sink in real-time manner. So base on  
> this I
> propose next steps:
> 1. Create RT Category class.

This is what we've done, but I doubt that you want an Orocos-specific  
class inside log4cpp?

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

> 3. Collect all events (not LogingEvents) in a rt buffer and send they
> into a sink - serialize and send to socket for example.
> 4. On other side of sink you may have some listener that receive,
> deserialize and invoke log4cpp with preconfigured nonrt
> categories/appenders to do real logging.

We actually just send LoggingEvents through the buffer. What benefit  
do you see with sending events that are not LoggingEvents? Aren't they  
going to contain the same data? As part of this, you would need to  
completely override all the logging functions in RTCategory to take  
rt_string objects instead of std::string. It seems like we would be  
completely replacing the Category and LoggingEvent classes, where as  
with my current implementation we build a slightly different  
LoggingEvent class, and we override just a couple of functions in the  
RTCategory class. One of my primary aims going in to this was to reuse  
as much of log4cpp as possible.

> To do all this work you don't need to modify LoggingEvent, because you
> may use whatever logging event container you need in RTCategory - it  
> is
> fully internal class in this context.

I understand what you are suggesting, I just don't see the benefits.  
Are you primarily hoping for the user to avoid building different  
versions of log4cpp (ie with or without a LoggingEvent class that uses  
rt_string)?

Thanks
Stephen

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

[Konstantin L. <to....@gm...>]

S Roderick пишет:
> 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.
Yes. Thanx.
If I correctly understand all you wishes you need to collect and send 
all logging events into some sink in real-time manner. So base on this I 
propose next steps:
1. Create RT Category class.
2. Instruct somehow log4cpp to create RTCategory in HierarchyMaintainer .
3. Collect all events (not LogingEvents) in a rt buffer and send they 
into a sink - serialize and send to socket for example.
4. On other side of sink you may have some listener that receive, 
deserialize and invoke log4cpp with preconfigured nonrt 
categories/appenders to do real logging.

To do all this work you don't need to modify LoggingEvent, because you 
may use whatever logging event container you need in RTCategory - it is 
fully internal class in this context.

If my understanding and propositions is right we will move forward.

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

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

[Konstantin L. <to....@gm...>]

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

[Log4cpp-devel] Modifying log4cpp to support realtime systems

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

As previously noted in a feature request on sourceforge, I am  
interested in modifying log4cpp to be useable within real-time  
systems. I have made a series of preliminary changes to support this,  
and I wanted to start working with the log4cpp developers to see best  
how to fit these changes in.

Primarily, I had to remove the default hierarchy maintainer, and  
change LoggingEvent to use std::string variants that used a O(1)  
memory allocator. There were also some other minor build system  
changes required.

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?

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?

I've tested the changes under Mac OS X Snow Leopard and Ubuntu Jaunty.

Cheers
Stephen

Re: [Log4cpp-devel] Task manager permissions

[Thomas W. <tho...@ho...>]

Hi,

i have changed your permissions ... hope you can now work again without
problems ;-) ... hope your sf account name is dark--angel?

If not drop me a mail with your sf account name.

Cheers,

-- waffel

Konstantin Litvinenko schrieb:
> Hi All!
> 
>  Please, change my permissions for Task Manager to Technician to allow 
> me close/manage bugs/patches/feature requests. I want push project 
> further but unable to do it withou*t it.
> *
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Task manager permissions

[Konstantin L. <to....@gm...>]

Hi All!

 Please, change my permissions for Task Manager to Technician to allow 
me close/manage bugs/patches/feature requests. I want push project 
further but unable to do it withou*t it.
*

Re: [Log4cpp-devel] Logging Time in UTC/GMT timezone

[Konstantin L. <to....@gm...>]

ankit tandon пишет:
> Hi All ,
> Currently is there any way to print the timestamps/dates in log4cpp 
> converted to GMT/UTC timezone. I read somewhere that using "%d" prints 
> the date in UTC but we are still getting our local system (US) time. 
> Any help regarding this will be deeply appreciated.
>
No, there is no way to print UTC time using PatternLayout. But you can 
write your own appender that will print UTC timestamps/date.

[Log4cpp-devel] Logging Time in UTC/GMT timezone

[ankit t. <ank...@ya...>]

Hi All ,
     Currently is there any way to print the timestamps/dates in log4cpp  converted to GMT/UTC timezone. I read somewhere that using "%d" prints the date in UTC  but we are still getting our local system (US) time. Any help regarding this will be deeply appreciated.
  
Thanks
Ankit



      

Re: [Log4cpp-devel] log4cpp thread safety

[Konstantin L. <1da...@ma...>]

Hello, FROHNER!
You wrote to <log...@li...> on Thu, 25 Sep 2008 
16:53:07 +0300:

 FA> We are using log4cpp in our project and we have some multi-threaded
 FA> services. Hence we are very happy with the thread safety improvements
 FA> of v1.0, however there are still a few areas, where static variables
 FA> are used without explicit locking:

 FA> AppendersFactory& AppendersFactory::getInstance()
 FA> LayoutsFactory& LayoutsFactory::getInstance()
 FA> TriggeringEventEvaluatorFactory& 
TriggeringEventEvaluatorFactory::getInstance()

 FA> Could they not cause any problem if they are ran in a multi-threaded
 FA> environment, where the statements might interleave?

        Hm.... Yes, they definitly will cause race problems if they run in 
concurence. If you make any concurent call to AppendersFactory, 
LayoutsFactory or TriggeringEventEvaluatorFactory you will hit a race 
condition. The only reason why this part is not protected by mutex is that I 
have never configure/reconfigure log4cpp in multi-thread enviroment. We 
configure first, than run threads. If you do the same, than you will not 
have any problems.
        Anyway I will address this issue in main line soon.

With best regards, Konstantin Litvinenko. 

[Log4cpp-devel] log4cpp thread safety

[FROHNER A. <Ako...@ce...>]

Hi,

We are using log4cpp in our project and we have some multi-threaded
services. Hence we are very happy with the thread safety improvements
of v1.0, however there are still a few areas, where static variables
are used without explicit locking:

AppendersFactory& AppendersFactory::getInstance()
LayoutsFactory& LayoutsFactory::getInstance()
TriggeringEventEvaluatorFactory& TriggeringEventEvaluatorFactory::getInstance()

Could they not cause any problem if they are ran in a multi-threaded
environment, where the statements might interleave?

Cheers,
    Ákos
-- 
FROHNER Ákos/DM/IT/CERN -- Data Management/JRA1/EGEE

Re: [Log4cpp-devel] is this project in progress?

[Konstantin L. <Kon...@ma...>]

Hello, somayeh!
You wrote to <log...@li...> on Sat, 13 Sep 2008 
01:15:36 -0700 (PDT):

 sb> i am a new user in log4cpp and i want to know if this
 sb> is an in progress project or not?

What kind of progress do you expect?

With best regards, Konstantin Litvinenko. 

[Log4cpp-devel] is this project in progress?

[somayeh b. <s.b...@ya...>]

hi

i am a new user in log4cpp and i want to know if this
is an in progress project or not?

thanks a lot
s.bakhshaei



      

[Log4cpp-devel] Best dave suggestion

[claiborn e. <gem...@gs...>]

 look, pills todays best solution check out here

[Log4cpp-devel] Best gallagher suggestion

[abie g. <ed...@wh...>]

 try,  medication  overnite check out here

Re: [Log4cpp-devel] How to enable console output ?

[Andy <hew...@gm...>]

Sorry...everybody
 After I restart the system, it becomes OK.......
My God.....




2008/5/21 Andy <hew...@gm...>:
> 2008/5/21 Konstantin Litvinenko <Kon...@ma...>:
>> Hello, Andy!
>> You wrote to <log...@li...> on Mon, 19 May 2008
>> 20:38:37 +0800:
>>
>>
>>  A> after I call init(), then I write this:
>>
>>  A> loggg.debug(" Hello, log4cpp!");
>>
>>    On Windows this code works as expected
>>
>> #include <log4cpp/Category.hh>
>> #include <log4cpp/PropertyConfigurator.hh>
>> #include <iostream>
>>
>> log4cpp::Category& loggg =
>> log4cpp::Category::getInstance(std::string("mylog"));
>>
>> void init()
>> {
>>
>>  try
>>  {
>>   log4cpp::PropertyConfigurator::configure("log4cpp.properties");
>>  }
>>  catch (log4cpp::ConfigureFailure & f)
>>  {
>>   std::cerr << "configure problem " << f.what() << std::endl;
>>  }
>>
>> }
>>
>> int main()
>> {
>>   init();
>>   loggg.debug(" Hello, log4cpp!");
>>   return 0;
>> }
>>
>> Print out:
>>
>> 2008-05-21 08:30:38,718 [DEBUG][3476] :  Hello, log4cpp!
>> 2008-05-21 08:30:38,718 [DEBUG][3476] :  Hello, log4cpp!
>>
>> What log4cpp version, compiler version, OS do you use?
>
> OS:
> [root@localhost MSCA]# uname -a
> Linux localhost.localdomain 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005
> i686 i686 i386 GNU/Linux
>
> log4cpp:  log4cpp-1.0
>
> And I ssh to the computer  with SSH SECURE SHELL,  is this a problem ?
>
> Thanks  so  much.
>
>
>>
>> With best regards, Konstantin Litvinenko.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Log4cpp-devel mailing list
>> Log...@li...
>> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>>
>

Re: [Log4cpp-devel] How to enable console output ?

[Andy <hew...@gm...>]

2008/5/21 Konstantin Litvinenko <Kon...@ma...>:
> Hello, Andy!
> You wrote to <log...@li...> on Mon, 19 May 2008
> 20:38:37 +0800:
>
>
>  A> after I call init(), then I write this:
>
>  A> loggg.debug(" Hello, log4cpp!");
>
>    On Windows this code works as expected
>
> #include <log4cpp/Category.hh>
> #include <log4cpp/PropertyConfigurator.hh>
> #include <iostream>
>
> log4cpp::Category& loggg =
> log4cpp::Category::getInstance(std::string("mylog"));
>
> void init()
> {
>
>  try
>  {
>   log4cpp::PropertyConfigurator::configure("log4cpp.properties");
>  }
>  catch (log4cpp::ConfigureFailure & f)
>  {
>   std::cerr << "configure problem " << f.what() << std::endl;
>  }
>
> }
>
> int main()
> {
>   init();
>   loggg.debug(" Hello, log4cpp!");
>   return 0;
> }
>
> Print out:
>
> 2008-05-21 08:30:38,718 [DEBUG][3476] :  Hello, log4cpp!
> 2008-05-21 08:30:38,718 [DEBUG][3476] :  Hello, log4cpp!
>
> What log4cpp version, compiler version, OS do you use?

OS:
[root@localhost MSCA]# uname -a
Linux localhost.localdomain 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005
i686 i686 i386 GNU/Linux

log4cpp:  log4cpp-1.0

And I ssh to the computer  with SSH SECURE SHELL,  is this a problem ?

Thanks  so  much.


>
> With best regards, Konstantin Litvinenko.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>