[jsr352-public] Batch Java EE Integration and application context propagation
- From: Cheng Fang <
- Subject: [jsr352-public] Batch Java EE Integration and application context propagation
- Date: Wed, 02 Oct 2013 23:29:41 -0400
While integrating our batch implementation into Java EE, we noticed this
is an area not adequately covered by either batch spec or Java EE 7
Platform spec, which is understandable in the first release of the new
spec. And in an earlier discussion in this list, Chris also indicated
interest to remedy that in next version.
Our main concern with batch EE integration is portability and
compatibility. Product A and B may have batch integrated into Java EE
differently, and even though they both passed TCK, batch applications
deployed to different appservers may still experience different behaviors.
Even though we tried to best align batch with EE platform during our
batch integration, it's still possible the next version of batch spec
may include different integration requirements we will need to implement
at the risk of breaking product backward compatibility.
So I propose we start discussion on batch Java EE integration. Any new
requirements will not be in batch spec 1.0, but they can provide
guidance and expectations for application developers and spec implementers.
One area that can benefit from clarification is how to propagate various
EE application contexts (e.g., classloader, security context, jndi
naming context, transaction context) to batch threads. Inside an
appserver, the batch container may use threads that are not managed by
EE containers (ejb or web containers), and EE spec does not require
context propagation to such unmanaged threads.
But we think it's common use case for batch artifacts running on
unmanaged threads to use Java EE services such as jndi lookup, or EJB
invocations, or resource injections. To achieve that, some form of
context propagation is needed from the EE component that started batch job.
What types of contextual data must be propagated? If we follow the
approach in JSR 236 Concurrency Utils for EE, it will be classloader,
naming context and security context, but not transaction context. Batch
runtime manages global transaction on its own so no tx propagation is
When it comes to jndi naming context propagation, which jndi namespaces
must be propagated, java:global/, java:app/, java:module/, and
java:comp/? We believe java:global, java:app, java:module should be
propagated, but java:comp namespace should not. All constant entries in
java:comp required by EE spec will still be propagated, such as
java:comp/UserTransaction. In webapp, java:comp/ mirrors java:module
and so will also be made available. For this specific naming context
propagation issue, we recently filed an issue with CTS, and I will be
happy to share more details when we are on that topic.