Parameter types improvement

[spring-projects-issues]

Stéphane Nicoll opened BATCH-1461 and commented

Spring Batch does not offer a way to define a custom parameter type. The reason behind it is that they are persisted in the database and require some kind of pre-defined types. Right now String, long, double and Date are supported. A first improvement would allow any batch job developer to plug ParameterMapper implementation(s). Here is a proposal for the contract of the ParameterMapper interface:

/**
 * Maps the specified primitive parameter into the actual parameter object. Returns
 * <tt>null</tt> if the mapper cannot handle the specified parameter, otherwise returns
 * the mapped object.
 *
 * @param parameterName the name of the parameter
 * @param parameterType the primitive type of the parameter
 * @param parameterValue the primitve value of the parameter
 * @return the mapped parameter or <tt>null</tt> if the primitive parameter cannot be handled
 */
Object map(String parameterName, ParameterType parameterType, Object parameterValue);

The parameter mapper is only used to manipulate a more complex object during the batch job execution instead of a primitive/raw value. It's not meant to transform the complex value to the primitive type.

The mappers could be defined on the job like this

<job id="myJob" xmlns="http://www.springframework.org/schema/batch">
  <step id="step">
    <tasklet>
      <chunk reader="reader"processor=" processor" writer="writer" commit-interval="10"/>
    </tasklet>
  </step>
  <parameter-mappers>
    <parameter-mapper ref="myMapper"/>
  </parameter-mappers>
</job>

A default mapper implementation can be added at the end of the chain to return the actual primitive type if no custom mapper did map it.

One concrete example of this is a business object identified by an ID. The job parameter would be initially the ID but the job would actually use the actual business object while executing the batch. The ParameterType interface may need to be renamed to something more explicit since the JobParameter could hold other data types in this case.

The advantage of this approach is that it does not break command line executions for instance since the raw ID is still used as input. It is also persistent-friendly.

---

Affects: 2.1.0.M3

[spring-projects-issues]

Dave Syer commented

I see the value in being able to inject a strongly typed object into a step component (like a reader). But I don't think it justifies a new XML namespace feature because you can quite easily accomplish the basic injection use case with Spring 3, e.g.

<bean id="reader" class="...." scope="step">
   <property name="foo" value="#{fooDao.get(jobParameters['foo.id'])}"/>
</bean>

Or am I missing something?

[spring-projects-issues]

Stéphane Nicoll commented

if you feel at ease with the XML config, yes. If you don't or you want to abstract the mapping, it's a different story. Say that a a company has a dozens strong types and the associated ParameterMapper implementations. One guy creates the list and an abstract Job bean with a ref to it and you're done.

[spring-projects-issues]

Dave Syer commented

What kind of parameter mappers would be generic enough to be valuable then (not the fooDao-based one in my example, I guess)?

[spring-projects-issues]

Stéphane Nicoll commented

None and I guess that's the whole point. If you're happy with String, id as long, simple date and a numeric value you don't need this. If you need a more complex object in input that you can identify with an ID, then the mapper implementation is just something that is too specific to be generic.

The only mapper I'd have in mind is something in line with the JpaItemWriter and HibernateWriter.

JpaParameterMapper would take the ID of a persistent object and its target class and would return the persistent object instead of the ID. HibernateParameterMapper would do the same with a session factory.

This is our primary use case (using persistent objects as parameter instead of a raw id). Other use cases are possible like injecting a java.io.File based on a file path.

[spring-projects-issues]

Stéphane Nicoll commented

Injecting a Spring's Resource object would also be a good example.

[spring-projects-issues]

Dave Syer commented

Spring uses its own type conversion mechanisms for this (in particular the Resource has its own PropertyEditor). I would guess that if you use a custom ConversionService in Spring 3.0 you can avoid the extra JobParameters mapper entirely. Please try it and let us know if that causes problems.

[fmbenhassine]

Closing this issue, based on the last comment.

[fmbenhassine]

Re-opened as part of #3960 .

[fmbenhassine]

Resolved with #4204 .