[wildfly-dev] Per-application batch job repository

[James R. Perkins]

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

-- 
James R. Perkins
Red Hat JBoss Middleware