celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: svn commit: r1627453 - /celix/trunk/remote_services/topology_manager/private/src/activator.c
Date Thu, 25 Sep 2014 06:52:17 GMT
2014-09-25 8:30 GMT+02:00 Björn Petri <bjoern.petri@sundevil.de>:
> I agree, I had always the impression that the fw_log is using the
> logservice.

Not the case, maybe it could be done like that. But then you would really
on a private framework API. Considering the OSGi API, this should not be
the case.

> But nevertheless wouldn't it be useful to have a re-usable code part which
> takes care of register/unregistering the log service and also implement a
> fallback-printf?

I guess you mean tracking the log_service and not register/unregister,
since that is part of the log_service's implementation itself.

I am not so sure. The boilerplate code for getting the log_service should
be minimized using a dependency manager or something. But since we don't
have that one yet, we could add a piece of public code to the log_service
containing a pre-setup tracker for the log_service.

But then it is still needed to check if the log_service is available before
logging. This could simply be put in a method inside your own component,
only about 5 lines or something.. If a printf fallback is needed, it could
be placed in that code as well.

static myComponent_log(my_component_pt cmp, log_level_t level, char *log) {
  if (cmp->logService) {
    cmp->logService->log(cmp->logService->logger, level, log);
  } else {
    printf("STDOUT Log: %s", log);

> Otherwise we end up with plenty of boilerplate-code only for doing "some"
> logs.

Most code is in the needed tracker, the other part can be put away in a
wrapper method. It would really be nice to have a dependency_manager here..

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message