For the first part of that question, I think it could be handled fairly easily by the StaxEventWriterOutputSource. Essentially, the output of your query would be mapped to a domain object, which the OutputSource would then serialize using jaxb. For more information on it works, please look at the documentation for the OutputSource, integration tests, and the samples jobs. Additionally, since Spring OXM is used, it's documentation is available as well.
In terms of limiting the input, using a PropertyPlaceholderConfigurer can help with parameter passing. For example:
Code:
<property name="drivingQuery" value="SELECT * from TABLE where DATE > ${date}" />
This will work well if the job is being kicked off from the command line, and only requires a placeholder configurer to be declared in the application context.
Another approach would be to create a custom JobIdentifierFactory, that returns your own custom extension the JobIdentifier interface. This could then be obtained by making your processor step scoped, and implement the StepContextAware interface. Please keep in mind that StepScope will also need to be in the application context. (at least until our custom namespace handler is finished)
The issue of notifying the processor when no more input is available is currently being debated:
http://opensource.atlassian.com/proj...owse/BATCH-151
This is part of a larger discussion about the relationship between the provider, processor, and output source. Until this is resolved in the next milestone, a work around would be to extend whichever tasklet you are using to call a 'final' method after the provider returns null. For example:
Code:
class CustomTasklet extends RestartableItemProviderTasklet{
public ExitStatus execute(){
ExitStatus result = super.execute()
//only complete should cause finalize call
if(result == ExitStatus.COMPLETED){
if(itemProcessor instanceof FinalizableItemProcessor){
//cast and call finalize method
}
}
return result;
}
}
It's certainly not perfect, but hopefully you get the idea.