Custom "Converters" not working with @Command-Annotations #1352

Activity

1. github-actions

   added

   status/need-triageTeam needs to triage and take a first lookTeam needs to triage and take a first look

   on May 16, 2026
2. tschoellhorn

   changed the title [-]Custom "Converters" not working at all[/-] [+]Custom "Converters" not working with @Command-Annotations[/+] on May 17, 2026
3. czpilar commented on May 19, 2026

   

   czpilar

   on May 19, 2026

   Last edited by czpilar

   Contributor

   More actions

   Fixed in PR #1353

   When no ConfigurableConversionService bean is defined CommandFactoryBean falls back to a fresh DefaultConversionService. That fallback now also harvests Converter, GenericConverter and ConverterFactory beans from the application context and registers them on the new service. For Converter<S, T> declared as a @Bean lambda, the runtime class loses its generics, so source/target are resolved from the merged bean definition's ResolvableType and registered via the typed addConverter(source, target, converter) overload.
4. tschoellhorn commented on May 19, 2026

   

   tschoellhorn

   on May 19, 2026

   Author

   More actions

   Thanks that you could look into the issue. Is there a workaround I could use in the meantime (before the PR is merged into the main line) ?
5. czpilar commented on May 19, 2026

   

   czpilar

   on May 19, 2026

   Contributor

   More actions

   Here's a workaround you can add into your application until the fix lands - it replicates the same auto-harvesting logic from the PR as a user-defined ConfigurableConversionService bean, so your existing @Bean Converter<String, Message> lambda from the reproducer keeps working unchanged:

   package org.springframework.shell.samples.helloworld.boot;
   
   import org.springframework.boot.SpringApplication;
   import org.springframework.boot.autoconfigure.SpringBootApplication;
   import org.springframework.context.ApplicationContext;
   import org.springframework.context.ConfigurableApplicationContext;
   import org.springframework.context.annotation.Bean;
   import org.springframework.core.ResolvableType;
   import org.springframework.core.convert.converter.Converter;
   import org.springframework.core.convert.converter.ConverterFactory;
   import org.springframework.core.convert.converter.GenericConverter;
   import org.springframework.core.convert.support.ConfigurableConversionService;
   import org.springframework.core.convert.support.DefaultConversionService;
   import org.springframework.shell.core.command.CommandContext;
   import org.springframework.shell.core.command.CommandOption;
   import org.springframework.shell.core.command.annotation.Command;
   import org.springframework.shell.core.command.annotation.Option;
   
   import java.util.function.Function;
   
   @SpringBootApplication
   public class SpringShellApplication {
   
   	public static void main(String[] args) {
   		SpringApplication.run(SpringShellApplication.class, args);
   	}
   
   	@Command(name = "custom")
   	public String custom(@Option(longName = "msg", required = true) Message msg) {
   		return msg.getMsg();
   	}
   
   	@Command(name = "simple")
   	public String simple(@Option(longName = "msg", required = true) String msg) {
   		return msg;
   	}
   
   	@Bean
   	org.springframework.shell.core.command.Command programmatic() {
   		Function<CommandContext, String> action = ctx -> ctx.getOptionByName("msg").value();
   		return org.springframework.shell.core.command.Command.builder()
   			.name("programmatic")
   			.options(CommandOption.with().longName("msg").type(Message.class).build())
   			.execute(action);
   	}
   
   	@Bean
   	public Converter<String, Message> messageConverter() {
   		return source -> {
   			Message m = new Message();
   			m.setMsg(source);
   			return m;
   		};
   	}
   
   	@Bean
   	@SuppressWarnings({"rawtypes", "unchecked"})
   	ConfigurableConversionService conversionService(ApplicationContext ctx) {
   		DefaultConversionService cs = new DefaultConversionService();
   		ctx.getBeansOfType(GenericConverter.class).values().forEach(cs::addConverter);
   		ctx.getBeansOfType(ConverterFactory.class).values().forEach(cs::addConverterFactory);
   		ctx.getBeansOfType(Converter.class).forEach((name, converter) -> {
   			ResolvableType type = ((ctx instanceof ConfigurableApplicationContext cac
   				&& cac.getBeanFactory().containsBeanDefinition(name))
   				? cac.getBeanFactory().getMergedBeanDefinition(name).getResolvableType()
   				: ResolvableType.forClass(converter.getClass()))
   				.as(Converter.class);
   			Class<?> source = type.getGeneric(0).resolve();
   			Class<?> target = type.getGeneric(1).resolve();
   			if (source != null && target != null) {
   				cs.addConverter(source, target, converter);
   			} else {
   				cs.addConverter(converter);
   			}
   		});
   		return cs;
   	}
   
   	public static class Message {
   
   		String msg;
   
   		public String getMsg() {
   			return msg;
   		}
   
   		public void setMsg(String msg) {
   			this.msg = msg;
   		}
   
   	}
   
   }

   With registered bean:

   

   Without registered bean:
   
6. tschoellhorn commented on May 19, 2026

   

   tschoellhorn

   on May 19, 2026

   Author

   More actions

   Thanks for the workaround. It works great in the testases I provided.

   Yet, in the larger project I try to upgrade, the Converter-Beans are more complicated and have dependencies to the database. Thus, they are initialized after these ConversionService and thus have not been published to the ApplicationContext. I tried to remedy that with @dependsOn - but in that case I receive a circular definition:

   ***************************
   APPLICATION FAILED TO START
   ***************************
   
   Description:
   
   The dependencies of some of the beans in the application context form a cycle:
   
   ┌─────┐
   |  conversionService defined in class path resource [wdc/crawler3/Config.class]
   ↑     ↓
   |  panelConverter (field private wdc.crawler3.core.dao.PanelDAO wdc.crawler3.core.main.PanelConverter.panelDAO)
   ↑     ↓
   |  panelDAO defined in file [/vagrant/wdc-crawler3/target/classes/wdc/crawler3/core/dao/PanelDAO.class]
   ↑     ↓
   |  getJdbcTemplate defined in class path resource [wdc/crawler3/Config.class]
   ↑     ↓
   |  dataSourceScriptDatabaseInitializer defined in class path resource [org/springframework/boot/jdbc/autoconfigure/DataSourceInitializationAutoConfiguration.class]
   ↑     ↓
   |  spring.sql.init-org.springframework.boot.sql.autoconfigure.init.SqlInitializationProperties
   └─────┘
   

   Now, this seems a general issue which might affect also your fix. I did not find an easy way to include that case in the tests. Any ideas how to proceed?
7. tschoellhorn commented on May 19, 2026

   

   tschoellhorn

   on May 19, 2026

   Author

   More actions

   I could provide a more complex and realistic use case including tests. The main difference is that the Converter-Bean itself depends on another bean (in that case JdbcTemplate). Now it does not get registered with this solution. I guess the real fix will have the same problems. Please find attached the updated test-cases. It has nothing to do with lambda-expressions.

   shell.zip
8. czpilar commented on May 19, 2026

   

   czpilar

   on May 19, 2026

   Contributor

   More actions

   I tried the reproducer against the PR (4.0.3-SNAPSHOT), removed the workaround first - all three tests pass, even with MessageConverter as a @Component that @Autowireds JdbcTemplate.

   About the cycle: it isn't caused by the harvesting logic itself, it's caused by the bean's name and type. A bean named conversionService of type ConfigurableConversionService is also picked up by Spring as the conversion service for @ConfigurationProperties binding. So SqlInitializationProperties needs conversionService, conversionService needs MessageConverter, MessageConverter needs JdbcTemplate, JdbcTemplate needs DataSource, DataSource needs the SQL initializer, the SQL initializer needs SqlInitializationProperties -> loop closed.

   The fix doesn't trigger this because its DefaultConversionService is a plain local variable inside CommandFactoryBean#getConfigurableConversionService, never registered as a bean. Spring's property binding keeps using its own default. By the time CommandRegistry is being created and our harvesting runs, DataSource and JdbcTemplate already exist, so MessageConverter instantiates without trouble.

   If you want to keep using a workaround until the PR is merged to the main and released, just rename the bean - e.g. @Bean("shellConversionService") ConfigurableConversionService …. CommandFactoryBean looks it up by type so it still finds it, but Spring's property binder only looks for the literal name conversionService, so the cycle breaks.

   @Bean("shellConversionService")
   @SuppressWarnings({"rawtypes", "unchecked"})
   public ConfigurableConversionService conversionService(ApplicationContext ctx) {
   ...
   }
9. tschoellhorn commented on May 20, 2026

   

   tschoellhorn

   on May 20, 2026

   Author

   More actions

   Thanks for the "fix" of the fix. I did not catch the loop myself - sorry. Now I am confident that your fix also will actually close the issue. Hope your fix will be integrated soon.

   👍React with 👍1Reacted by David Pilař
10. czpilar commented on May 20, 2026

    

    czpilar

    on May 20, 2026

    Contributor

    More actions

    @tschoellhorn No problem. I’m glad to help this project with my contributions, as we use it in our company projects and I also use it in my personal projects.

    ❤️React with ❤️1Reacted by Mahmoud Ben Hassine
11. fmbenhassine

    added a commit that references this issue on May 25, 2026

    Fix user-defined Converter beans were ignored by @Command-annotated m…

    ...

    eb7498c
12. fmbenhassine

    closed this as completedin #1353on May 25, 2026
13. fmbenhassine

    added

    type/bugIs a bug reportIs a bug report

    and removed

    status/need-triageTeam needs to triage and take a first lookTeam needs to triage and take a first look

    on May 25, 2026
14. fmbenhassine

    added this to the 4.0.3 milestone on May 25, 2026