Closed smillidge closed 10 years ago
Hi Scott,
The primary use case is to enable easy replacement of the implementations of the various services exposed by the ServicesManager. In particular I am interested in providing alternative implementations of the IPersistenceManagerService. This could be to create specific optimised RDBMS implementations, however it would also enable easy integration of NoSQL or file based persistent stores.
Currently ServicesManagerImpl only appears to read the service implementation class names from META-INF/services/batch-services.properties which means the core jar needs to be patched which is not ideal.
This patch adds a simple mechanism for a container to hook in service overrides before the service classes are defined.
An alternative would be to search for batch-config.properties and batch-services.properties in other classloaders for example the current thread context class loader as well as
InputStream batchServicesListInputStream = this.getClass() .getResourceAsStream("/META-INF/services/" + BATCH_INTEGRATOR_CONFIG_FILE);
Steve
Steve,
So, just to be clear, the sequence is:
1) Some bundle starts before the first batch call and calls BatchSPIManager.registerBatchContainerOverrideProperties()
2) The ServicesManagerImpl, in the core RI bundle, (now named com.ibm.jbatch.container) gets lazily initialized when the first batch API is invoked: (BatchRuntime.getJobOperator()) .
Just wanted to be clear that the register call 1) has to happen before JobOperator is loaded for this to work.
Does that sound right?
If so, I like this. It seems like simply a better way to use the one-off configurability we've already provided (which as you said isn't too usable if it requires editing the com.ibm.jbatch.container JAR).
Hi Scott,
That's exactly right. I'm just looking for a one shot way to override the properties you are reading from the JAR before the container is initialized.
Steve
I can't say I tested this in any way, but it looks good, so merging.
I have a JUnit test that works but I haven't added it to the commit as it needs to be marked @Ignore as it needs to be run on its own as the other tests initialise the runtime before the properties can be overriden. I can provide the unit test in a new pull request if required.
Steve, it's not required, probably of minimal value now with the given test infrastructure. If someone wants to pull in Glassfish into our Maven build/test, then it might be useful. No idea how much work that is.
Provides an extension point for GlassFish to override service implementations by providing properties to override those read from the META-INF.
Fix #12