[javaee-spec users] [jsr342-experts] Re: Batch API issue

From: Pete Muir <>
Date: Mon, 28 Jan 2013 18:01:41 +0000

I would tend to agree with Markus.

On 28 Jan 2013, at 05:58, Markus Eisele wrote:

> HI Bill,
> I understand the requirements and I indeed can follow the Batch API
> scenario. (you're referring to 7.6 Job XML Loading here, right?)
> With regards to the fact that this is an implementation aspect only
> and will never reach out to end-users I would be very open. Given,
> that there are a lot of portability issues with file-system access, it
> will be a burden for the 352 implementations to handle all the
> different server environments. Curious if they would be willing to
> discuss about making this implementation specific loader optional (at
> least in 1.0).
> Nevertheless with regards to being part of the EE umbrella I am in
> favor of using @Resource or comparable constructs for loading their
> external resources if they are running in the container context. As
> long as we don't have a Java EE File API which takes care of all the
> portability, security, clustering and threading issues this is the
> only way I see.
> I'm wondering if this is also describing a possible use case for a
> future Configuration API? What else could be solutions:
> - deploy the scripts as a library/configuration jar
> - put them in a database
> To sum it up: They should either use @Resource or drop the
> implementation specific loader from their 1.0 (with good hope for a
> better solution in EE 8)
> - M
>> Which approach do you prefer?
>> 1. The current Batch API approach of leaving all the details
>> up to the implementation.
>> 2. Find a way (e.g., @Resource) to expose these application dependencies
>> on an external batch script to the deployment process.
>> Let me know what you think.