These options seem right to me Cheng. I tend to lean towards one as it's more consistent with what we do elsewhere. I do however agree it's some what of a PITA to have yet another descriptor file. On 12/10/2013 08:08 PM, Cheng Fang wrote: > 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

On Mon, Dec 16, 2013 at 5:24 PM, Cheng Fang <cfang(a)redhat.com <mailto:cfang@redhat.com>> wrote: introducing wildfly-batch.xml as an optional descriptor Please don't as we have too much of deployment descriptors already. if anything add it to jboss-all.xml as it was made to be reused as one deployment descriptor to rule them all. -- tomaz _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev