Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Test the JSR-352 integration in a non-Wildfly JEE application server

Description

I just tried to remove the scope-related hacks in -jsr352-jberet, and it turns out they are not necessary. It makes sense, since the default scope in CDI is "dependent" (i.e. one instance per request).
I probably got confused when trying to make things work even though there was an @Singleton annotation on every batch artifact.

Anyway, this means that the only thing the -jsr-jberet artifact actually provides is the CDI integration. So it could work with other JEE application servers after all, and if so we should consider providing a -jsr352-cdi artifact that could be used with any JEE application server.

Activity

Show:

Yoann Rodière January 10, 2018 at 3:14 PM

Anyway, this means that the only thing the -jsr-jberet artifact actually provides is the CDI integration

Unfortunately, this is no longer true since we target WildFly 11, which includes a newer version of JBeret and requires us to provide our own implementation of org.jberet.spi.JobXmlResolver.

See and the first commit mentioned in the commit message of https://github.com/yrodiere/hibernate-search/commit/9e681e4b537bab20dc8c35e9dc7d68db85296ef8 in particular.

Closing as rejected since this is no longer an easy goal and is not worth it if it requires a specific module for another JavaEE server.

Rejected

Details

Assignee

Reporter

Components

Priority

Created November 24, 2017 at 1:50 PM
Updated January 10, 2018 at 3:14 PM
Resolved January 10, 2018 at 3:14 PM