Coder Social home page Coder Social logo

jberet / jsr352 Goto Github PK

View Code? Open in Web Editor NEW
124.0 15.0 76.0 75.06 MB

Implementation of Jakarta Batch Specification and API

License: Eclipse Public License 2.0

Java 97.86% Groovy 0.13% JavaScript 1.70% PHP 0.04% Python 0.11% Ruby 0.11% Scala 0.06%
batch batch-processing jakarta java

jsr352's Introduction

JBeret logo

JBeret is an implementation of Jakarta Batch. It is also included in WildFly, the new and improved JBoss Application Server to provide portable batch processing support in Jakarta EE environment.

Build JBeret

To build and run default set of tests:

mvn install

Some tests require additional steps and thus are not included in the default run. For instance, MongoDB-related tests need to start MongoDB first. To build and run all tests:

# start MongoDB database
mongod

# build JBeret, activate allTests maven profile to run all tests
mvn install -DallTests

Some tests involves very large data set (e.g., over 1 million rows of CSV or Excel data), and may cause memory errors in some machines:

OutOfMemoryError: unable to create new native thread

Increase ulimit to avoid such errors. For example,

ulimit -u 2048add

JBeret Modules:

  • jberet-core: core batch runtime engine
  • jberet-se: impl classes specific to Java SE runtime environment
  • jberet-support: a collection of reusable batch readers and writers (e.g., CSV, fixed length, Excel, Json, XML, Mongo, JDBC, JMS, HornetQ, PDF, etc) for batch applications, and JNDI support
  • jberet-rest-api: REST API for batch job management
  • jberet-ui: front-end UI web app for batch job management
  • jberet-se-bom: a maven BOM to encapsulate all the dependencies required by JBeret Java SE.
  • test-apps: test applications
  • tck-porting-impl: support running Jakarta Batch TCK with JBeret in Java SE
  • wildfly-jberet-samples: Sample batch processing apps that can be deployed to WildFly or JBoss EAP 7
  • quarkus-jberet: The Quarkus JBeret Extension adds support for Jakarta Batch applications

3rd-party & Community Extensions:

Project Resources:

Batch sample & test applications:

  • https://github.com/jberet/jberet-wildfly-samples, web apps that demonstrate the following:
    • JsonItemReader, JsonItemWriter
    • CsvItemReader, CsvItemWriter
    • XmlItemReader, XmlItemWriter
    • MongoItemReader, MongoItemWriter
    • JNDI lookup of Jackson JsonFactory, MappingJsonFactory & XmlFactory in WildFly for batch reader and writer
    • JNDI lookup of MongoClient in WildFly
    • job xml files showing the use of various reader/writer configuration properties
    • jberet-support module can be installed in WildFly and referenced by multiple apps via either MANIFEST.MF or jboss-deployment-structure.xml
  • https://github.com/jberet/jsr352/tree/main/test-apps
    • test apps running in Java SE environment to verify core batch requirements
    • test apps running in Java SE environment to verify additional JBeret features (inheritance, scripting support, infinispan job repository, etc)

org.jberet artifacts may be retrieved from Maven Central or JBoss Public Repository

<repositories>
    <repository>
        <id>jboss-public-repository-group</id>
        <name>JBoss Public Repository Group</name>
        <url>https://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>
...
<dependencies>
        <dependency>
            <groupId>jakarta.batch</groupId>
            <artifactId>jakarta.batch-api</artifactId>
            <version>${version.jakarta.batch.batch-api}</version>
            <scope>provided</scope>
        </dependency>

    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-core</artifactId>
        <version>1.0.2.Final</version> <!-- replace it with the desired version -->
    </dependency>
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-support</artifactId>
        <version>1.0.2.Final</version> <!-- replace it with the desired version -->
    </dependency>

Batch application dependencies

Minimal application dependencies:
    <dependency>
            <groupId>jakarta.batch</groupId>
            <artifactId>jakarta.batch-api</artifactId>
        </dependency>
    <dependency>
        <groupId>javax.inject</groupId>
        <artifactId>javax.inject</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.enterprise</groupId>
        <artifactId>cdi-api</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.transaction</groupId>
        <artifactId>jboss-transaction-api_1.2_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.marshalling</groupId>
        <artifactId>jboss-marshalling</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.logging</groupId>
        <artifactId>jboss-logging</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.weld</groupId>
        <artifactId>weld-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.wildfly.security</groupId>
        <artifactId>wildfly-security-manager</artifactId>
    </dependency>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
    </dependency>

A note on webapp or Jakarta EE application packaging: Jakarta EE API jars are already available in the appserver, and should not be included in WAR, JAR, or EAR files. Their maven dependency scope should be set to provided. In addition, if the application is deployed to JBoss EAP or WildFly, almost all of the above dependencies are already available as JBoss modules, and should not be duplicated in application package.

maven BOM dependency used to encapsulate all the dependencies required by JBeret Java SE.
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jberet</groupId>
            <artifactId>jberet-se-bom</artifactId>
            <version>2.1.2.Final-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
The following is also required for Java SE batch applications (h2 can be omitted when using in-memory batch job repository):
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-se</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.weld.se</groupId>
        <artifactId>weld-se</artifactId>
    </dependency>
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
    </dependency>
Optional application dependencies depending on application usage:
    <!-- any JDBC driver jars, e.g., h2, when using jdbc batch job repository -->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
    </dependency>

     <!-- infinispan and jgroups jars, when infinispan job repository is used.
          Additional infinispan cachestore jars (e.g., infinispan-cachestore-jdbc, infinispan-cachestore-mongodb,
          infinispan-cachestore-leveldb, infinispan-cachestore-rest, infinispan-cachestore-cassandra, etc) may be
          needed if such a cachestore is used. -->
     <dependency>
         <groupId>org.infinispan</groupId>
         <artifactId>infinispan-core</artifactId>
     </dependency>
     <dependency>
         <groupId>org.infinispan</groupId>
         <artifactId>infinispan-commons</artifactId>
     </dependency>
     <dependency>
         <groupId>org.jgroups</groupId>
         <artifactId>jgroups</artifactId>
     </dependency>

     <!-- MongoDB jars, when MongoDB job repository is used -->
     <dependency>
         <groupId>org.mongodb</groupId>
         <artifactId>mongo-java-driver</artifactId>
         <version>${version.org.mongodb.mongo-java-driver}</version>
         <scope>provided</scope>
     </dependency>

    <!-- replace Java built-in StAX provider with aalto-xml or woodstox
         (woodstox dependencies not shown here)
    -->
    <dependency>
        <groupId>com.fasterxml</groupId>
        <artifactId>aalto-xml</artifactId>
    </dependency>
    <dependency>
        <groupId>org.codehaus.woodstox</groupId>
        <artifactId>stax2-api</artifactId>
    </dependency>
    
    <!-- jberet-support includes common reusable batch ItemReader & ItemWriter classes for
         various data types such as CSV, XML, JSON, Fixed length, Excel, MongoDB, JDBC, JMS, HornetQ, etc.
         The application should further provide appropriate transitive dependencies from 
         jberet-support, depending on its usage.
    -->
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-support</artifactId>
    </dependency>

jsr352's People

Contributors

bryant1410 avatar chengfang avatar dascheid avatar dependabot[bot] avatar elguardian avatar iweiss avatar jamezp avatar jianajavier avatar jmartisk avatar liweinan avatar luck3y avatar mobe91 avatar moulalis avatar nuzayats avatar panossot avatar parsharma avatar paulkeogh avatar radcortez avatar ranabirchakraborty avatar stuartwdouglas avatar tomashofman avatar zerrossetto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jsr352's Issues

StepListener.afterStep() should also be called in case of exceptions inside the step

Please see also: WASdev/standards.jsr352.jbatch#21

According to section 9.2.2 of the spec:

A step listener can receive control before and after a step runs, and also if an exception is thrown during step processing.

So in contrast to my comment in #25, the spec is quite clear about this topic and the afterStep() method should also be called in case of exceptions.

Currently JBeret does not call the afterStep() method in case of exceptions, so this should be adjusted.

NoSuchJobException

We have a WAR containing jberet-ui + jberet-rest (plus dependencies, as you can see in the attached pom) resources exposed with a REST application (by annotation). JBeret-UI API url points to the very war itself (because the war itself exposes the rest resources as already said).

Then we have an EAR containing the previous defined WAR and an EJB module (among other things) containing some Batchlets.

In summary : we are sure we have jberet-ui pointing to jberet-rest apis exposed in a war inside an ear with several batchlet.

Then we try to start some of these batchlet using jberet-ui and this actually works (the job starts and works without problem but an error is print in log and is shown in the user interface, screenshot attached) :

2018-01-08 15:01:13,441 WARN [org.jberet.rest-api] (default task-45) JBERET071000: Exception occurred when accessing JBeret Rest API:: javax.batch.operations.NoSuchJobException: WFLYBATCH000005: The job name 'importTreatmentCsv' was not found for the deployment.
at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.validateJob(JobOperatorService.java:404)
at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobInstance(JobOperatorService.java:282)
at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecution(JobOperatorService.java:308)
at org.jberet.operations.DelegatingJobOperator.getJobExecution(DelegatingJobOperator.java:97)
at org.jberet.rest.service.JobService.start(JobService.java:60)
at org.jberet.rest.resource.JobResource.start(JobResource.java:72)
at org.jberet.rest.resource.JobResource$Proxy$_$$_WeldClientProxy.start(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:209)
at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:244)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:209)
at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:244)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

2018-01-08 15:01:13,688 INFO [org.visiontech.batch.AbstractImportEntityBatchlet] (Batch Thread - 2) COMPLETED

As you can see at the end of the log the job actually worked and completed.

Something is not right, obliviously.
The UI itself can't refresh showing the jobs ...

I think this bug may be related to both rest rest-api and ui.

Can you help us ?

image
pom.zip

IllegalAccessError when instantiate StepBuilder

Hi there!

I'm facing issues when trying instantiate a StepBuilder.

StepBuilder stepBuilder = new StepBuilder("foo" + i);

Then I recieve the following stack trace:

16:44:44,158 ERROR [org.quartz.core.JobRunShell] (DefaultQuartzScheduler_Worker-1) Job DEFAULT.Foo threw an unhandled Exception: : java.lang.IllegalAccessError: tried to access method org.jberet.job.model.Chunk.<init>()V from class org.jberet.job.model.StepBuilder
    at org.jberet.job.model.StepBuilder.<init>(StepBuilder.java:97) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at footasks.Foo.execute(Foo.java:50) [classes:]
    at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [quartz-2.2.1.jar:]
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [quartz-2.2.1.jar:]

16:44:44,160 ERROR [org.quartz.core.ErrorLogger] (DefaultQuartzScheduler_Worker-1) Job (DEFAULT.Foo threw an exception.: org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.IllegalAccessError: tried to access method org.jberet.job.model.Chunk.<init>()V from class org.jberet.job.model.StepBuilder]
    at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz-2.2.1.jar:]
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [quartz-2.2.1.jar:]
Caused by: java.lang.IllegalAccessError: tried to access method org.jberet.job.model.Chunk.<init>()V from class org.jberet.job.model.StepBuilder
    at org.jberet.job.model.StepBuilder.<init>(StepBuilder.java:97) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at footasks.Foo.execute(Foo.java:50) [classes:]
    at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [quartz-2.2.1.jar:]
    ... 1 more

It's seens very strange, because, the constructor of Chunk have package modifier, and the StepBuilder is in the same package.

Can anyone help me?

Ps.: I'm running in Wildfly 8.1.0

PurgeBatchlet and Wildfly 10

The sql and sqlFile batch properties of org.jberet.repository.PurgeBatchlet don't work when jberet is used with Wildfly because the JobRepository is an instance of org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService and not an instance of org.jberet.repository.JdbcRepository.

So, the condition if (jobRepository instanceof JdbcRepository) that starts the purge of the persistent store is never true.

So far i understand that Wildfly needs to extend the functionality of the JobRepository and since the JdbcRepository is marked as final that is done with a wrapper. I think that this behaviour should be expected and so directly handled inside jberet but I have not still found a good solution.

So, what are your thoughts about this?
Thank you.

Checkpoints must be set after skipped item

As discussed in WASdev/standards.jsr352.batch-spec#15 it is necessary that checkpoints get also update after skipping an item. Otherwise the skipped item might be read again when processing the next chunk.

You can easily test this behavior by adding a test to ChunkSkipRetryIT:

    @Test
    public void retrySkipWrite0to10() throws Exception {
        params.setProperty("writer.fail.on.values", "0,1,2,3,4,5,6,7,8,9,10");
        params.setProperty("repeat.failure", "true");
        final ArrayList<List<Integer>> expected = new ArrayList<List<Integer>>();

        // 0 - 10 failed, re-written and failed and skipped
        expected.add(asList(11));
        expected.add(asList(12));
        expected.add(asList(13));
        expected.add(asList(14));
        expected.add(asList(15));
        expected.add(asList(16));
        expected.add(asList(17));
        expected.add(asList(18));
        expected.add(asList(19));
        expected.add(asList(20, 21, 22, 23, 24, 25, 26, 27, 28, 29));

        runTest(chunkSkipRetryXml, expected);
        // 20: read first 10 in first try, read again in retry 
        // +20: read second 10 in first try, read again in retry 
        // +10: read third 10 in first try, no retry needed
        verifyMetric(Metric.MetricType.READ_COUNT, 20 + 20 + 10);
        verifyMetric(Metric.MetricType.READ_SKIP_COUNT, 0);
        verifyMetric(Metric.MetricType.PROCESS_SKIP_COUNT, 0);
        verifyMetric(Metric.MetricType.WRITE_SKIP_COUNT, 11);
        verifyMetric(Metric.MetricType.ROLLBACK_COUNT, 1);
    }

In this test the verifyMetric for READ_COUNT fails because the read count is 60 instead of 50. Thats because all the first 10 items of the first chunk failed and were skipped. As long as there is no checkpoint update after skip there is no checkpoint while processing the fist 10 items. After starting with the next chunk again an exception occures and the reader is rolled back to the previous checkpoint. Because there is no checkpoint yet it reads the fist items again.

Imagine if there are many failing items it would read a lot of items again and again.

Transaction cannot proceed: STATUS_MARKED_ROLLBACK

Hi, I am experiencing the above error which is very similar to the following issue: https://issues.jboss.org/browse/JBERET-179

When I am reading or processing an item within chunk, the transaction might be marked as roll back only somewhere in bussiness method due to an exception. When the exception is skippable, JBeret does not take any action in case of readItem() nor processItem() methods in ChunkRunner and continues to use the transaction marked for rollback in another chunk round.

The expected behavior would be, similarly to what is done in doCheckpoint(), to roll back the transaction and to begin it again before the new round of the chunk starts:

if (tm.getStatus() == Status.STATUS_MARKED_ROLLBACK) {
	tm.rollback();
	tm.begin();
}

parameterType for Complex Type

It is supported yet?

Let's say you have <property name="parameterNames" value="id, phone, contact.Name"/>. I'm interested on being able to fetch the value contact.Name

Inconsistent BatchStatus after database connection loss

If during execution of a job the database connectivity gets lost and the job completes with error,
javax.batch.operations.JobOperator#getRunningExecutions still returns that job execution.

Environment:

  • Wildfly 16.0.0.Final
  • JDBC Job Repository
  • A Business Application deployed in a WAR uses javax.batch.operations.JobOperator

Steps to reproduce:

  1. Start Job X, note the job's execution ID
  2. Before Job X completes, shutdown the database related to the JDBC Job Reporoistoty
  3. Wait until Job X completes with error (as the Batch Runtime cannot commit Job's final state FAILED to the database)
  4. Turn the database on
  5. Call javax.batch.operations.JobOperator#getRunningExecutions(String jobName)
    Expected: javax.batch.operations.JobOperator#getRunningExecutions DOES NOT return execution ID from step 1
    Actual: javax.batch.operations.JobOperator#getRunningExecutions DOES return execution ID from step 1
  6. Call javax.batch.operations.JobOperator#getJobExecution(long executionId)
    Expected: the returned JobExecution has the state FAILED
    Actual: the returned JobExecution has the state FAILED

Support additional Serialization mechanisms

For SVM native image, Java Serialization is not supported yet.

We can workaround this, by use SVM Substitute with a supported Serialization mechanism (Jsonb for instance).

Unfortunately, this still raises an issue of different behaviours between the JVM and SVM executions, plus if using a persistent repository the data serialization is incompatible.

Ideally, we could support different Serialization mechanisms in JBeret and pick which one to use with a configuration. You won't be able to change Serialization after the first execution with a persistent store, but at least it would allow you to keep consistency between the JVM and SVM.

ChunkRunner call itemReader.checkpointInfo() for every read

JSR specify that checkpointInfo on ItemReader will be called before checkpoint commit, but jberet implementation call the method for every read and if rollback occurs in chunk processing the checkpoint info stored for the ItemReader is not correct

NPE in retry after a partitioned chunk

(targets jberet 1.2.0.final)

We have a partitioned chunk step (let's say step2) following another partitioned chunk step "step1" (using the same mapper but I don't think this relevant). The mapper is in override = false mode.

When a step1 partition fails and the job is restarted, the step1 finishes (the only remaining partition is completed) but when the step2 begins, we get the NPE provided in [1].

In StepExecutionRunner.beginPartition(), the decision to read again the previous context of the step is given by : final boolean isRestartNotOverride = isRestart && !isOverride;
but in our case, the step2 returns a null context as it has never been launched.

A workaround we use successfully (in the partitions mapper) :

StepExecutionImpl originalStepExec = ((StepContextImpl) stepContext)
                .getOriginalStepExecution();
plan.setPartitionsOverride(originalStepExec == null);

Thanks, KUTGW
[1]

15:32:30,049 WARN  [org.jberet] (Batch Thread - 3) JBERET000018: Could not find the original step execution to restart.  Current step execution id: 0, step name: ajouter_metadonnees
15:32:30,051 ERROR [org.jberet] (Batch Thread - 3) JBERET000007: Failed to run job collecterAtlas, ajouter_metadonnees, org.jberet.job.model.Step@164a6d81: java.lang.NullPointerException
    at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:256) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:216) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:140) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runJobElement(CompositeExecutionRunner.java:128) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:196) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runJobElement(CompositeExecutionRunner.java:128) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:196) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:59) [jberet-core-1.2.0.Final.jar:1.2.0.Final]
    at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:193) [eap6-jberet-1.0.3-SNAPSHOT.jar:1.0.3-SNAPSHOT]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_80]
    at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_80]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Support Java 17

One of the main issues right now is with the WildflySecurityManager.

Maybe we should remove it altogether?

NPE in partitioned chunk processing

I got this exception executing a partitioned chunk with 8 partition and 8 thread (same step with 4 thread give no exception!)

ERROR [org.jberet] (Batch Thread - 10) JBERET000007: Failed to run job [job_name] [step_name], org.jberet.job.model.Chunk@4a7e8c98: java.lang.NullPointerException
    at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:332) [rt.jar:1.8.0_05]
    at org.jberet.runtime.runner.ChunkRunner.run(ChunkRunner.java:206) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
    at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:144) [wildfly-jberet-8.1.0.Final.jar:8.1.0.Final]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

WELD-001408: Unsatisfied dependencies for type X with qualifiers @Default

I'm working on the Hibernate Search project which deploys a JSR 352 batch job via a module added to WildFly rather than through a deployed application. This batch job should then be usable from applications which declare a dependency to that module, e.g. my arquillian test PerformanceIT.java:

@RunWith(Arquillian.class)
public class PerformanceIT {

    @Deployment
    public static WebArchive createDeployment() {
        WebArchive war = ShrinkWrap.create( WebArchive.class, PerformanceIT.class.getSimpleName() + ".war" )
                .addAsWebInfResource( "jboss-deployment-structure.xml", "/jboss-deployment-structure.xml" )
                .addAsResource( "META-INF/persistence.xml" )
                .addAsWebInfResource( EmptyAsset.INSTANCE, "beans.xml" )
                .addPackage( Company.class.getPackage() );
        return war;
    }
    ...
}

When the WildFly-10.0.0.Final was launched, the job xml had been found. However, I got the below errors. I'm very new in this field and I don't how to fix it. Do these errors mean the producers of JobContext / StepContext / BatchProperty do not have bean defining annotations? Any help will be very appreciated, thx!

Mincong

14:28:18,053 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."PerformanceIT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."PerformanceIT.war".WeldStartService: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 10 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext
  at org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext(JobContextSetupListener.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type int with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition
  at org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition(PartitionMapper.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart
  at org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart(BeforeChunkBatchlet.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable
  at org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable(EntityReader.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm.<init>(CheckpointAlgorithm.java:36)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer.<init>(LuceneDocProducer.java:71)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector.<init>(ProgressCollector.java:34)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter.<init>(LuceneDocWriter.java:67)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator(JobContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator.<init>(ProgressAggregator.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet(JobContext)
  at org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet.<init>(AfterChunkBatchlet.java:50)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)

    at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:76)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:479)
    at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:446)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
    at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
    ... 3 more

14:28:18,071 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "PerformanceIT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"PerformanceIT.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"PerformanceIT.war\".WeldStartService: Failed to start service
    Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 10 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext
  at org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext(JobContextSetupListener.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type int with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition
  at org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition(PartitionMapper.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart
  at org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart(BeforeChunkBatchlet.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable
  at org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable(EntityReader.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm.<init>(CheckpointAlgorithm.java:36)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer.<init>(LuceneDocProducer.java:71)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector.<init>(ProgressCollector.java:34)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter.<init>(LuceneDocWriter.java:67)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator(JobContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator.<init>(ProgressAggregator.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet(JobContext)
  at org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet.<init>(AfterChunkBatchlet.java:50)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
"}}
14:28:18,076 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "PerformanceIT.war" was rolled back with the following failure message: 
{"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"PerformanceIT.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"PerformanceIT.war\".WeldStartService: Failed to start service
    Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 10 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext
  at org.hibernate.search.jsr352.internal.JobContextSetupListener.jobContext(JobContextSetupListener.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type int with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition
  at org.hibernate.search.jsr352.internal.steps.lucene.PartitionMapper.rowsPerPartition(PartitionMapper.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart
  at org.hibernate.search.jsr352.internal.steps.beforeChunk.BeforeChunkBatchlet.purgeAtStart(BeforeChunkBatchlet.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type boolean with qualifiers @BatchProperty
  at injection point [BackedAnnotatedField] @Inject @BatchProperty private org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable
  at org.hibernate.search.jsr352.internal.steps.lucene.EntityReader.cacheable(EntityReader.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.CheckpointAlgorithm.<init>(CheckpointAlgorithm.java:36)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocProducer.<init>(LuceneDocProducer.java:71)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector(StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressCollector.<init>(ProgressCollector.java:34)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StepContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter(JobContext, StepContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.LuceneDocWriter.<init>(LuceneDocWriter.java:67)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator(JobContext)
  at org.hibernate.search.jsr352.internal.steps.lucene.ProgressAggregator.<init>(ProgressAggregator.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JobContext with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet(JobContext)
  at org.hibernate.search.jsr352.internal.steps.afterChunk.AfterChunkBatchlet.<init>(AfterChunkBatchlet.java:50)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
"}}

According JBeret specification JBeret should be able to @Inject @BatchProperty File file, but it works only in special curcumstance.

I have a class as follows:

public class FileListPartitionMapper implements PartitionMapper {

private static final String FILE_NAME = "fileName";

@Inject
@BatchProperty(name = "fileNamePattern")
private String fileNamePattern;

@Inject
@BatchProperty(name = "importPath")
private String importPath;

/*

  • (non-Javadoc)
  • @see javax.batch.api.partition.PartitionMapper#mapPartitions()
    */
    @OverRide
    public PartitionPlan mapPartitions() throws Exception {
List<File> matchedFiles = Files.list(Paths.get(importPath)).map(Path::toFile).filter(File::isFile).filter(file -> file.getName().matches(fileNamePattern))
    .collect(Collectors.toList());

PartitionPlan partitionPlan = new PartitionPlanImpl();
partitionPlan.setThreads(10);

int partitionNumber = matchedFiles.size();
partitionPlan.setPartitions(partitionNumber);

Properties[] partitionProperties = new Properties[partitionNumber];
partitionPlan.setPartitionProperties(partitionProperties);

for (int indexPartition = 0; indexPartition < partitionNumber; indexPartition++) {
  Properties prop = new Properties();
  // prop.setProperty(FILE_NAME, matchedFiles.get(indexPartition).getPath()); // Set Property as String is commented out here.
  prop.put(FILE_NAME, matchedFiles.get(indexPartition)); // Hier I am putting the file object in the Properteis, as Properties backed by Map<Object, Object> it must be okay.
  partitionProperties[indexPartition] = prop;
}

return partitionPlan;

}
}

My Reader class looks as follows (for simplification I removed most of the code except Injection point).

public class FileReader implements ItemReader {

private static final String FILE_NAME = "fileName";

@Inject
@BatchProperty(name = FILE_NAME)
private File file; // Here the file Object is null

....
}

Now if I commented out the following line in my FileListPartitionMapper class, as follows:
prop.setProperty(FILE_NAME, matchedFiles.get(indexPartition).getPath()); // this method except only String key and String value.

and commented in the following line:
prop.put(FILE_NAME, matchedFiles.get(indexPartition));

then in my FileReader class, the file-object is not null anymore.

Short conclusion of the Problem is as follows: if we use properties.setProperty(String key, String value), then @Inject @BatchProperty works fine, whereas properties.put(Object key, Object value) is preferrable but DOES NOT work.

However, I did more investigation and I found that JBeret uses "org.jberet.job.model.Properties", which uses only String key and String value. Hence it expects java.util.Properties must hold String key and String value.

user guide

The link to the JBeret user guide / documentation is dead. It just goes to the gitbook site.

gulp build doesn't exit

as title says

the problem is related to this piace of code inside bundle task

   return b.bundle()
    .on('error', plugins.util.log.bind(plugins.util, 'Browserify Error'))
    .pipe(source('bundle.js'))

    //minify with source map file
    .pipe(buffer())
    //.pipe(plugins.sourcemaps.init({loadMaps: true}))
    .pipe(plugins.if(!isDebug(), plugins.uglify()))
    // Add transformation tasks to the pipeline here.
    //.pipe(plugins.sourcemaps.write('./'))

    .pipe(gulp.dest(distDir));

inside gulpfile.js

please fix this, otherwise automatic building (without manually CTRL+C) would be impossible

thank you

Properties from PartitionPlan in Step partitioning

We can't access the properties of PartitionPlan built in PartitionMapper once in the step partitioned.
In StepExecutionRunner.beginPartition (), I patch JBeret to add to each "step1" in the iterations of the loop "partitionProperties" of the partition. (I had to create a converter Java.util Properties to JBeret Properties)

Now my reader can access the properties I have prepared in PartitionMapper by injecting StepContext.

Error restarting job when the file name differs from the attribute id. Using jdbc repository

In the restart method (JobOperatorImpl) if the repository does not found the job repository.getJob(jobName), it tries to load the job from the file. If the job name is different from the xml file name, the job file is not found.
Example:
META-INF/batch-jobs/calculate-interest.xml

<?xml version="1.0" encoding="UTF-8"?>
<job id="jbci" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">

Steps to reproduce error:

  1. Start Job and end the job with error or stop job only

    http://localhost:8080/batch-issuer/api/batch/start?name=jbci
    return executionId;

    public enum EJobsName implements IJobsName
    {
       jbci("calculate-interest", false, true);
    
  2. Stop server

  3. Start server

  4. Restart the job

http://localhost:8080/batch-issuer/api/batch/restart?executionId=XXX

The problem is in class JobOperatorImpl.java, with the following lines

Code

// the job may not have been loaded, e.g., when the restart is performed in a new JVM
final String jobName = originalToRestart.getJobName();
if (repository.getJob(jobName) == null) {
    final Job jobDefined = ArchiveXmlLoader.loadJobXml(jobName,  batchEnvironment.getClassLoader(), new ArrayList<Job>());
     repository.addJob(jobDefined);
}

StackTrace:

[ Message ] : FileNotFoundException: jbci.xml (El sistema no puede encontrar el archivo especificado)
[ Class ] : org.jberet.creation.ArchiveXmlLoader
[ Method ] : loadJobXml
[ Parameters ] : empty
[ Detail ] : java.io.FileNotFoundException: jbci.xml (El sistema no puede encontrar el archivo especificado)
at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_75]
at java.io.FileInputStream.(FileInputStream.java:146) [rt.jar:1.7.0_75]
at org.jberet.creation.ArchiveXmlLoader.getJobXml(ArchiveXmlLoader.java:145) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:86) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.operations.JobOperatorImpl.restart(JobOperatorImpl.java:205) [jberet-core-1.0.2.Final.jar:1.0.2.Final]

Exception if transaction timeout occured before partitions complete

If I run a partitioned step with a low transaction timeout (15s) all partitions run well, everyone in a separate transaction that stay alive for max 1s, but the partition analyzer loop is in a unique transaction so if timeout occured then at the end of all partition executions I got this exception:

While partition executions:

[com.arjuna.ats.arjuna](Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 in state RUN
[com.arjuna.ats.arjuna](Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 invoked while multiple threads active within it.
[com.arjuna.ats.arjuna](Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 aborting with 1 threads active!

Then at partitions end:

ERROR [org.jberet](Batch Thread - 10) JBERET000007: Failed to run job xxx, xxx, org.jberet.job.model.Step@3a6838f9: java.lang.IllegalStateException: BaseTransaction.rollback - ARJUNA016074: no transaction!
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:139) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:114)
at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:348) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:202) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:138) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:58) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:144) [wildfly-jberet-8.1.0.Final.jar:8.1.0.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)

ChunkListener onError method not invoked for open() and close() methods of ItemReader and ItemWriter

Hello JBeret-team,

we have some integration-tests running on WildFly 8.1 as well as Glassfish 4.

There is one test-case, where an exception is thrown in a chunk-step inside the ItemReader.open(..) method. There is a ChunkListener defined for that chunk-step, where we do some generic error-logging inside the onError(..) method.

In Glassfish 4 (which includes the JBatch reference implementation), the method ChunkListener.onError(..) method is called when the exception is thrown, while in WildFly 8.1 / JBeret, the onError(..) method is not invoked. The Apache BatchEE-implementation (fork of JSR352 RI), also still behaves like the original reference-implementation.

So currently, we have a different behavior of our batch jobs depending on the JSR352 implementation of the underlying JEE container.

After a look into the JSR352 spec, I am not 100% sure, which of the implementations shows the correct behavior. The inteface-definition for the CunkListener interface states the following:

/**
* The onError method receives control
* before the chunk transaction is rolled back.
* Note afterChunk is not invoked in this case.
* @param ex specifies the exception that
* caused the roll back.
* @throws Exception throw if an error occurs.
*/
public void onError(Exception ex) throws Exception;

If by "chunk transaction", only the "regular" chunk-transactions are meant (and not the two separate transactions for open() and close() of the reader and writer), then JBeret behaves correctly and the BatchEE-guys would have to adjust their implementation (in this case I would open a new ticket for them).

However, in this case, from my point of view, there is no possibility for implementing some generic exception-processing in form of a listener. We would have do implement our own exception-processing inside the open() and close() methods (catch, log, re-throw), which is not as generic as we would like it to be.

I think the "big" JSR352 implementations should at least show the same behavior here in order to ensure the portability of the applications. What do you think about this issue? Has this been discussed before?

Thanks & best regards

Mario Ködding

Mongo support for storing batch metadata?

I checked https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql and found that there is no mongo.ddl

my jberet.properties

job-repository-type=mongodb

# Optional, default is jdbc:h2:~/jberet-repo for h2 database as the default job repository DBMS.
# For h2 in-memory database, db-url = jdbc:h2:mem:test;DB_CLOSE_DELAY=-1
# For mongodb, db-url includes all the parameters for MongoClientURI, including hosts, ports, username, password,
# database name, and options.  The format of MongoClient uri:
#    mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]
# See MongoClientURI javadoc at http://api.mongodb.org/java/current/
# An example of MongoDB db-url = mongodb://localhost/testData
db-url = mongodb+srv://user:[email protected]/database
db-user =
db-password =
db-properties =

Is mongo db supported or did I misconfigured the properties?

Thanks

Annotation Exception for Rest API

I'm using wildfly 10 with the most recent jberet beta, I guess the XMLTransient needs to be removed?

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
Transient field "future" cannot have any JAXB annotations.
this problem is related to the following location:
at @javax.xml.bind.annotation.XmlTransient()
at org.jberet.schedule.JobSchedule

at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:106)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:460)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:292)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:139)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1138)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:392)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.<init>(JAXBContextWrapper.java:88)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.<init>(JAXBContextWrapper.java:113)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.createContextObject(XmlJAXBContextFinder.java:56)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBContextFinder.createContext(AbstractJAXBContextFinder.java:150)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.findCacheContext(XmlJAXBContextFinder.java:72)
at org.jboss.resteasy.plugins.providers.jaxb.CollectionProvider.writeTo(CollectionProvider.java:298)
... 42 more

JobOperatorImpl doesnt propagate status to repository

I noticed that JobOperatorImpl.abandon(...) doesnt propagate the 'abandoned' status to the repository, this causes a non synchronized information about the real state of the job execution, that can be clearly seen when using JdbcRepository. This also occur to 'started' state, that is never propagated.
Please let me know if need more details about it.

Outdated checkpoint-info in clutered enviroment

In clustered enviroment with central jdbc repository, outdated reader-checkpoint-infos are loaded when switching executions between instances of a cluster. I will describe the issue by example:

Let there be server A and server B in cluster:

  1. a job is started in server A
  2. job is running, executing chunk items and storing reader-checkpoint-infos in jdbc database
  3. the job is stopped, leaving the chekpoint info at count 100
  4. the job is restarted on server B
  5. server B resumes from checkpoint-info holding count 100
  6. server B is stopped after fifty more chunk-items done, leaving checkpoint-info at 150
  7. the job is restarted on server A
  8. server A resumes from outdated checkpoint-info holding count of 100, which it was the last time this server stopped the job

After some debuging it seems JBeret is cashing JobExecutionImpl objects in AbstractPersistentRepository which are not up to date during job restart process.

I am currently using JBeret 1.2.0 final.

Injection of batch artifact properties does not work

According to https://jberet.gitbooks.io/jberet-user-guide/content/batch_properties/, I should be able to inject batch artifact properties using the @BatchProperty annotation. This mechanism is even used in several of the existing test cases (e.g. "SleepBatchletTest"); however, when I set a breakpoint in the "process" method of that batchlet, the "sleepMinutes" field is always 0.

I could not find any test case specifically covering batch artifact properties. (The "InjectBatchletTest" only validates job and step properties.) Hence, my assumption is that it is a bug that should be fixed.

Usage of JBoss Marshalling incompatible with native compilation with GraalVM

BatchUtil class currently uses a org.jboss.marshalling.cloner.ObjectCloner. Native compilation yields this (the actual log is much longer and less readable, showing just the most important piece here)

Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing org.jboss.marshalling.reflect.SerializableField.setShort(java.lang.Object, short) 
(...)
Caused by: com.oracle.svm.hosted.analysis.flow.SVMMethodTypeFlowBuilder$UnsafeOffsetError: Field AnalysisField<SerializableField.fieldOffset accessed: false reads: true written: true> is used as an offset in an unsafe operation, but no value recomputation found.
 Wrapped field: HotSpotResolvedJavaFieldImpl<org.jboss.marshalling.reflect.SerializableField.fieldOffset long:16>

We might need to get rid of JBoss Marshalling, or hack around it somehow, but I'm not yet sure if it's possible.

Method JobListener#afterJob called too early

Take a look at the class JobExecutionRunner. The method afterJob from registered JobListeners is called before the JobRepository and the status of the Job is updated.

Therefore the Job still has the Status "STARTED" and no EndTime is available at this point. This is somehow confusing.

The StepExecutionRunner behaves differently. The Status of the Step is updated and an EndTime is available at the point, when the method afterStep of registered StepListeners is called

JdbcRepository leave ResultSet open on oracle.

Hi,
At least jdbc oracle driver don´t close the resultSets when the preparedStatement close´s method is called.
If the resultSet was iterated and you get the resultSet from the preparedStatement, to close it, the reference will be not properly closed.

Two examples of this are:

  • getJobExecution on lines
final ResultSet rs = preparedStatement.executeQuery(); //not closed.
  • createTables on lines
countPartitionExecutionStatement = connection1.prepareStatement(countPartitionExecutions);
countPartitionExecutionStatement.executeQuery();  //leave the rs reference

Thanks,
Mauricio Fenoglio

JdbcItemReader restart behavior

Hi,

I think JdbcItemReader might have an issue with its checkpoint information. The method checkpointInformation() always returns currentRowNumber. So, in case of a transaction rollback, this would be the last record in the result set, that got successfully processed and committed. Therefore I'd expect open() to set the result set cursor to this exact position and continue processing (rs.next()) after the last successfully processed item.
Is there any other reason for open() to use checkpoint - 1 instead of just checkpoint?

Best,

-fd

Presence of beans.xml in jberet-support

All necessary Beans are marked with @dependent and therefore jberet-support is an implicit Bean Archive. Isn't the presence of beans.xml with bean-discovery-mode="annotated" ambiguous.

Because of the presence of the beans.xml jberet-support can't be used in an CDI 1.0 environment (we can't use a higher Version at the moment), when not all optional dependencies are included in the classpath.

To avoid this, jberet-support has to be repackaged without beans.xml in our project.

Does JBeret support Java11?

WildFly supported Java11 in 1.5.
Has JBeret been tested with Java11?
If JBeret does not support Java11, will JBeret have plans to support Java11?

Log statements in Reader/Writer/Processor/Listener not printing

I am trying to run a JSR352 java batch program in Java SE mode using JBERET implementation. I can see my main() method getting executed. It is in this main() method i get handle of a job operator and starting the job.

public static void main(String[] args) {

    LoggingConfig logConfiguration = new LoggingConfig();

    logger.info("Begining Batch with JBeret approach");

    JobOperator jo = BatchRuntime.getJobOperator();
    long id = jo.start("PilotJob", null);

    logger.info("End of Batch");

}

but, I do not see any log statements inside my reader, processor, writer or listeners getting printed.

I have a logging.properties defined and loaded from my projects src/main/resources/META-INF folder. The log statements in my main() method is getting printed according to it but, the log statements in my reader/writer/processor and listeners aren't printing at all.

public class LoggingConfig {
    public LoggingConfig() {
        try {
            // Load a properties file from class path that way can't be achieved
            // with java.util.logging.config.file

              final LogManager logManager = LogManager.getLogManager(); 
              try (final InputStream is = getClass().getResourceAsStream("/META-INF/logging.properties")) 
              {
                  logManager.readConfiguration(is);
              }

        } catch (Exception e) {
            System.out.println("Error while reading Log configuration file");
            e.printStackTrace();
        }
    }
}

Why isn't my log statements (java log library) in my java batch program to be printed ?

I have also tried giving the following VM Arguments while running my java program , yet no changes

-Dorg.jboss.logging.provider=jdk -Djava.util.logging.config.file=C:\pilotJBeret\src\main\resources\META-INF\logging.properties

Here are the logs from the main() method. I can clearly see that a job has been started but, not sure why the log statements of the batch program isn't getting printed.

    INFO: App Begining Batch with JBeret approach
    INFO: org.jboss.weld.Version WELD-000900: 2.2.15 (Final)
    INFO: org.jboss.weld.Bootstrap WELD-ENV-000014: Falling back to Java Reflection for bean-discovery-mode="annotated" discovery. Add org.jboss:jandex to the classpath to speed-up startup.
    INFO: org.jboss.weld.Bootstrap WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
    WARN: org.jboss.weld.Interceptor WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled
    WARN: org.jboss.weld.Interceptor WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled
    DEBUG: org.jboss.weld.Bootstrap WELD-000100: Weld initialized. Validating beans
    DEBUG: org.jboss.weld.Reflection WELD-000620: interface javax.enterprise.inject.Intercepted is not declared @Target(METHOD, FIELD, PARAMETER, TYPE). Weld will use this annotation, however this may make the application unportable.
    DEBUG: org.jboss.weld.Reflection WELD-000620: interface javax.enterprise.inject.Decorated is not declared @Target(METHOD, FIELD, PARAMETER, TYPE). Weld will use this annotation, however this may make the application unportable.        
    FINE: javax.batch.runtime.BatchRuntime Loaded BatchContainerServiceProvider with className = org.jberet.operations.JobOperatorImpl
    TRACE: org.jberet JBERET000022: resume is not implemented for local transactions
    DEBUG: org.jberet JBERET000017: Persisted org.jberet.runtime.JobInstanceImpl@6 with id 6
    DEBUG: org.jberet JBERET000017: Persisted org.jberet.runtime.JobExecutionImpl@6 with id 6
    INFO: App End of Batch

PurgeBatchlet doesn't work with JdbcJobRepository

When using JdbcJobRepository PurgeBatchlet doesn't work propertly.
By code, with JdbcJobRepository, PurgeBatchlet only uses sql and sqlFile parameters, but when using other parameters (like numberOfRecentJobExecutionsToKeep) JobExecutions are only removed from memory.

What's the sense of that ?

JdbcJobRepository should override AbstractJobRepository removeJobExecutions method and properly delete/clean every data JBeret may have been created.

JBeret users SHOULD NOT use/know any specific JBeret/implementation detail to clean the JobRepository !

Also, even if this is not the right place, Wildfly integration should also be improved.
The jberet submodule should have a parameter to specify the number of jobs to keep and use the specific JBeret implementation methods to clean the data, without the use of the PurgeBatchlet.

Absolutely this is not something end/user programmers should know about ...

I really like jsr352 specification but I had my production environment pollutted with thousands of old entries and being unable to clean them in proper way.

This causes problems like :

https://issues.redhat.com/browse/WFLY-7418
https://developer.jboss.org/thread/272830

For now, I'll switch to memory repository and use the PurgeBatchlet with a low value of numberOfRecentJobExecutionsToKeep.
Hoping this will be enough.

Thank you in advance

"JBERET000651: The requested permits (%d) is greater than the maximum number of permits (%d) allowed in the thread pool.";

We got this error in openshift 4.0 with quarkus 1.11.0-Final and latest quarkus-jberet

org.jboss.threads.JBossThread.run(JBossThread.java:501)
: java.lang.IllegalStateException: JBERET000651: The requested permits (2) is greater than the maximum number of permits (1) allowed in the thread pool.

Is this something we can solve in application.properties? or in openshift environment?

jberet-camel reading only one file

Hi
I'm trying to read ZIP file with jberet
M'y first step use a camelItemReader to copy remote file localy with camel-ftps component.

Just for test I'm use file to file with camel file reader and writer
<step id="simple.step1"> <chunk item-count="1"> <reader ref="camelItemReader"> <properties> <property name="beanType" value="java.io.InputStream" /> <property name="timeout" value="6000" /> <property name="endpoint" value="file:target/data/?preMove=.inprogress/&amp;move=../.done&amp;include=test.xml"/> </properties> </reader> <writer ref="camelItemWriter"> <properties> <property name="endpoint" value="file:target/in/?fileName=toto.xml" /> </properties> </writer> </chunk> </step>
It works but ...
I have a problem with the timeout property. With a short delay I'm not sure if the file was downloaded correctly (process aborted)
With a long wait time I'm sure which file to download but the process does not end when the first file is downloaded and if a second file is available it is also downloaded.
How do I download only one file and wait long enough to be sure that the download will not be interrupted?

Thank

ItemWriter.close() called twice

When I run a partitioned step, the ItemWriter's close() method is called twice.
I think the problem lies in ChunkRunner.run().
The itemWriter reference is not set to null after closing without exception and therefore the final call to safeClose() will call ItemWriter.close() again.

The same probably holds for the ItemReader.close() though I did not actually test it.

NPE for JobExecution#getJobName

When trying to retrieve the running executions of a job but I got a NPE:
Caused by: java.lang.NullPointerException at org.jberet.runtime.JobExecutionImpl.getJobName(JobExecutionImpl.java:141) at org.jberet.operations.JobOperatorImpl.getRunningExecutions(JobOperatorImpl.java:157) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.getRunningJobIds(BatchOperatorServiceBean.java:143) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.assertAtomicJob(BatchOperatorServiceBean.java:94) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.start(BatchOperatorServiceBean.java:54)

looking at the code, i could not tell what the problem was, could some body give me some hints?
(I possted a question http://stackoverflow.com/questions/39074855/jberet-npe-for-jobexecutiongetjobname as well).

thanks in advance.

OutOfMemoryError: unable to create new native thread

When running the jberet-support tests I always get an "OutOfMemoryError: unable to create new native thread" error. Resolved it via:

ulimit -u 2048

The pom.xml probably also contains a typo at (twice -Xms):

<jvmArgs>-Xms512m -Xmx4g -Xss256k</jvmArgs>

Maybe this could be documented somewhere?

JBERET000601: Failed to get job xml file for job

This is a followed issue of #80. I used arquillian to test an installed module containing a batch job. After the succeed deployment of the WAR, I got the below error:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 20.696 sec <<< FAILURE! - in org.hibernate.search.jsr352.PerformanceIT
testDiffrentMassIndexer(org.hibernate.search.jsr352.PerformanceIT)  Time elapsed: 7.002 sec  <<< ERROR!
javax.batch.operations.JobStartException: JBERET000601: Failed to get job xml file for job mass-index.xml
    at org.jberet.creation.ArchiveXmlLoader.getJobXml(ArchiveXmlLoader.java:129)
    at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:91)
    at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
    at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
    at org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer(PerformanceIT.java:163)
    at org.hibernate.search.jsr352.PerformanceIT.testDiffrentMassIndexer(PerformanceIT.java:117)

My job XML is not found by the batch runtime. Here're some points that I've checked:

  • The job XML mass-index.xml has been included in the module's jar file. I checked by viewing the Contents of a JAR File. It is located at:

    META-INF/batch-jobs/mass-index.xml
    
  • The SPI of JobXmlResolver has been implemented using org.jberet.tools.MetaInfBatchJobsJobXmlResolver, it has been included in the module, located at:

    META-INF/services/org.jberet.spi.JobXmlResolver
    
  • The arquillian deployment works with jboss deploement structure file, where the dependency on the module include a dependency on its META-INF directory, as suggested in the mailing-list.

    <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
        <deployment>
            <dependencies>
                <module name="org.hibernate.search.jsr352" services="export" export="true" slot="${project.version}" meta-inf="import"/>
            </dependencies>
        </deployment>
    </jboss-deployment-structure>

After the transaction reaper has run , ChunkRunner does not clear the transaction from the thread

In https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/runtime/runner/ChunkRunner.java Line 335

tm.rollback(); is called only for certain status.

However in case when the TransactionReaper has rolled back the transaction, the status will be Status.STATUS_ROLLEDBACK and if tm.rollback or tm.suspend is never called.

Unless tm.rollback or tm.suspend is called, the thread is still associated with transaction.
Any new Jobs started will fail if they use this thread already associated with a transaction.

The solution for this would be to add Status.STATUS_ROLLEDBACK and Status.STATUS_NO_TRANSACTION in line 332.

JBERET000640 - Wildfly 14

I am getting the follow error when i try to run a programmatic job definition. I am using wildfly 14, java ee 8 and jberet 1.3.1.Final.

JBERET000640: A BatchEnvironment implementation could not be found. Please ensure the SPI has been implemented and is on the class path

MongoItemWriter changes _id from ObjectId to regular string value

I have a simple batch job that uses MongoItemReader to read documents from Mongodb. I use a processor to modify one field then MongoItemWriter saves the changes. Instead of saving the information to the original document, a new document is created with the original _id field saved as a regular string value instead of the ObjectId field.

Jberet and Thorntail

Hello,
I would like to create simple etl program using jberet and thorntail. I have created project and delivered code but I don't know how to configure database connection that will be using in property . I have configured connection to database in project-defaults.yml file like:
swarm:
datasources:
data-sources:
my_datasource:
driver-name: oracle
.....
It work's fine as jpa datasoure bo how to use it in batch xml file.

Regards
sw

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.