Hi,
2013/12/13 <[email protected]> > > > 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 > EVENT_ADMIN_? > 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 IMPLEMENTATION_A_LOG_SERVICE_ and IMPLEMENTATION_B_LOG_SERVICE_. This is 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: * OSGI_SERVICE_{NAME}_{INTERFACE}_{VALUE} --> OSGI_SERVICE_LOG_LOGSERVICE_LOG_DEBUG * {NAME}_{VALUE} --> LOGSERVICE_LOG_DEBUG * CELIX_{VALUE} --> CELIX_LOG_DEBUG Using this mechanism, enums/constants from the framework should be named: * OSGI_FRAMEWORK_{INTERFACE}_{VALUE} So instead of having BUNDLE_INSTALLED, this should be changed to OSGI_FRAMEWORK_BUNDLE_INSTALLED. 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
