This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Tasklet interface and attributes

Dec 20th, 2008, 07:01 PM

I'm doing some work with Spring Batch (2.x M3) and had questions regarding the Tasklet interface. Within my implementation of Tasklet, I'd like to get one of the job parameters. The interface for Tasklet defines:

It turns out that even when specifying timePeriod=20081220 from the command line (using CommandLineJobRunner) the result of attrs.attributeNames() is empty. After stepping through this with a debugger I found that attrs is really an instance of StepContext with a getJobParameters() method which makes sense. I'm now casting attrs to StepContext (after checking instanceof to guard myself against changes in Batch and failing the step if it's different) but this is ugly.

Is AttributeAccessor really the proper definition for Tasklet? It seems to me that Tasklets would expect easy access to context information and that there's actually very little gain for this far an abstraction in the interface. I could see attrs being defined as something in the middle, like an interface that is used to represent all context information (i.e. for job context, step context, tasklet context, execution context, etc.).

The way it stands now, there's no access to job parameters without a cast which just seems wrong.

It's not strictly true that there is no way to access the JobParameters. The normal way to do it is to implement StepExecutionListener in your Tasklet.

But actually it probably makes sense for the StepContext to be exposed directly in the Tasklet interface. If you would open a JIRA, we can discuss some more there and track the changes, if we decide to make the change to the interface.

Comment

It's not strictly true that there is no way to access the JobParameters. The normal way to do it is to implement StepExecutionListener in your Tasklet.

Ah, I see.

But actually it probably makes sense for the StepContext to be exposed directly in the Tasklet interface. If you would open a JIRA, we can discuss some more there and track the changes, if we decide to make the change to the interface.

I'll do that. I think it would be an improvement to the interface and simplify (what seems to me) a common scenario. I'm not sure how useful the AttributeAccessor argument is to execute() in its current form, hence the comments.

I'll create a JIRA ticket. If it's something of interest, I'd be happy to help work on the changes.