[wildfly-dev] Per-application batch job repository

[Cheng Fang]

If there is no objections, we will go with option 1, introducing 
wildfly-batch.xml as an optional descriptor to EAR, ejb jar and WAR.

Cheng

On 12/11/13, 12:10 AM, James R. Perkins wrote:
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev