-
Bug
-
Resolution: Done
-
Critical
-
None
-
None
Prior to 1.1.0.Final I was able to load and start a batch job located in jar 1 from jar 2. Both jars were package inside an ear. Now with the latest introduction of spi resolver (JobXmlResolverService from wildfly 9) the service created for jar 2 have no jobXmlResolvers so the start method from JobOperator throws an javax.batch.operations.JobStartException: JBERET000601: Failed to get job xml file for job XXX.
According to the spec:
"archive loader If the implementation-specific mechanism does fails to resolve a Job XML reference, then the batch runtime implementation must resolve the reference with an archive loader. The implementation must provide an archive loader that resolves the reference by looking up the reference from the META-INF/batch-jobs directory." I think that the implementation have to try to load jobs also in META-INF/batch-jobs dir.
Changes in the old behaviour was made due to Issue JBERET-144
- is related to
-
WFLY-4998 Domain deployment batch subsystem resources throw an NPE when an attempting to read the resource
- Closed
- relates to
-
JBEAP-6776 [GSS](7.0.z) Unable to load job xml in jar files inside WAR (and EAR)
- Closed
-
JBEAP-6777 [GSS](7.1.0) Unable to load job xml in jar files inside WAR (and EAR)
- Closed