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: celix log levels
Date Fri, 13 Dec 2013 08:04:04 GMT

2013/12/13 <erik@jansman.eu>

> > Any other ideas?
> Using LOG_SERVICE_ sounds like a good idea. Will it imply to use the
> SERVICE_NAME_ prefix for all enums/constants? In the Event admin this
> problem also occurred with conflicting names from the framework and we
> solved this by using EVENT_ as a prefix, should this then be changed to

Yes I think that makes sense.

Even in the case when there are multiple implementations of a certain
service are used this is still ok. It is not needed to have something like
because they are both implementations of the LOG_SERVICE so both use the
same enum (since the enum is dictated by the service, not by the component).

Additional question (and thinking out loud): do we need to include
something like OSGI_ in front of everything? With Celix being a generic
services solution, there is always a change that some third party library
has a similar enum. Within Java the namespace
org.osgi.service.{name}.{interface} solves this. Is only using {name} good

So the following options are now proposed:

Using this mechanism, enums/constants from the framework should be named:

So instead of having BUNDLE_INSTALLED, this should be changed to

The problem I see with this is that the OSGi spec isn't really consistent
with constant naming. Sometimes the values are prefixed (eg LOG_DEBUG), and
sometimes not (UNINSTALLED from Bundle). From a Java point of view, the
Bundle constants are fine, they are within the Bundle namespace. This
results in the awkward looking OSGI_SERVICE_LOG_LOGSERVICE_LOG_DEBUG.

So I'd like to propose to use the Bundle constants as an example and do the
same for the others. This would make the LogService constants to be:
* OSGI_SERVICE_LOG_LOGSERVICE_DEBUG --> This still has a duplication, but
removing this might result in conflicts if within one package multiple
Classes use the same constant names.

Met vriendelijke groet,

Alexander Broekhuis

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