5:08 a.m.
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