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.