[jboss-jira] [JBoss JIRA] (WFLY-4139) Batch module dependencies not configured for valid deployments

[Cheng Fang (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang updated WFLY-4139:
-----------------------------
    Description: 
In BatchEnvironmentProcessor the Batch subsystem only adds a dependency on wildfly's transaction manager and bean manager if some marker files are detected. (See here)

https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/extension/src/main/java/org/wildfly/extension/batch/deployment/BatchEnvironmentProcessor.java#L73

If they are not detected an unhelpful exception is thrown when instantiating the JobOperator:

{noformat}
01:18:25,442 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war")
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 248.119 sec <<< FAILURE! - in io.machinecode.chainlink.ee.wildfly.WildFlyTest
testGlassfish(io.machinecode.chainlink.ee.wildfly.WildFlyTest)  Time elapsed: 0.336 sec  <<< ERROR!
java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider org.jberet.operations.JobOperatorImpl could not be instantiated
	at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment.getArtifactFactory(BatchEnvironmentService.java:123)
	at org.wildfly.jberet.DelegatingBatchEnvironment.getArtifactFactory(DelegatingBatchEnvironment.java:52)
	at org.jberet.operations.JobOperatorImpl.<init>(JobOperatorImpl.java:89)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57)
	at io.machinecode.chainlink.ee.wildfly.WildFlyTest.testGlassfish(WildFlyTest.java:36)
{noformat}

There are valid reasons that these marker files may not be in the deployment, an example being that the deployment might only read metadata from jobs started by other deployments from the configured repository. This check also does not take into account jars in a war's lib dir (for example if you try and run a test using arquillian) or in an ear, which should be allowed.

I think there should be two changes. Firstly, those dependencies should be added unconditionally as there are cases where these marker will not be present and they will still be required. Secondly, the exception thrown because the beanManager has not been configured should be thrown earlier in the lifecycle where it will generate a real error message (perhaps in BatchEnvironmentService#start before creating the WildFlyBatchEnvironment where it can first be detected):

https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/jberet/src/main/java/org/wildfly/jberet/services/BatchEnvironmentService.java#L71

  was:
In BatchEnvironmentProcessor the JBatch subsystem only adds a dependency on wildfly's transaction manager and bean manager if some marker files are detected. (See here)

https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/extension/src/main/java/org/wildfly/extension/batch/deployment/BatchEnvironmentProcessor.java#L73

If they are not detected an unhelpful exception is thrown when instantiating the JobOperator:

{noformat}
01:18:25,442 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war")
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 248.119 sec <<< FAILURE! - in io.machinecode.chainlink.ee.wildfly.WildFlyTest
testGlassfish(io.machinecode.chainlink.ee.wildfly.WildFlyTest)  Time elapsed: 0.336 sec  <<< ERROR!
java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider org.jberet.operations.JobOperatorImpl could not be instantiated
	at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment.getArtifactFactory(BatchEnvironmentService.java:123)
	at org.wildfly.jberet.DelegatingBatchEnvironment.getArtifactFactory(DelegatingBatchEnvironment.java:52)
	at org.jberet.operations.JobOperatorImpl.<init>(JobOperatorImpl.java:89)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57)
	at io.machinecode.chainlink.ee.wildfly.WildFlyTest.testGlassfish(WildFlyTest.java:36)
{noformat}

There are valid reasons that these marker files may not be in the deployment, an example being that the deployment might only read metadata from jobs started by other deployments from the configured repository. This check also does not take into account jars in a war's lib dir (for example if you try and run a test using arquillian) or in an ear, which should be allowed.

I think there should be two changes. Firstly, those dependencies should be added unconditionally as there are cases where these marker will not be present and they will still be required. Secondly, the exception thrown because the beanManager has not been configured should be thrown earlier in the lifecycle where it will generate a real error message (perhaps in BatchEnvironmentService#start before creating the WildFlyBatchEnvironment where it can first be detected):

https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/jberet/src/main/java/org/wildfly/jberet/services/BatchEnvironmentService.java#L71



> Batch module dependencies not configured for valid deployments
> --------------------------------------------------------------
>
>                 Key: WFLY-4139
>                 URL: https://issues.jboss.org/browse/WFLY-4139
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
>         Environment: Fedora 19, JDK 8u25, wildfly-dist:9.0.0.Alpha1
>            Reporter: Brent Douglas
>            Assignee: Jason Greene
>
> In BatchEnvironmentProcessor the Batch subsystem only adds a dependency on wildfly's transaction manager and bean manager if some marker files are detected. (See here)
> https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/extension/src/main/java/org/wildfly/extension/batch/deployment/BatchEnvironmentProcessor.java#L73
> If they are not detected an unhelpful exception is thrown when instantiating the JobOperator:
> {noformat}
> 01:18:25,442 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war")
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 248.119 sec <<< FAILURE! - in io.machinecode.chainlink.ee.wildfly.WildFlyTest
> testGlassfish(io.machinecode.chainlink.ee.wildfly.WildFlyTest)  Time elapsed: 0.336 sec  <<< ERROR!
> java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider org.jberet.operations.JobOperatorImpl could not be instantiated
> 	at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment.getArtifactFactory(BatchEnvironmentService.java:123)
> 	at org.wildfly.jberet.DelegatingBatchEnvironment.getArtifactFactory(DelegatingBatchEnvironment.java:52)
> 	at org.jberet.operations.JobOperatorImpl.<init>(JobOperatorImpl.java:89)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
> 	at java.lang.Class.newInstance(Class.java:438)
> 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 	at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57)
> 	at io.machinecode.chainlink.ee.wildfly.WildFlyTest.testGlassfish(WildFlyTest.java:36)
> {noformat}
> There are valid reasons that these marker files may not be in the deployment, an example being that the deployment might only read metadata from jobs started by other deployments from the configured repository. This check also does not take into account jars in a war's lib dir (for example if you try and run a test using arquillian) or in an ear, which should be allowed.
> I think there should be two changes. Firstly, those dependencies should be added unconditionally as there are cases where these marker will not be present and they will still be required. Secondly, the exception thrown because the beanManager has not been configured should be thrown earlier in the lifecycle where it will generate a real error message (perhaps in BatchEnvironmentService#start before creating the WildFlyBatchEnvironment where it can first be detected):
> https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/jberet/src/main/java/org/wildfly/jberet/services/BatchEnvironmentService.java#L71



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)