Bugzilla – Bug 4199
Use of batch.xml in JEE environment
Last modified: 2013-01-16 18:32:19 UTC
It seems like the use of a batch.xml, presumably packaged in an application JAR/WAR/etc., would not fit so well into something like a JEE environment.
Does it really seem correct to force a JEE-based JSR352 implementation to allow an app to specify its own artifact loading scheme, overriding what is probably an already carefully constructed and non-trivial loading scheme in the managed environment?
I'm not sure how much sense it makes for the transaction SPI either.
Would it be better to say there are two modes: JEE, JSE (or managed/unmanaged maybe).
Leave it undefined, i.e. implementation-specific, how the runtime decides which mode it is operating under.
But these SPIs would then only apply to JSE (unmanaged) mode.
As I'm saying this I'm realizing these thoughts must have come up in other JSR discussions if not this one. If that's the case then I'm curious how you thought this would fit into JEE.
The idea behind these SPIs is:
- use of alternate DI technologies - CDI, Spring DI, OSGi Blueprint
- use of platform appropriate transaction manager: JTA, CICS, JOTM, etc
- DI agnostic @JobOperator injection
I think I agree exposing this to the application developer directly via a mechanism like batch.xml is not the best idea.
I'm thinking maybe the best approach is to eliminate the SPIs altogether and leave it to the implementer. For transaction management, we can stipulate JTA is must be used.
On the other hand, maybe we should keep the SPIs, but expose them differently - outside the reach of the application developer. Perhaps we simply specify the SPIs are implemented with an interface and factory pattern. An implementer could provide their own implementation of the factory ...
I do not believe that JTA should be a must use for transaction. I think local transactions are sufficient for single process, single resource batch scenarios, which covers a large number of batch cases. I'm wondering if the JPA spec provides an approach we can leverage with providing configurations for JSE vs JEE.
The transaction manager SPI has been removed. The choice of global vs local has been removed. The final proposed draft states global transactions are used in JEE and local in SE.