I seem to have hit a stumbling block with defining the thread-pool. When I use the an UnboundedQueueThreadPool from the threads subsystem I get errors when executing a second deployment. The error is; 17:12:39,809 ERROR [org.jberet.util] (batch-batch - 3) jberet000018: Failed to run job chunkPartition, , org.jberet.job.model.Job@e3527afd: java.lang.IllegalStateException: jberet000001: Failed to create artifact with ref name chunkPartitionAnalyzer. Ensure CDI beans.xml is present and batch.xml, if any, is configured properly. at org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:196) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.runner.StepExecutionRunner.initPartitionConfig(StepExecutionRunner.java:355) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.runner.StepExecutionRunner.<init>(StepExecutionRunner.java:85) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:155) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:87) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:55) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_60] at org.jboss.threads.JBossThread.run(JBossThread.java:122) Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for ModuleClassLoader for Module "deployment.batch-flow.war:main" from Service Module Loader. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.jboss.weld.Container.instance(Container.java:65) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:769) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:89) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:730) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:750) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:73) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01] at org.wildfly.jberet.WildFlyArtifactFactory.create(WildFlyArtifactFactory.java:54) [wildfly-jberet-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.jberet.creation.ArtifactFactoryWrapper.create(ArtifactFactoryWrapper.java:39) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] at org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:194) [jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3] ... 11 more Note that it's using the wrong ModuleClassLoader for some reason. I'm not sure if the thread is being created with the TCCL from the first deployment and being cached or what. I'll dig in more, but maybe you know off the top of your head. If I use the ee.ConcurrentService for the default managed executor service everything seems to work fine. I'm attaching the full server.log so you can see it if you'd like. This is the specific commit for the changes https://github.com/jamezp/wildfly/commit/9d94d842a01e03059bf4b62058e062de... the branch is https://github.com/jamezp/wildfly/compare/WFLY-508-WFLY-1680-c. -- James R. Perkins Red Hat JBoss Middleware _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev