|
[
Permlink
| « Hide
]
Dave Syer added a comment - 28/Aug/07 02:48 AM
Can you attach a command line client that exhibits this behaviour?
I was launching the job from eclipse (not exactly "command line", but it doesn't matter I believe), so I attach the launch configuration.
I'm not sure this can be easily imported so here are the key settings: main class: org.springframework.batch.execution.bootstrap.BatchCommandLineLauncher arguments: jobs/simpleTaskletJob.xml simpleTaskletJob The launcher works if you put it in the project (and modify the project names if necessary).
The custom editor configurer needs to be added to the job configuration. Also the step scope registration: <bean parent="customEditorConfigurer"/> <!-- register the step scope with the application context --> <bean class="org.springframework.batch.execution.scope.StepScope" /> If you have time, could you try some of the other samples this way and tell us (or attach a patch) which ones need to be fixed? P.S. I committed the above change to simpleTaskletJob.xml. I'm attaching a patch that adds the bean declarations... this resolved most of the problems, but tradeJob and multilineOrderJob are still having some scope-related trouble with FlatFileOutputSource.
One more remark: adding "magical" bean declaration for each job feels like a workaround... I guess the BatchCommandLineLauncher should be refactored to handle the subtleties of creating appropriate application context? It's not really a workaround - e.g. if you used step scope in your job configuration you should expect to have to declare it. At some point we are going to have a custom namespace, and that can take care of the "magical" beans. In the meantime the samples serve as a reference point for best practice I guess.
Fixed samples so they can be launched from command line. To make it easier they all have the same job name ("jobConfiguration") and the launcher is also committed to CVS now - it will work if the project names are execution and samples. Thanks for the patch - it helped a lot.
N.B. there is no logger output from most of the jobs - is that expected? Yes, logging is another example of differences in context creation. The logging aspect is declared in the container definition so it does not apply to beans declared in job configuration when run from command line.
Is there a particular reason why BatchCommandLineLauncher creates the parent context first instead of creating the context at once from multiple configuration files? (it is sure not desirable to have inconsistencies between functional tests and manually running a job - I don't know which approach to context creation is better, but I believe only one should be used) Along the same lines, I had the problem that the 'step' scope was not available to jobs unless it was re-defined in the job configuration file since it was loaded as part of the simple-container-definition (imported from data-source-context).
I believe this is related to the issue I submitted regarding the use of simple-container-definition in sample projects ( It seems that either a single context should be created for all of these beans or it should be advised that a separate configurable file be imported by all jobs - eg. batch-common.xml (as I have done in my development) which contains definitions every job should have, eg. the JobConfigurationRegistryBeanPostProcessor. I also used this to separate batch datasource from my 'normal' datasource to allow batch schema to exist separate from data which individual jobs are concerned with and so jobs are unaware of batch datasource. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
(some) samples launched from command line don't work
