Skip to main content

[javaee-spec users] [jsr342-experts] Re: Batch API issue

  • From: Bill Shannon <bill.shannon@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: Batch API issue
  • Date: Mon, 28 Jan 2013 14:01:21 -0800
  • List-id: <jsr342-experts.javaee-spec.java.net>

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@...> 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.





[javaee-spec users] [jsr342-experts] Batch API issue

Bill Shannon 01/25/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Werner Keil 01/26/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Bill Shannon 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Werner Keil 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Bill Shannon 01/29/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Werner Keil 01/29/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Markus Eisele 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Pete Muir 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Werner Keil 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Bill Shannon 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Bill Shannon 01/28/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Jim Knutson 01/29/2013

[javaee-spec users] [jsr342-experts] Re: Batch API issue

Bill Shannon 01/29/2013
 
 
Close
loading
Please Confirm
Close