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.