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

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