[wildfly-dev] Per-application batch job repository

[Cheng Fang]

WildFly batch implementation currently supports a global batch job 
repository, with the plan to support per-application job repository.  
James and I have been tossing around a few ideas, and would like to get 
input on some implementation approaches.  Here are some options:

1, introduce wildfly-batch.xml.  Applications can package in 
wildfly-batch.xml to override batch subsystem configurations for this 
app.  This gives applications maximum flexibility to customize any 
batch-related configurations that can be reasonably modified by 
application, including batch job repository datasource, thead pool, 
etc.  But the downside is there is one more wildfly-specific deployment 
descriptors to deal with.

2, define various batch profile that applications can choose from. The 
CLI path would be something like subsystem=batch/profile=A where A would 
be the name of the profile and would have the same settings as a root 
(subsystem=batch). If something, e.g. a thread-pool, isn't defined on 
the profile it falls back to the default.  The user would define the 
profile by adding a MANIFEST.MF entry with something like Batch-Profile: A.

This approach avoids the need for wildfly-batch.xml, but including 
application config inside MANIFEST.MF may not be that obvious to app 
developers.

3, use a relative jndi-name (a loose term) for job repository datasource 
in batch subsystem configuration, and this relative jndi-name may be 
bound to a datasouce declared in application scope.  For example,

3.1) admin wants to enforce a global job repository (no per-app job 
repository), so he can configure jndi-name attribute in the batch 
subsystem xml snippet:
jndi-name = "java:jboss/datasources/ExampleDS"

3.2) admin wants to allow either global or per-app job repository by 
using relative jndi-name:
jndi-name = "datasources/batch-job-repository"

3.2.1) app Foo wants to use global job repository as configured in 
WildFly server, then do nothing.  jberet will just expand the configured 
jndi-name and use java:jboss/datasources/batch-job-repository as the 
effective job repository jndi-name.

3.2.2) app Bar wants to use per-application job repository, so Bar can 
add a resource-ref to its web.xml or application.xml or ejb.xml
<resource-ref>
<res-ref-name>java:app/env/datasources/batch-job-repository<res-ref-name>
<mapped-name>java:jboss/datasources/orderDB</mapped-name>

When both app Foo and Bar are running inside WildFly server, Foo uses 
the global job repository while Bar uses its own job repository 
(orderDB) without any interference.

Any other ideas and suggestions are also welcome.  James, feel free to 
add or correct anything I've missed.

Cheng