Bug 4199 - Use of batch.xml in JEE environment
Use of batch.xml in JEE environment
Product: jbatch
Classification: Unclassified
Component: source
PC Windows
: P5 major
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2012-10-10 16:56 UTC by ScottKurz
Modified: 2013-01-16 18:32 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2012-10-10 16:56:42 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. 

Take BatchArtifactFactory....

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.

Comment 1 cvignola 2012-10-10 18:04:33 UTC
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 ...
Comment 2 waynexlund 2012-11-14 23:24:21 UTC
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.
Comment 3 cvignola 2013-01-16 15:22:39 UTC
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.