WASdev / standards.jsr352.jbatch

Home of 'jbatch', a compatible implementation of the Jakarta Batch specification (and the former Reference Implementation for the JSR 352, Batch Applications for the Java Platform specification).
Other
21 stars 18 forks source link

added extension location for a container to provide override properties #14

Closed smillidge closed 10 years ago

smillidge commented 10 years ago

Provides an extension point for GlassFish to override service implementations by providing properties to override those read from the META-INF.

Fix #12

smillidge commented 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

scottkurz commented 10 years ago

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).

smillidge commented 10 years ago

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

scottkurz commented 10 years ago

I can't say I tested this in any way, but it looks good, so merging.

smillidge commented 10 years ago

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.

scottkurz commented 10 years ago

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.