Date: Sat, 26 Jan 2013 02:17:58 +0100
Bill,
Thanks a lot for pointing that out.
I would prefer 2.
Is @Resource the only or best option you see, or would other alternatives
like @Inject if technically feasable also work?
Sorry to add this here again, but in the JSR 358 (JCP.next) EG we just came
across some interesting and valid points about Umbrella JSRs like EE and
those JSRs meant for inclusion. Markus I believe must have quoted section
2.1.3 of the JCP procedures already, and Batch has upgraded to JCP 2.9
where this is quoted from:
2.1.2 PROTECT THE INSTALLED BASE AND GUARD AGAINST FRAGMENTATION
Changes to the Java programming language, the Java virtual machine (JVM,)
the Java Native Interface (JNI,) packages in the "java.*" space, or other
packages delivered only as part of Java SE, have the potential to seriously
disrupt the installed base if carried out inconsistently across the
Platform Editions. In order to protect the installed base, any such changes
can only be accepted and carried out within a UJSR for Java SE.
*In order to guard against fragmentation, new Platform Edition
Specifications must not substantially duplicate existing Platform Editions
or Profiles.*
2.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONS
All new or revised Specifications must be compatible with the most recent
versions of the targeted Platform Edition Specifications. In order to
achieve this, all UJSRs to define new Profile Specifications or revise
existing Profile Specifications must reference either the most recent
Release version of the Platform Edition Specification they are based upon
or a newer version of that Specification that is under development via an
active UJSR.
2.1.4 PLATFORM INCLUSION
The JSR submission form requires the submitter to state whether the JSR's
RI and TCK should be delivered as part of a Profile or Platform Edition, in
standalone manner, or both. The final decision as to whether a specific JSR
is included in a Profile or a Platform Edition is made by the Spec Lead and
Expert Group of the Platform Edition or Profile JSR, and is confirmed by
the EC ballots on the relevant JSR. If the Spec Lead for the Platform
Edition or Profile JSR turns down a request for inclusion then the JSR must
deliver a standalone RI and TCK.
*Technologies may be incorporated into a Profile or Platform Edition after
having been initially delivered standalone. A JSR for a new version of an
API that proposes to become part of a Profile or Platform Edition and is
considering discontinuing standalone availability must state the rationale
for this change and must inform the public of the intention to discontinue
the availability of the standalone RI, and TCK one JSR submission in
advance.*
The signature of the 2 interfaces that duplicate AutoCloseable from SE 7
may not be that "significant", but the interesting and vital question
remains, if and under what terms, JSR 352 shall be made available
"standalone" if the minimum SE version was 6, or would this qualify as
"backport" into EE 6 Umbrella instead?[?]
Thanks,
Werner
On Fri, Jan 25, 2013 at 11:55 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> I'd like the advice of this group on an issue with the Batch API.
>
> The Batch API specifies how applications can define job steps.
> Job steps are combined into a batch job using an XML file that
> is effectively a batch "job control language" script. The application
> starts a batch job by supplying this batch JCL script to the Batch API.
>
> 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.
>
> 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.
>
> Normally, when a Java EE application uses a resource that's external
> to the application and can be configured by an administrator, we
> expect the application to declare this external dependency using
> (e.g.) a @Resource annotation. This creates information known to
> the deployment process that alerts the deployer that an external
> resource is being referenced and must be supplied.
>
> The Batch API provides no way to expose to the deployment process
> an application's dependency on an externally supplied batch script.
> An application might fail at runtime because the administrator didn't
> supply the expected script with the expected name.
>
> I've proposed that the Batch API make use of @Resource to handle
> this case, similarly to how we've handled other cases, but they've
> rejected that proposal. They believe the loosely defined approach
> that leaves all the details up to the implementation is sufficient.
>
> 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.
>
(image/gif attachment: 35F.gif)