I have a WAR application that includes a JAR library. The JAR library contains the Batch Job and the Batch Artifacts (META-INF/batch-jobs/...
). The WAR app includes this jar as a library and defines a JAX-RS Service that allows to clients to invoke the batch job calling the JobOperator
Interface...
When i run this deployment, the JSR 352 implementation (JBeret) keeps complaining that the Job cannot be found anyware when the JobOperator Interface is called... However, if the Batch Job and the Batch Artifacts are included as classes of the WAR deployment, everything runs smoothly...
So, what is the problem?
After a "little" research, i found the answer (dispersed) in the following links:
Wildfly Issues
Mailing list
Briefly, In order to put this kind of deployment to work, you have to modify the deployment that calls the Job Operator interface to invoke the requested Job (in my case, it was the WAR File)... These are the modifications:
Include an "empty" batch-jobs
folder under the META-INF
folder. (I guess the empty is optional, because i have to put a README file under that folder to prevent GIT from removing such folder)
Define a ServiceLoader
(file) under META-INF/services
folder. This ServiceLoader (file) must be called: org.jberet.spi.JobXmlResolver
and should contain the following implementation as content: org.jberet.tools.MetaInfBatchJobsJobXmlResolver
That's all.
The WildFly issue (https://issues.jboss.org/browse/WFLY-7000, similar to the one mentioned above, but is a different one) has been fixed, and should address your point 1 (having to use empty batch-jobs/ directory).