Some (more) questions about log4cpp and Orocos

Hello,

I read the documentation about the log4cpp [1], and I have some questions
about some other use cases.

- Can we use the orocos-port of log4cpp in an typical GUI application
without using the OCL::string and OCL::logging::Category ? I mean, does the
current port of log4cpp is "broken" for standard use of log4cpp?

- Let say we have our own deployment system, is there any non-RTT-intrusive
workaround to log from anywhere in the components (in constructor,
destructor, configureHook, ...) ?

Philippe

[1]
http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-...

Some (more) questions about log4cpp and Orocos

On Jan 19, 2011, at 10:44 , Philippe Hamelin wrote:

> Hello,
>
> I read the documentation about the log4cpp [1], and I have some questions about some other use cases.
>
> - Can we use the orocos-port of log4cpp in an typical GUI application without using the OCL::string and OCL::logging::Category ? I mean, does the current port of log4cpp is "broken" for standard use of log4cpp?

Yes, we do this. Same log4cpp (w/ Orocos patches) build. Use as normal log4cpp.

NB that if you pass OCL::Strings over ports from your deployer to your GUI, you need to init TLSF at the GUI also.

> - Let say we have our own deployment system, is there any non-RTT-intrusive workaround to log from anywhere in the components (in constructor, destructor, configureHook, ...) ?

Yes. How, depends on whether you want to keep realtime or not.

- without realtime, use log4cpp as normal (like a GUI).
- with realtime, make sure the LoggingService is up first. This ensures that the real-time/components side of log4cpp is up and ready. We put some patches into the OCL v1.x deployer to support group loading, which we use to do exactly this. We load/start the logging components in the first group, and then load/start the application components in the second group. The application components can use log4cpp+realtime anywhere then.You also need to make sure that you initialize TLSF & log4cpp _before_ loading the logging service. See the OCL deployer code (which I must submit some patches to simplify).

NB you _can_ use both the non-realtime and the realtime parts of log4cpp in the same class. You just need to obtain two categories - one which is a normal log4cpp category, and one which was created by the OCL::LoggingService and which supports real-time access. Using these two objects is the same, it is just what happens behind the scenes. Now _why_ you would want to do this is beyond me ...

I really need to put together a full example system demonstrating this ... Peter/Markus, did anything happen re the orocos-examples repository we spoke of a few weeks back? Some ML activity sounded like one of your students might have started down this track?

HTH
S

Some (more) questions about log4cpp and Orocos

2011/1/19 S Roderick <kiwi [dot] net [..] ...>

> On Jan 19, 2011, at 10:44 , Philippe Hamelin wrote:
>
> > Hello,
> >
> > I read the documentation about the log4cpp [1], and I have some questions
> about some other use cases.
> >
> > - Can we use the orocos-port of log4cpp in an typical GUI application
> without using the OCL::string and OCL::logging::Category ? I mean, does the
> current port of log4cpp is "broken" for standard use of log4cpp?
>
> Yes, we do this. Same log4cpp (w/ Orocos patches) build. Use as normal
> log4cpp.
>
> NB that if you pass OCL::Strings over ports from your deployer to your GUI,
> you need to init TLSF at the GUI also.
>
> > - Let say we have our own deployment system, is there any
> non-RTT-intrusive workaround to log from anywhere in the components (in
> constructor, destructor, configureHook, ...) ?
>
> Yes. How, depends on whether you want to keep realtime or not.
>
> - without realtime, use log4cpp as normal (like a GUI).
> - with realtime, make sure the LoggingService is up first. This ensures
> that the real-time/components side of log4cpp is up and ready. We put some
> patches into the OCL v1.x deployer to support group loading, which we use to
> do exactly this. We load/start the logging components in the first group,
> and then load/start the application components in the second group. The
> application components can use log4cpp+realtime anywhere then.You also need
> to make sure that you initialize TLSF & log4cpp _before_ loading the logging
> service. See the OCL deployer code (which I must submit some patches to
> simplify).
>
>
In GUI. we don't care about realtime so it's easier to use directly log4cpp.
However, when the GUI is linked with some Orocos component, it would be
natural to use the Logging service. However, I guess this will lead to two
log files (two appenders) ?

> NB you _can_ use both the non-realtime and the realtime parts of log4cpp in
> the same class. You just need to obtain two categories - one which is a
> normal log4cpp category, and one which was created by the
> OCL::LoggingService and which supports real-time access. Using these two
> objects is the same, it is just what happens behind the scenes. Now _why_
> you would want to do this is beyond me ...
>
>
Also, in that case, I guess they can't share the same appender?

> I really need to put together a full example system demonstrating this ...
> Peter/Markus, did anything happen re the orocos-examples repository we spoke
> of a few weeks back? Some ML activity sounded like one of your students
> might have started down this track?
>
>
That would be very helpful!

Some (more) questions about log4cpp and Orocos

On Jan 19, 2011, at 12:39 , Philippe Hamelin wrote:

> 2011/1/19 S Roderick <kiwi [dot] net [..] ...>
> On Jan 19, 2011, at 10:44 , Philippe Hamelin wrote:
>
> > Hello,
> >
> > I read the documentation about the log4cpp [1], and I have some questions about some other use cases.
> >
> > - Can we use the orocos-port of log4cpp in an typical GUI application without using the OCL::string and OCL::logging::Category ? I mean, does the current port of log4cpp is "broken" for standard use of log4cpp?
>
> Yes, we do this. Same log4cpp (w/ Orocos patches) build. Use as normal log4cpp.
>
> NB that if you pass OCL::Strings over ports from your deployer to your GUI, you need to init TLSF at the GUI also.
>
> > - Let say we have our own deployment system, is there any non-RTT-intrusive workaround to log from anywhere in the components (in constructor, destructor, configureHook, ...) ?
>
> Yes. How, depends on whether you want to keep realtime or not.
>
> - without realtime, use log4cpp as normal (like a GUI).
> - with realtime, make sure the LoggingService is up first. This ensures that the real-time/components side of log4cpp is up and ready. We put some patches into the OCL v1.x deployer to support group loading, which we use to do exactly this. We load/start the logging components in the first group, and then load/start the application components in the second group. The application components can use log4cpp+realtime anywhere then.You also need to make sure that you initialize TLSF & log4cpp _before_ loading the logging service. See the OCL deployer code (which I must submit some patches to simplify).
>
>
> In GUI. we don't care about realtime so it's easier to use directly log4cpp. However, when the GUI is linked with some Orocos component, it would be natural to use the Logging service. However, I guess this will lead to two log files (two appenders) ?

The LoggingService (in its current form) is only good for initial configuration of the log4cpp system based on the Orocos cpf file. After that, we never use it. Just go directly to log4cpp and get a category. I think you might be able to work this situation to use one log file, but I'd have to think it through some more.

Peter originally thought that we should add services to the LoggingService, to use it directly (think SM's and scripts). He's probably right about that. We just have had no use for it. And the RT consequences might be interesting in RTT v1.x ...

> NB you _can_ use both the non-realtime and the realtime parts of log4cpp in the same class. You just need to obtain two categories - one which is a normal log4cpp category, and one which was created by the OCL::LoggingService and which supports real-time access. Using these two objects is the same, it is just what happens behind the scenes. Now _why_ you would want to do this is beyond me ...
>
>
> Also, in that case, I guess they can't share the same appender?

Correct.

>
> I really need to put together a full example system demonstrating this ... Peter/Markus, did anything happen re the orocos-examples repository we spoke of a few weeks back? Some ML activity sounded like one of your students might have started down this track?
>
>
> That would be very helpful!

It's just a matter of finding the time ... and I'll wait a little to hear from Peter/Markus.
S