Issue Details (XML | Word | Printable)

Key: BATCH-346
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Robert Kasanicky
Reporter: Lucas Ward
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Spring Batch

Modify job runner to require only one xml location.

Created: 07/Feb/08 10:11 PM   Updated: 07/Aug/08 10:06 AM
Component/s: Core
Affects Version/s: 1.0.0.m4
Fix Version/s: 1.0.0.m5

Time Tracking:
Original Estimate: 0.5d
Original Estimate - 0.5d
Remaining Estimate: 0.5d
Remaining Estimate - 0.5d
Time Spent: Not Specified
Remaining Estimate - 0.5d


 Description  « Hide
The current version of the CommandLineJobRunner requires two xml files, one that contains the job, and one that contains the launcher. In my opinion, this was a very handy abstraction, when there were executor interfaces that could be different for varying 'execution environments'. However, with the changes that have come along to remove the *Executor interfaces, I'm don't think this is necessary. Furthermore, the latest version of Spring IDE now provides support for import statements, making this approach much more preferred than it once was.

 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Robert Kasanicky added a comment - 29/Feb/08 02:58 AM
CommandLineJobRunner now requires just single xml file argument, samples modified to use import statement (and removed parent context loading from test launcher)

Douglas C. Kaminsky added a comment - 05/Mar/08 03:06 PM
I don't think this is a good approach. It's much friendlier to the command line runner, but less friendly to any launch environment that only needs to concern itself with the job and not with execution environment. In this case, it forces the user to keep two different job configurations for normal run and restart if they use any type of application container for scheduled launches.

e.g. suppose you have XML file "A" containing only the job definition bean "job-A" and does not import anything, since your application container looks up the execution environment (somehow) and keeps it in memory. Now suppose "job-A" fails, so you need to perform a restart from the command line. You would need to create an alternate version of "A" containing an appropriate import statement or you need to create a configuration "B" to link "A" to the execution environment (ala the test contexts in samples). Either way you now have double the configuration files.

This also makes it much more difficult to switch between environments for testing.

e.g. suppose you have one execution environment that uses the database and one that does not that is used for unit testing. You would need to create two versions of every job configuration if you use the 'import' strategy, one to import each version of the environment.

I think the ability to swap environments between invocations is too powerful to lose.

Dave Syer added a comment - 06/Mar/08 02:23 AM
We haven't lost it. All the samples are still runnable as a single pair of imports (as per the unit tests), or as a standalone job configuration context (as per the JMX demo - which admittedly is not exhaustively testing all the samples, but the principle is there).

Douglas C. Kaminsky added a comment - 06/Mar/08 10:20 AM
My point is that it becomes cumbersome to create contexts for every permutation of your runtime environment. I'm going to create a forum issue to discuss this some time today - I'll post back the link when I've created the thread.

Dave Syer added a comment - 07/Aug/08 10:06 AM
Assume closed as resolved and released