Problems with LUA ( logger properties & load components)

Dear friends,

I try to use LUA scripting in order to execute some tests, but I found two problems:

1.- LOGGER:

On my LUA script I have:

 -- LOGGING CONFIGURATION -- --- ---
 
depl:loadComponent("AppenderA", "OCL::logging::FileAppender")
depl:loadComponent("LoggingService", "OCL::logging::LoggingService")
 
depl:setActivity("AppenderA", 0.5, 0, 0)
depl:setActivity("LoggingService", 0.5, 0, 0)
 
aa = depl:getPeer("AppenderA")
ls = depl:getPeer("LoggingService")
 
depl:addPeer("AppenderA","LoggingService")
 
depl:loadService("LoggingService","marshalling")
ls:provides("marshalling"):loadProperties("/development/apps/ugv/core/commands/test.cpf")
 
aa:configure()
ls:configure()
aa:start()
ls:start()

but when execute the script, it has a problem with it:

OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
0.082 [ ERROR  ][TinyDemarshaller] Could not load /development/apps/ugv/core/commands/test.cpf Error: Error document empty.
0.082 [ ERROR  ][PropertyLoader:load] Some error occured while parsing /development/apps/ugv/core/commands/test.cpf

I can't understant the reason of the Empty document because the file has inside:

# root category logs to application (this level is also the default for all 
# categories who's level is NOT explicitly set in this file)
log4j.rootCategory=DEBUG, AppenderFile
 
# orocos setup
log4j.category.org.orocos.rtt=INFO, AppenderFile
log4j.additivity.org.orocos.rtt=false   # do not also log to parent categories
 
# application setup
log4j.category.org.me=INFO, AppenderFile
log4j.additivity.org.me=false         # do not also log to parent categories
 
log4j.category.org.command=DEBUG
 
log4j.appender.applicationAppender=org.apache.log4j.FileAppender
log4j.appender.applicationAppender.fileName=log/Command.log
log4j.appender.applicationAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.applicationAppender.layout.ConversionPattern=%d{%Y%m%dT%T.%l} [%-5p] %c %m%n

2.- LOADING COMPONENT

I try to load the component, it was loaded correctly if I use XML configuration files or Orocos Scripting, but when I use the next source the rttlua has an execption as "segmentation fault"

depl:path("/media/DATA/orocos-toolchain/install/lib/orocos/gnulinux/orocos/compRF")
depl:import("compRF")
depl:loadComponent("cRF","ugv::drivers::CompRF")

Any ideas? Thanks in advance

Problems with LUA ( logger properties & load components)

Hi Antonio,

On Thu, Nov 24, 2011 at 04:28:30PM +0100, antonio [dot] castellon [..] ... wrote:
>
> I try to use LUA scripting in order to execute some tests, but I found two
> problems:
>
> 1.- LOGGER:
>
> On my LUA script I have:
>
>
>
> -- LOGGING CONFIGURATION -- --- ---
>
> depl:loadComponent("AppenderA", "OCL::logging::FileAppender")
> depl:loadComponent("LoggingService", "OCL::logging::LoggingService")
>
> depl:setActivity("AppenderA", 0.5, 0, 0)
> depl:setActivity("LoggingService", 0.5, 0, 0)
>
> aa = depl:getPeer("AppenderA")
> ls = depl:getPeer("LoggingService")
>
> depl:addPeer("AppenderA","LoggingService")
>
> depl:loadService("LoggingService","marshalling")
> ls:provides("marshalling"):loadProperties("/development/apps/ugv/core/commands/test.cpf")
>
> aa:configure()
> ls:configure()
> aa:start()
> ls:start()
>
>
>
> but when execute the script, it has a problem with it:
>
>
>
> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> 0.082 [ ERROR ][TinyDemarshaller] Could not load
> /development/apps/ugv/core/commands/test.cpf Error: Error document empty.
> 0.082 [ ERROR ][PropertyLoader:load] Some error occured while parsing
> /development/apps/ugv/core/commands/test.cpf
>
>
>
> I can't understant the reason of the Empty document because the file has
> inside:
>
>
>
> # root category logs to application (this level is also the default for all
> # categories who's level is NOT explicitly set in this file)
> log4j.rootCategory=DEBUG, AppenderFile
>
> # orocos setup
> log4j.category.org.orocos.rtt=INFO, AppenderFile
> log4j.additivity.org.orocos.rtt=false # do not also log to parent
> categories
>
> # application setup
> log4j.category.org.me=INFO, AppenderFile
> log4j.additivity.org.me=false # do not also log to parent categories
>
> log4j.category.org.command=DEBUG
>
> log4j.appender.applicationAppender=org.apache.log4j.FileAppender
> log4j.appender.applicationAppender.fileName=log/Command.log
> log4j.appender.applicationAppender.layout=org.apache.log4j.PatternLayout
> log4j.appender.applicationAppender.layout.ConversionPattern=%d{%Y%m%dT%T.%l}
> [%-5p] %c %m%n

The loadProperties operation expects an Property XML format
file. You can generate one as follows:

depl:loadService("LoggingService","marshalling")
aa:provides("marshalling"):writeProperties("props.cpf")

Then edit props.cpf and load that file. AFAIK using above
configuration file will only work with the deployer when passed with
the "--rtt-log4cpp-config-file file" option.

> 2.- LOADING COMPONENT
>
> I try to load the component, it was loaded correctly if I use XML
> configuration files or Orocos Scripting, but when I use the next source the
> rttlua has an execption as "segmentation fault"
>
>
>
> depl:path("/media/DATA/orocos-toolchain/install/lib/orocos/gnulinux/orocos/compRF")
> depl:import("compRF")
> depl:loadComponent("cRF","ugv::drivers::CompRF")

I don't quite understand what you mean with "when I use the next
source". Can you send a backtrace for the segmentation fault? There is
one known issue in "rtt_rosnode" that is fixed in the latest debian
packages that caused crashes upon creating a port. Does updating your
packages help?

Markus

Problems with LUA ( logger properties & load components)

Dear Antonio,

Please keep the list on CC.

On Thu, Nov 24, 2011 at 05:57:16PM +0100, Antonio Castellon wrote:

>
> Could you send me an example of XML, because I use the attached file and when
> I launch the lua script it has a problem with it:

I don't have one, please try what I suggested in the previous email
and create the proprty xml using the marshalling service. The
marshalling service chokes because Your XML is a deployment XML, not a
property file.

> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> 0.075 [ ERROR ][PropertyLoader:load] Could not compose unknown type
> 'OCL::logging::LoggingService'.
> 0.075 [ ERROR ][PropertyLoader:load] Could not compose unknown type
> 'OCL::logging::FileAppender'.
>
> About the other problem with the load component, I attached the LUA script and
> I used different components that are launched sucessfully from
> deployer-gnulinux (using Orocos script or XML, but not from LUA ).
>
> Note : I 'm not using ROS... :-/

I'm sorry, but this is too little information to help you. When does
the crash occur exactly, what versions are you using? Debian packages
or from source? Are you sure everything is recompiled correctly?
Without a backtrace I have no clue what might be going wrong.

Best regards
Markus

enkulator's picture

Problems with LUA ( logger properties & load components)

Good morning Markus,

I execute the write XML properties from the correct deployer instance
(deployer-gnulinux) and it generate the next definition for each type:

*Service: (*logger_services.xml)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
<properties>
<struct name="Levels" type="PropertyBag">
<description>A PropertyBag defining the level of each category of
interest.</description>
<simple name="ugv.core" type="string"><value>debug</value></simple>
</struct>
<struct name="Appenders" type="PropertyBag">
<description>A PropertyBag defining the appenders for each category of
interest.</description>
*<simple name="ugv.core"
type="string"><value>AppenderA</value></simple>*
</struct>
</properties>

*Appender: (*logger_appenders.xml)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
<properties>
<simple name="LayoutName" type="string"><description>Layout name (e.g.
'simple', 'pattern')</description><value>pattern</value></simple>
<simple name="LayoutPattern" type="string"><description>Layout conversion
pattern (for those layouts that use a pattern)</description><value>%d [%t]
%-5p %c %x - %m%n</value></simple>
<simple name="Filename" type="string"><description>Name of file to log
to</description><value>log/Command.log</value></simple>
<simple name="MaxEventsPerCycle" type="long"><description>Maximum number
of log events to pop per cycle</description><value>0</value></simple>
</properties>

But when I try to use them on my luascript using:

depl:loadService("LoggingService","marshalling")
LoggingService:provides("marshalling"):loadProperties("logger_services.xml")

depl:loadService("AppenderA","marshalling")
AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")

It generates the unknow error:

OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
category: type is 'N7log4cpp8CategoryE'

Any idea? I try to found some information on forum/website and I found
other similar examples using the same pattern configuration on Appenders
struct.

Thanks in advance,
& Best regards,
Toni

On Thu, Nov 24, 2011 at 21:18, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:

> Dear Antonio,
>
> Please keep the list on CC.
>
> On Thu, Nov 24, 2011 at 05:57:16PM +0100, Antonio Castellon wrote:
>
> >
> > Could you send me an example of XML, because I use the attached file
> and when
> > I launch the lua script it has a problem with it:
>
> I don't have one, please try what I suggested in the previous email
> and create the proprty xml using the marshalling service. The
> marshalling service chokes because Your XML is a deployment XML, not a
> property file.
>
> > OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> > 0.075 [ ERROR ][PropertyLoader:load] Could not compose unknown type
> > 'OCL::logging::LoggingService'.
> > 0.075 [ ERROR ][PropertyLoader:load] Could not compose unknown type
> > 'OCL::logging::FileAppender'.
> >
> > About the other problem with the load component, I attached the LUA
> script and
> > I used different components that are launched sucessfully from
> > deployer-gnulinux (using Orocos script or XML, but not from LUA ).
> >
> > Note : I 'm not using ROS... :-/
>
> I'm sorry, but this is too little information to help you. When does
> the crash occur exactly, what versions are you using? Debian packages
> or from source? Are you sure everything is recompiled correctly?
> Without a backtrace I have no clue what might be going wrong.
>
> Best regards
> Markus
>
>

Problems with LUA ( logger properties & load components)

Hi Antonio,

On Fri, Nov 25, 2011 at 08:01:19AM +0100, Antonio Castellon wrote:
>
> I execute the write XML properties from the correct deployer instance
> (deployer-gnulinux) and it generate the next definition for each type:
>
> Service: (logger_services.xml)
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE properties SYSTEM "cpf.dtd">
> <properties>
> <struct name="Levels" type="PropertyBag">
> <description>A PropertyBag defining the level of each category of interest.</description>
> <simple name="ugv.core" type="string"><value>debug</value></simple>
> </struct>
> <struct name="Appenders" type="PropertyBag">
> <description>A PropertyBag defining the appenders for each category of
> interest.</description>
> <simple name="ugv.core" type="string"><value>AppenderA</value></
> simple>
> </struct>
> </properties>
>
>
> Appender: (logger_appenders.xml)
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE properties SYSTEM "cpf.dtd">
> <properties>
> <simple name="LayoutName" type="string"><description>Layout name (e.g.
> 'simple', 'pattern')</description><value>pattern</value></simple>
> <simple name="LayoutPattern" type="string"><description>Layout conversion
> pattern (for those layouts that use a pattern)</description><value>%d [%t]
> %-5p %c %x - %m%n</value></simple>
> <simple name="Filename" type="string"><description>Name of file to log to
> </description><value>log/Command.log</value></simple>
> <simple name="MaxEventsPerCycle" type="long"><description>Maximum number
> of log events to pop per cycle</description><value>0</value></simple>
> </properties>

It looks OK to me.

> But when I try to use them on my luascript using:
>
>
>
> depl:loadService("LoggingService","marshalling")
> LoggingService:provides("marshalling"):loadProperties
> ("logger_services.xml")
>
> depl:loadService("AppenderA","marshalling")
> AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>
>
>
> It generates the unknow error:
>
>
> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
> category: type is 'N7log4cpp8CategoryE'
>
>
> Any idea? I try to found some information on forum/website and I found other
> similar examples using the same pattern configuration on Appenders
> struct.

It seems that your category 'ugv.core' is not defined. I suspect it
might be because rttlua does not run

log4cpp::HierarchyMaintainer::set_category_factory(
OCL::logging::Category::createOCLCategory);

Steven, Peter, should I conditionally include (#ifdef
ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?

Does this really have to be in the main or can't this go into the
deployment component configuration? That would save us from
duplicating it?

Markus

Problems with LUA ( logger properties & load components)

On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>
> > But when I try to use them on my luascript using:
> >
> >
> >
> > depl:loadService("LoggingService","marshalling")
> > LoggingService:provides("marshalling"):loadProperties
> > ("logger_services.xml")
> >
> > depl:loadService("AppenderA","marshalling")
> > AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
> >
> >
> >
> > It generates the unknow error:
> >
> >
> > OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> > 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
> > category: type is 'N7log4cpp8CategoryE'
> >
> >
> > Any idea? I try to found some information on forum/website and I found other
> > similar examples using the same pattern configuration on Appenders
> > struct.
>
> It seems that your category 'ugv.core' is not defined. I suspect it
> might be because rttlua does not run
>
> log4cpp::HierarchyMaintainer::set_category_factory(
> OCL::logging::Category::createOCLCategory);
>
> Steven, Peter, should I conditionally include (#ifdef

I actually meant Stephen, sorry :-)

> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>
> Does this really have to be in the main or can't this go into the
> deployment component configuration? That would save us from
> duplicating it?

Any comment on this?

Markus

Problems with LUA ( logger properties & load components)

On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:

> On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>>
>>> But when I try to use them on my luascript using:
>>>
>>>
>>>
>>> depl:loadService("LoggingService","marshalling")
>>> LoggingService:provides("marshalling"):loadProperties
>>> ("logger_services.xml")
>>>
>>> depl:loadService("AppenderA","marshalling")
>>> AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>>>
>>>
>>>
>>> It generates the unknow error:
>>>
>>>
>>> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
>>> 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
>>> category: type is 'N7log4cpp8CategoryE'
>>>
>>>
>>> Any idea? I try to found some information on forum/website and I found other
>>> similar examples using the same pattern configuration on Appenders
>>> struct.
>>
>> It seems that your category 'ugv.core' is not defined. I suspect it
>> might be because rttlua does not run
>>
>> log4cpp::HierarchyMaintainer::set_category_factory(
>> OCL::logging::Category::createOCLCategory);
>>
>> Steven, Peter, should I conditionally include (#ifdef
>
> I actually meant Stephen, sorry :-)

I did wonder ... :-)

Yes, the above is required in any application/deployment that wants to use the real-time logging.

>> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>>
>> Does this really have to be in the main or can't this go into the
>> deployment component configuration? That would save us from
>> duplicating it?
>
> Any comment on this?

The above line _must_ occur _before_ any real-time loggers are actually instantiated. Otherwise you end up with non-real-time loggers, and all hell breaks loose ... You might be able to come up with a way to put this inside the logging service component, so that it loads then, but my intention with originally putting it _before_ RTT initialization was with the future hope of having RTT use the real-time logging itself (which is what we actually do).
S

Problems with LUA ( logger properties & load components)

On Fri, Nov 25, 2011 at 10:58:29PM +0100, S Roderick wrote:
> On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:
>
> > On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
> >>
> >>> But when I try to use them on my luascript using:
> >>>
> >>>
> >>>
> >>> depl:loadService("LoggingService","marshalling")
> >>> LoggingService:provides("marshalling"):loadProperties
> >>> ("logger_services.xml")
> >>>
> >>> depl:loadService("AppenderA","marshalling")
> >>> AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
> >>>
> >>>
> >>>
> >>> It generates the unknow error:
> >>>
> >>>
> >>> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
> >>> 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
> >>> category: type is 'N7log4cpp8CategoryE'
> >>>
> >>>
> >>> Any idea? I try to found some information on forum/website and I found other
> >>> similar examples using the same pattern configuration on Appenders
> >>> struct.
> >>
> >> It seems that your category 'ugv.core' is not defined. I suspect it
> >> might be because rttlua does not run
> >>
> >> log4cpp::HierarchyMaintainer::set_category_factory(
> >> OCL::logging::Category::createOCLCategory);
> >>
> >> Steven, Peter, should I conditionally include (#ifdef
> >
> > I actually meant Stephen, sorry :-)
>
> I did wonder ... :-)
>
> Yes, the above is required in any application/deployment that wants to use the real-time logging.
>
> >> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
> >>
> >> Does this really have to be in the main or can't this go into the
> >> deployment component configuration? That would save us from
> >> duplicating it?
> >
> > Any comment on this?
>
> The above line _must_ occur _before_ any real-time loggers are
> actually instantiated. Otherwise you end up with non-real-time
> loggers, and all hell breaks loose ... You might be able to come up
> with a way to put this inside the logging service component, so that
> it loads then, but my intention with originally putting it _before_
> RTT initialization was with the future hope of having RTT use the
> real-time logging itself (which is what we actually do).

And what is preventing us from putting it into RTT? The fear
additional dependencies? As log4cpp it is not intrusive and easily
(compile time) disabled I would vote for putting it in.

Markus

Problems with LUA ( logger properties & load components)

On Nov 30, 2011, at 04:28 , Markus Klotzbuecher wrote:

> On Fri, Nov 25, 2011 at 10:58:29PM +0100, S Roderick wrote:
>> On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:
>>
>>> On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>>>>
>>>>> But when I try to use them on my luascript using:
>>>>>
>>>>>
>>>>>
>>>>> depl:loadService("LoggingService","marshalling")
>>>>> LoggingService:provides("marshalling"):loadProperties
>>>>> ("logger_services.xml")
>>>>>
>>>>> depl:loadService("AppenderA","marshalling")
>>>>> AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>>>>>
>>>>>
>>>>>
>>>>> It generates the unknow error:
>>>>>
>>>>>
>>>>> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
>>>>> 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
>>>>> category: type is 'N7log4cpp8CategoryE'
>>>>>
>>>>>
>>>>> Any idea? I try to found some information on forum/website and I found other
>>>>> similar examples using the same pattern configuration on Appenders
>>>>> struct.
>>>>
>>>> It seems that your category 'ugv.core' is not defined. I suspect it
>>>> might be because rttlua does not run
>>>>
>>>> log4cpp::HierarchyMaintainer::set_category_factory(
>>>> OCL::logging::Category::createOCLCategory);
>>>>
>>>> Steven, Peter, should I conditionally include (#ifdef
>>>
>>> I actually meant Stephen, sorry :-)
>>
>> I did wonder ... :-)
>>
>> Yes, the above is required in any application/deployment that wants to use the real-time logging.
>>
>>>> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>>>>
>>>> Does this really have to be in the main or can't this go into the
>>>> deployment component configuration? That would save us from
>>>> duplicating it?
>>>
>>> Any comment on this?
>>
>> The above line _must_ occur _before_ any real-time loggers are
>> actually instantiated. Otherwise you end up with non-real-time
>> loggers, and all hell breaks loose ... You might be able to come up
>> with a way to put this inside the logging service component, so that
>> it loads then, but my intention with originally putting it _before_
>> RTT initialization was with the future hope of having RTT use the
>> real-time logging itself (which is what we actually do).
>
> And what is preventing us from putting it into RTT? The fear
> additional dependencies? As log4cpp it is not intrusive and easily
> (compile time) disabled I would vote for putting it in.
>
> Markus

We did this quite a while ago, but you do end up with a chicken-and-egg situation of RTT being init'd before logging can be configured, and issues like that. It's a little unwieldly - I'd like to take another long look at it first, before pushing to upstream.
S

Problems with LUA ( logger properties & load components)

On Wed, 30 Nov 2011, Stephen Roderick wrote:

> On Nov 30, 2011, at 04:28 , Markus Klotzbuecher wrote:
>
>> On Fri, Nov 25, 2011 at 10:58:29PM +0100, S Roderick wrote:
>>> On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:
>>>
>>>> On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>>>>>
>>>>>> But when I try to use them on my luascript using:
>>>>>>
>>>>>>
>>>>>>
>>>>>> depl:loadService("LoggingService","marshalling")
>>>>>> LoggingService:provides("marshalling"):loadProperties
>>>>>> ("logger_services.xml")
>>>>>>
>>>>>> depl:loadService("AppenderA","marshalling")
>>>>>> AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>>>>>>
>>>>>>
>>>>>>
>>>>>> It generates the unknow error:
>>>>>>
>>>>>>
>>>>>> OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
>>>>>> 0.092 [ ERROR ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
>>>>>> category: type is 'N7log4cpp8CategoryE'
>>>>>>
>>>>>>
>>>>>> Any idea? I try to found some information on forum/website and I found other
>>>>>> similar examples using the same pattern configuration on Appenders
>>>>>> struct.
>>>>>
>>>>> It seems that your category 'ugv.core' is not defined. I suspect it
>>>>> might be because rttlua does not run
>>>>>
>>>>> log4cpp::HierarchyMaintainer::set_category_factory(
>>>>> OCL::logging::Category::createOCLCategory);
>>>>>
>>>>> Steven, Peter, should I conditionally include (#ifdef
>>>>
>>>> I actually meant Stephen, sorry :-)
>>>
>>> I did wonder ... :-)
>>>
>>> Yes, the above is required in any application/deployment that wants to use the real-time logging.
>>>
>>>>> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>>>>>
>>>>> Does this really have to be in the main or can't this go into the
>>>>> deployment component configuration? That would save us from
>>>>> duplicating it?
>>>>
>>>> Any comment on this?
>>>
>>> The above line _must_ occur _before_ any real-time loggers are
>>> actually instantiated. Otherwise you end up with non-real-time
>>> loggers, and all hell breaks loose ... You might be able to come up
>>> with a way to put this inside the logging service component, so that
>>> it loads then, but my intention with originally putting it _before_
>>> RTT initialization was with the future hope of having RTT use the
>>> real-time logging itself (which is what we actually do).
>>
>> And what is preventing us from putting it into RTT? The fear
>> additional dependencies? As log4cpp it is not intrusive and easily
>> (compile time) disabled I would vote for putting it in.
>>
>> Markus
>
> We did this quite a while ago, but you do end up with a chicken-and-egg
> situation of RTT being init'd before logging can be configured, and
> issues like that. It's a little unwieldly - I'd like to take another long
> look at it first, before pushing to upstream.

To me it seems that the logging infrastructue is just a service as any
other one that can be loaded _at runtime_, that is, in other words, the
deployer can/should be involved to configure and launch the logger service
with the right ordering dependencies with other stuff that needs to be
deployed. Is this a too simple view on things?

In a broader context, the real solution to this kind of problems is, I
think, to separate the 'container' aspects of RTT from the 'application
component' aspects (by introducing an explicit 'container' primitive in
RTT, responsible for all interactions with the CPU/memory/OS/communication
platform. By deploying/starting the 'container' first, many chicken-and-egg
problems could be avoided...
> S

Herman

Problems with LUA ( logger properties & load components)

On Wed, Nov 30, 2011 at 9:22 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 30 Nov 2011, Stephen Roderick wrote:
>
>> On Nov 30, 2011, at 04:28 , Markus Klotzbuecher wrote:
>>
>>> On Fri, Nov 25, 2011 at 10:58:29PM +0100, S Roderick wrote:
>>>> On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:
>>>>
>>>>> On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>>>>>>
>>>>>>> But when I try to use them on my luascript using:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   depl:loadService("LoggingService","marshalling")
>>>>>>>   LoggingService:provides("marshalling"):loadProperties
>>>>>>>   ("logger_services.xml")
>>>>>>>
>>>>>>>   depl:loadService("AppenderA","marshalling")
>>>>>>>   AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It generates the unknow error:
>>>>>>>
>>>>>>>
>>>>>>>   OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
>>>>>>>   0.092 [ ERROR  ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
>>>>>>>   category: type is 'N7log4cpp8CategoryE'
>>>>>>>
>>>>>>>
>>>>>>> Any idea? I try to found some information on forum/website and I found other
>>>>>>> similar examples using the same pattern configuration on Appenders
>>>>>>> struct.
>>>>>>
>>>>>> It seems that your category 'ugv.core' is not defined. I suspect it
>>>>>> might be because rttlua does not run
>>>>>>
>>>>>>   log4cpp::HierarchyMaintainer::set_category_factory(
>>>>>>       OCL::logging::Category::createOCLCategory);
>>>>>>
>>>>>> Steven, Peter, should I conditionally include (#ifdef
>>>>>
>>>>> I actually meant Stephen, sorry :-)
>>>>
>>>> I did wonder ... :-)
>>>>
>>>> Yes, the above is required in any application/deployment that wants to use the real-time logging.
>>>>
>>>>>> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>>>>>>
>>>>>> Does this really have to be in the main or can't this go into the
>>>>>> deployment component configuration? That would save us from
>>>>>> duplicating it?
>>>>>
>>>>> Any comment on this?
>>>>
>>>> The above line _must_ occur _before_ any real-time loggers are
>>>> actually instantiated. Otherwise you end up with non-real-time
>>>> loggers, and all hell breaks loose ... You might be able to come up
>>>> with a way to put this inside the logging service component, so that
>>>> it loads then, but my intention with originally putting it _before_
>>>> RTT initialization was with the future hope of having RTT use the
>>>> real-time logging itself (which is what we actually do).
>>>
>>> And what is preventing us from putting it into RTT? The fear
>>> additional dependencies? As log4cpp it is not intrusive and easily
>>> (compile time) disabled I would vote for putting it in.
>>>
>>> Markus
>>
>> We did this quite a while ago, but you do end up with a chicken-and-egg
>> situation of RTT being init'd before logging can be configured, and
>> issues like that. It's a little unwieldly - I'd like to take another long
>> look at it first, before pushing to upstream.
>
> To me it seems that the logging infrastructue is just a service as any
> other one that can be loaded _at runtime_, that is, in other words, the
> deployer can/should be involved to configure and launch the logger service
> with the right ordering dependencies with other stuff that needs to be
> deployed. Is this a too simple view on things?

This was my initial idea too, and logging has been implemented as
a service for the major part. It's only the log("message") statements in
user/component/rtt code which is causing
the dependency during link-time anyway, so this 'minimal' support
must always be compiled in.

>
> In a broader context, the real solution to this kind of problems is, I
> think, to separate the 'container' aspects of RTT from the 'application
> component' aspects (by introducing an explicit 'container' primitive in
> RTT, responsible for all interactions with the CPU/memory/OS/communication
> platform. By deploying/starting the 'container' first, many chicken-and-egg
> problems could be avoided...

Our deployer now plays the role of application/component container, implicitly,
so if you make your own deployer (such as rttlua), you have to make sure that
it offers the same services as the standard deployer; or certain apps won't work
anymore due to a lack of services.

Peter

Problems with LUA ( logger properties & load components)

On Thu, 1 Dec 2011, Peter Soetens wrote:

> On Wed, Nov 30, 2011 at 9:22 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Wed, 30 Nov 2011, Stephen Roderick wrote:
>>
>>> On Nov 30, 2011, at 04:28 , Markus Klotzbuecher wrote:
>>>
>>>> On Fri, Nov 25, 2011 at 10:58:29PM +0100, S Roderick wrote:
>>>>> On Nov 25, 2011, at 15:45 , Markus Klotzbuecher wrote:
>>>>>
>>>>>> On Fri, Nov 25, 2011 at 11:16:40AM +0100, Markus Klotzbuecher wrote:
>>>>>>>
>>>>>>>> But when I try to use them on my luascript using:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   depl:loadService("LoggingService","marshalling")
>>>>>>>>   LoggingService:provides("marshalling"):loadProperties
>>>>>>>>   ("logger_services.xml")
>>>>>>>>
>>>>>>>>   depl:loadService("AppenderA","marshalling")
>>>>>>>>   AppenderA:provides("marshalling"):loadProperties("logger_appenders.xml")
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It generates the unknow error:
>>>>>>>>
>>>>>>>>
>>>>>>>>   OROCOS RTTLua 1.0-beta3 / Lua 5.1.4 (gnulinux)
>>>>>>>>   0.092 [ ERROR  ][rttlua-gnulinux::main()] Category 'ugv.core' is not an OCL
>>>>>>>>   category: type is 'N7log4cpp8CategoryE'
>>>>>>>>
>>>>>>>>
>>>>>>>> Any idea? I try to found some information on forum/website and I found other
>>>>>>>> similar examples using the same pattern configuration on Appenders
>>>>>>>> struct.
>>>>>>>
>>>>>>> It seems that your category 'ugv.core' is not defined. I suspect it
>>>>>>> might be because rttlua does not run
>>>>>>>
>>>>>>>   log4cpp::HierarchyMaintainer::set_category_factory(
>>>>>>>       OCL::logging::Category::createOCLCategory);
>>>>>>>
>>>>>>> Steven, Peter, should I conditionally include (#ifdef
>>>>>>
>>>>>> I actually meant Stephen, sorry :-)
>>>>>
>>>>> I did wonder ... :-)
>>>>>
>>>>> Yes, the above is required in any application/deployment that wants to use the real-time logging.
>>>>>
>>>>>>> ORO_BUILD_LOGGING ) the same code as deployer.cpp to set up logging?
>>>>>>>
>>>>>>> Does this really have to be in the main or can't this go into the
>>>>>>> deployment component configuration? That would save us from
>>>>>>> duplicating it?
>>>>>>
>>>>>> Any comment on this?
>>>>>
>>>>> The above line _must_ occur _before_ any real-time loggers are
>>>>> actually instantiated. Otherwise you end up with non-real-time
>>>>> loggers, and all hell breaks loose ... You might be able to come up
>>>>> with a way to put this inside the logging service component, so that
>>>>> it loads then, but my intention with originally putting it _before_
>>>>> RTT initialization was with the future hope of having RTT use the
>>>>> real-time logging itself (which is what we actually do).
>>>>
>>>> And what is preventing us from putting it into RTT? The fear
>>>> additional dependencies? As log4cpp it is not intrusive and easily
>>>> (compile time) disabled I would vote for putting it in.
>>>>
>>>> Markus
>>>
>>> We did this quite a while ago, but you do end up with a chicken-and-egg
>>> situation of RTT being init'd before logging can be configured, and
>>> issues like that. It's a little unwieldly - I'd like to take another long
>>> look at it first, before pushing to upstream.
>>
>> To me it seems that the logging infrastructue is just a service as any
>> other one that can be loaded _at runtime_, that is, in other words, the
>> deployer can/should be involved to configure and launch the logger service
>> with the right ordering dependencies with other stuff that needs to be
>> deployed. Is this a too simple view on things?
>
> This was my initial idea too, and logging has been implemented as
> a service for the major part. It's only the log("message") statements in
> user/component/rtt code which is causing
> the dependency during link-time anyway, so this 'minimal' support
> must always be compiled in.

Mmm, I am not so sure... This is a typical use case where the "dependency
injection" pattern would work: the "thing" that is being logged need not
take the action to log, but must provide its loggable data for reading at
"ports" for the logging service to discover/configure/use via introspection at
runtime. Maybe I am talking next to the question.... please let me know :-)

>> In a broader context, the real solution to this kind of problems is, I
>> think, to separate the 'container' aspects of RTT from the 'application
>> component' aspects (by introducing an explicit 'container' primitive in
>> RTT, responsible for all interactions with the CPU/memory/OS/communication
>> platform. By deploying/starting the 'container' first, many chicken-and-egg
>> problems could be avoided...
>
> Our deployer now plays the role of application/component container, implicitly,

Indeed: as in many cases, the good RTT developers implicitly use the RTT
primitives in the right way. But that should be improved and made explicit,
by splitting some of the existing primitives, the TaskContext in,
articular, into more primitive primitives with a more limited but
appropriate feature set. Easy to say, more difficult to do :-)

> so if you make your own deployer (such as rttlua), you have to make sure that
> it offers the same services as the standard deployer; or certain apps won't work
> anymore due to a lack of services.

What makes something into a "standard" deployer by the way? One that
implements a deployment standard such as OMG's DEPL...? :-) (Would be
nice...)

> Peter

Herman

Problems with LUA ( logger properties & load components)

On 01/12/11 05:22, Herman Bruyninckx wrote:
> In a broader context, the real solution to this kind of problems is, I
> think, to separate the 'container' aspects of RTT from the 'application
> component' aspects (by introducing an explicit 'container' primitive in
> RTT, responsible for all interactions with the CPU/memory/OS/communication
> platform. By deploying/starting the 'container' first, many chicken-and-egg
> problems could be avoided...

It works very well for us. Isn't this how OSGi does it, too?

Geoff

Problems with LUA ( logger properties & load components)

On Thu, 1 Dec 2011, Geoffrey Biggs wrote:

> On 01/12/11 05:22, Herman Bruyninckx wrote:
>> In a broader context, the real solution to this kind of problems is, I
>> think, to separate the 'container' aspects of RTT from the 'application
>> component' aspects (by introducing an explicit 'container' primitive in
>> RTT, responsible for all interactions with the CPU/memory/OS/communication
>> platform. By deploying/starting the 'container' first, many chicken-and-egg
>> problems could be avoided...
>
> It works very well for us. Isn't this how OSGi does it, too?

I think so. If only we could simply use the (Java-only) OSGi infrastructure
for non-Java frameworks too, sigh... :-(

> Geoff

Herman