Skip to main content

[jsr352-public] Batch Java EE Integration and application context propagation

  • From: Cheng Fang < >
  • To:
  • 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 needed.

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.


[jsr352-public] Batch Java EE Integration and application context propagation

Cheng Fang 10/03/2013

[jsr352-public] Re: Batch Java EE Integration and application context propagation

Scott Kurz 10/03/2013
Please Confirm