The new service discovery system mimics java services, but is based on properties. As such, keys are the service class followed by any differentiation string, and values are concrete implementation class names. For example, a converter will now be installed in the common settings file, like
The "something" in the key is not really used for any purpose, except differentiating the different keys and thus giving the possibility to override them. This sytem is okay but is still missing the order of precedence of possible different implementations. For example, I could have a generic converter, able to convert everything using the toString method or a format of XML serialization, and want it as the last resort if a better one is not found for a specific type. This is available in java services, but it is not clear if it is an implementation detail or if is a documented behaviour. In any case, it is not available in a consistent way when more than one service definition file is found on the classpath.
Raw alphabetical sorting of keys could be a solution, but would also make keys more difficult to override. Up to now this feature has not been necessary, it could be for LABS-352, in which case it will be implemented.