[
https://issues.jboss.org/browse/WFLY-4988?page=com.atlassian.jira.plugin....
]
James Perkins commented on WFLY-4988:
-------------------------------------
The pull request allows job XML files in a JAR in a WAR's `lib` directory to be
resolved. It also allows all modules of an `EAR` to see job XML files in libraries in
it's `lib` directory. Also `EAR` modules will be able to see job XML files in
dependent modules.
Can't load job from another jar inside ear
------------------------------------------
Key: WFLY-4988
URL:
https://issues.jboss.org/browse/WFLY-4988
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: Daniele Pirola
Assignee: James Perkins
Priority: Critical
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
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)