Make service loading mechanism more configurable

Hello,


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.


Regards,

Arnaud

Yes, it should be able to be overridden. If you have a patch definitely send a pull request and I’ll take a look.


Nathan

Thanks.

We found a workaround to some weird issue with this ServiceLocator mechanism by setting the liquibase.packages property explicitly which bypasses initial scan of the classpath to extract Liquibase-Package properties from the MANIFEST.MF. The issue we encountered was some random failures in the classpath scanning mechanism which manifested itself through an uninformative ZipException. We believe this is caused by the JVM hitting the upper limit of open file descriptors: JarFile are never closed unless close() method is explicitly closed or the JarFile object is garbaged, and when do some full classpath scanning twice, bad things happen.

Anyway, I definitely think that it would be a good idea to be able to set explicitly which classes are to be loaded in order to provide more control in production. I will attempt a patch this week, I think.

Regards,