We are using liquibase to handle db migration procedures inside our product and we have run into some trouble with the service loading mechanism. Our environment is rather complex: The execution classpath of liquibase contains hundreds of jars and moreover, some of these jars are modified at runtime. This leads to recurring errors reading jar files when liquibase scans its classpath to retrieve the components it needs, sometimes even to the point of crashing the JVM (segmentation faults occur in the underlying libc/libz when a jar is modified while being mapped to memory). We are aware this situation is far from perfect but it is difficult to change in the short term.
Therefore I would like to make the service loading more configurable to the point where it would bypass class loading mechanism and use given configuration object. This is appears to be currently possible as one can override ServiceLocator and related classes, but for the default singleton ServiceLocator is created which scans the classpath at construction time. My proposal is therefore simple: Do not build default ServiceLocator eagerly but use some external configuration mechanism to know which ServiceLocator to create (system property, command-line parameter, configuration file…).
If this sounds reasonable, I think I could easily provide some patch.