Hi, I'm trying to use the new feature of Spring Batch 5 that let you set a job parameter of any kind of type.

The problem is that you have to provide a Converter from your custom parameter type to String because Spring Batch needs it, but the only way to register this new converter is extending DefaultBatchConfiguration and overriding the getConverterService() method. This however switches off the spring boot autoconfiguration for Spring Batch, which seems a bit extreme just to register a simple converter.

I created a small project to demonstrate my situation https://github.com/EvaristeGalois11/spring-batch-parameter

In this small project i rely on the spring boot autoconfiguration to initialize the database schema needed by Spring Batch.

The WithoutConverterTest test case fails because the converter isn't registered, but the WithConverterTest test case fails too because the spring boot autoconfiguration isn't activated and the tables aren't being created.

Possible solution

My simple idea to resolve the problem is to provide a bean similar to Jackson2ObjectMapperBuilderCustomizer. If the spring boot autoconfiguration finds some beans of this type, the ConfigurableConversionService returned from DefaultBatchConfiguration:getConverterService() is enriched accordingly. This will permit registering a new converter without disrupting the autoconfiguration execution.

Let me know what you think, bye!

Comment From: wilkinsona

Thanks for the PR, @EvaristeGalois11. It looks good to me. What do you think, @fmbenhassine?

Comment From: fmbenhassine

LGTM as well. However, I don't understand why we need to autowire a list of customizers here: https://github.com/spring-projects/spring-boot/pull/34769/files#diff-956b655780b21aca86c5bd17fc65d604d5d4e08b0bb0492ddf14028570e83a10R125. Are we supposed to provide multiple customizers? As a Spring Boot user, I would expect to provide a single BatchConversionServiceCustomizer that enriches the base one with all my custom converters (ie a centralized customization rather than probably multiple scattered customizer beans around the application context). wdyt?

That said, if this is the Boot way of doing things, then I have no objection to use the suggested approach.

Comment From: EvaristeGalois11

I don't understand why we need to autowire a list of customizers here: https://github.com/spring-projects/spring-boot/pull/34769/files#diff-956b655780b21aca86c5bd17fc65d604d5d4e08b0bb0492ddf14028570e83a10R125. Are we supposed to provide multiple customizers? As a Spring Boot user, I would expect to provide a single BatchConversionServiceCustomizer that enriches the base one with all my custom converters (ie a centralized customization rather than probably multiple scattered customizer beans around the application context)

Thank you for your feedback!

I admit that I just followed along the Jackson2ObjectMapperBuilderCustomizer design for the most part. I guess the idea is that if you only allow a single bean as a customizer you could potentially conflict with some hypothetical library that tries to register its own customizer. For example i could be forced to use a company mandated framework that is based upon spring boot that already registers its own converters. I agree that most people (me included) will just plug some converters and move on with their life, but maybe having a bit more flexibility could be beneficial in the long run.

Anyway if you and @wilkinsona think that allowing a list is unnecessary in this case i will update the PR using an ObjectProvider instead, it's not a problem for me at all.

Comment From: fmbenhassine

I see. I will defer this decision to the Boot team to introduce this feature in a consistent way with how to customize things in other parts of Spring Boot.

Comment From: scottfrederick

Providing a list of customizers is a very common pattern in Spring Boot, and I think it's best to do that here for consistency.

Comment From: wilkinsona

@EvaristeGalois11 Thanks very much for making your first contribution to Spring Boot.