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 Muir <pmuir_at_bleepbleep.org.uk
> <mailto:pmuir_at_bleepbleep.org.uk>> wrote:
>
> 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.
>
>