celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From e...@jansman.eu
Subject Re: celix log levels
Date Fri, 13 Dec 2013 08:21:48 GMT
> Hi,
> 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
> enough?
> 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.

This doesn't improve readability of the code and I personally think that
it is not likely to happen. And following the reasoning, what if the
external library is a OSGI library? That might still lead to problems. So
personally i am against it.



View raw message