[jsr342-experts] Re: Batch API issue

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 28 Jan 2013 13:59:24 -0800

Markus Eisele wrote on 01/27/13 21:58:
> 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).

The current Batch spec requirement simply says:

  The batch runtime implementation must provide an implementation-specific
  means by which Job XML references are resolved to a Job XML document.

That's so weak as to be effectively optional.

> 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

Yes, if a future Configuration API provides more flexibility in where
and how configuration artifacts are made available to an application,
the Batch API could certainly make use of that.

> 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)

Thanks for your feedback.