[jboss-jira] [JBoss JIRA] (WFLY-4988) Can't load job from another jar inside ear

[Daniele Pirola (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092081#comment-13092081 ] 

Daniele Pirola commented on WFLY-4988:
--------------------------------------

I'm not able to see jobs in CLI because I suspect there is a bug in retrieving deployment and subdeployment information. Perhaps I have a not common installation but I think I didn't done nothing so strange. I have a domain controller (in host 1) and (currently) one slave host controller (in host 2). I have currently 3 server groups with one server for each started in both the 2 hosts, 1 ear installed per server. The ears deployed inside servers are naturally different (physical names) BUT must have the same deployment name because belong to the same lookup pattern inside my code. So I configured the different deployments to have the same runtime-name.
Now when I go to the wildfly console I don't see any subdeployment inside the deployment=my-physical-name.ear, I see this NPE inside log:

2015-07-23 10:54:23,469 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 154) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("deployment" => "alploy-loyaltybe.ear"),
    ("subdeployment" => "loyalty-bundle.jar"),
    ("subsystem" => "batch"),
    ("job" => "RESOURCE_BUNDLE_JOB")
]): java.lang.NullPointerException
        at org.wildfly.extension.batch.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:45)
        at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174) [wildfly-controller-1.0.0.Final.jar:1.0.0.Final]
        at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137) [wildfly-controller-1.0.0.Final.jar:1.0.0.Final]

Notice that code tries to search the deployment with name alploy-loyaltybe.ear, the physical name of my ear but I debug and inside org.jboss.msc.service.ServiceContainerImpl the service is registered (correctly IMO) with the runtime-name of the ear.
This is of course not directly related with batch or jberet framework.

> 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
>
> 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
(v6.3.15#6346)