Hi all,
Let's face it, configuration in Java EE is broken. Most of my customers
package their application in an ear and they have to use the same ear (i.e.
checksum) in all environments (test, dev, integration, production...),
meaning that all the configuration has to be externalize (web.xml,
persistence.xml...). Most of them use Spring Config or some home-made
tricky stuff or application-server specific configuration... but not JNDI
for example.
So, to be honest, until we have a decent configuration API, I would just
leave each spec to do its own stuff, so I would go fo 1. (The current Batch
API approach of leaving all the details up to the implementation).
I know that Mike Keith was brainstorming on having a Java EE Configuration
spec across all EE. Something that could use simple XML centralize file
instead of just JNDI (makes no sense to have JNDI sticking around for a
Batch spec that can live in Java SE). I wonder where this idea is at the
moment (I'll contact him).
My 2 cents
Antonio
On Fri, Jan 25, 2013 at 11:55 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> I'd like the advice of this group on an issue with the Batch API.
>
> The Batch API specifies how applications can define job steps.
> Job steps are combined into a batch job using an XML file that
> is effectively a batch "job control language" script. The application
> starts a batch job by supplying this batch JCL script to the Batch API.
>
> There are at least two models for how an application might deal with
> these batch scripts:
>
> 1. The batch scripts are an integral part of the application. They're
> supplied with the application and controlled by the application.
>
> 2. The application supplies only the batch job steps, expecting that
> an external agent (usually an administrator) constructs a batch
> script using these jobs. The application controls the execution
> of the script, but not the content of the script.
>
> In the first case it seems obvious that the batch script XML files
> should be packaged with the application and the application should
> refer to them by using a resource name in the application (possibly
> a name valid for Class.getResource(), possibly a name of a file in
> a fixed location in the application) when using the Batch API.
>
> In the second case, the application needs to refer to these scripts,
> but the scripts aren't packaged with the application, so it's not
> clear how the application should refer to them. The Batch API
> specifies this case very loosely. The Batch implementation is
> free to interpret the names given to it in any way it desires,
> locating these batch scripts wherever and however it wants. The
> names used with case #1 above are portable, assuming they
> haven't been overridden in some Batch implementation-specific way.
>
> Normally, when a Java EE application uses a resource that's external
> to the application and can be configured by an administrator, we
> expect the application to declare this external dependency using
> (e.g.) a @Resource annotation. This creates information known to
> the deployment process that alerts the deployer that an external
> resource is being referenced and must be supplied.
>
> The Batch API provides no way to expose to the deployment process
> an application's dependency on an externally supplied batch script.
> An application might fail at runtime because the administrator didn't
> supply the expected script with the expected name.
>
> I've proposed that the Batch API make use of @Resource to handle
> this case, similarly to how we've handled other cases, but they've
> rejected that proposal. They believe the loosely defined approach
> that leaves all the details up to the implementation is sufficient.
>
> Which approach do you prefer?
>
> 1. The current Batch API approach of leaving all the details
> up to the implementation.
>
> 2. Find a way (e.g., @Resource) to expose these application dependencies
> on an external batch script to the deployment process.
>
> Let me know what you think.
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org> |
Devoxx France <http://www.devoxx.fr>