Jim Knutson wrote on 01/29/13 11:09:
> Bill Shannon <bill.shannon_at_oracle.com> wrote on 01/25/2013 04:55:21 PM:
>> There are at least two models for how an application might deal with
>> these batch scripts:
>>
>> 1. The batch scripts are an integral part of the application. They're
>> supplied with the application and controlled by the application.
>>
>> 2. The application supplies only the batch job steps, expecting that
>> an external agent (usually an administrator) constructs a batch
>> script using these jobs. The application controls the execution
>> of the script, but not the content of the script.
>>
>> In the first case it seems obvious that the batch script XML files
>> should be packaged with the application and the application should
>> refer to them by using a resource name in the application (possibly
>> a name valid for Class.getResource(), possibly a name of a file in
>> a fixed location in the application) when using the Batch API.
>
> I assume noone has an issue with using a standard packaging of scripts
> in an application module (e.g. META-INF/batch-jobs) and using
> getResource() to access them. This has been a standard practice for
> resource access for ages. I can't see much value that @Resource
> would provide in this case, though eventually, @Resource might prove
> useful (once we get modularity).
I agree, this is fine, and @Resource is not needed in this case.
>> In the second case, the application needs to refer to these scripts,
>> but the scripts aren't packaged with the application, so it's not
>> clear how the application should refer to them. The Batch API
>> specifies this case very loosely. The Batch implementation is
>> free to interpret the names given to it in any way it desires,
>> locating these batch scripts wherever and however it wants. The
>> names used with case #1 above are portable, assuming they
>> haven't been overridden in some Batch implementation-specific way.
>
> I think it is perfectly valid to allow the spec to define extension
> points that vendors may use. In this case, the mechanism allows
> vendors to provide batch jobs and job management without being
> limited to application packaged scripts.
I have no objection to providing a way to do that. My objection is
that the way currently specified is unlike what we've done in similar
cases in other specs.
This seems like a typical Java EE case where the application depends
on a resource that the deployer or administrator must provide. Normally
we indicate such a dependency using something like @Resource.
If the application using Batch indicated its dependency on an externally
supplied batch job script using (e.g.)
@Resource
BatchJob aBatchJob;
And then could call
JobOperator.getJobOperator().start(aBatchJob);
(Obviously BatchJob is a new class needed to make this work.)
That would be consistent with other Java EE specs. The Deployer would
know that the application depends on an externally supplied batch job
script and would be required to configure one appropriately. Where
that script comes from, how it's configured, etc. can be left unspecified,
allowing the vendor to add value.
> In addition, it allows for
> cases where batch jobs and scripts may be computed dynamically by
> the application logic and not necessarily known at app deployment
> time.
That's supported by the ability to supply the complete XML for the
batch script. How the application finds or creates that XML is
unspecified, which is fine.