> 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.
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. Regards, Erik
