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.