Re: [wildfly-dev] Per-application batch job repository

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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev