The spec lead clearly intends that Batch is usable outside of Java
EE, in a Java SE only environment. That's fine.|
Werner Keil wrote on 01/28/13 10:04:
Would any of that mean, Batch is supposed to be in the
EE umbrella only, or are there parts that will work standalone,
without an EE container?
That mostly relates to the question of SE 6 vs. 7 before.
On Mon, Jan 28, 2013 at 7:01 PM, Pete
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
> 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
> - deploy the scripts as a library/configuration jar
> - put them in a database
> To sum it up: They should either use @Resource or
> 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
>> on an external batch script to the deployment
>> Let me know what you think.