Werner Keil wrote on 01/25/13 17:17:
> 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?
Only @Resource (and related annotations like @EJB) expose the required
information to the deployment process. @Inject is processed during CDI
initialization, which happens after deployment.
>
> 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?
They're clearly not proposing to change anything about EE 6.
None of the sections quoted above apply to the issue you've raised with the
Batch spec.