I'm trying to register a GenericConverter that will be able to convert things with @Value or configuration property bindings. Everything I've tried doesn't apply the converter until after it gets past the point where I'm trying to use it.

I've got the converter annotated with @Component and @ConfigurationPropertyBinding - which seem to work for regular Converter implementations, but it has no effect on GenericConverter. I've got a @Bean method providing a ConversionService with my converter registered, but it doesn't get called before trying to convert a property for use with @Value. I've tried using the WebMvcConfigurer.addFormatters override, but since that's only an MVC level registration, it definitely doesn't come into play early enough to help. I've tried defining a static initialization block in a @Configuration class that tries adding it to the ApplicationConversionService but the shared instance is immutable.

It doesn't seem like I'm trying to do anything super crazy or unreasonable. Why won't it pick up my converter?

Comment From: wilkinsona

As described in the documentation, you should use @ConfigurationPropertiesBinding.

If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: toadzky

As I mentioned in the original message, I have that annotation on my converter and it does not work:

I've got the converter annotated with @Component and @ConfigurationPropertyBinding - which seem to work for regular Converter implementations, but it has no effect on GenericConverter.

That's why I opened this as a bug, I wasn't looking for help - the question at the end was rhetorical.

Also, as I mentioned in my original message, I've tried doing what is suggested in the documentation but it isn't using my ConversionService bean binding - which has no dependencies, I'll add. So that seems to be a bug as well.

In case it wasn't clear from my original message, here's the list of different things I've tried to make it work:

  • @Component and @ConfigurationPropertiesBinding on the converter implementation (this works for regular converters)
  • @Bean method for the converter, with and without @ConfigurationPropertiesBinding on the method
  • @Bean method for a ConversionService that I've registered my converter on, with and without the @ConfigurationPropertiesBinding on the method
  • @ConfigurationPropertiesBinding on the @Configuration class that contains both the converter bean method and the ConversionService bean method.

Since the documentation clearly mentions 2 of the things that I have done, yet neither work, I feel this is clearly 2 bugs related to this functionality. If there is something I'm missing in the documentation that would make it work, please point me to it, but I'm doing things as they work with Converter and they don't work with GenericConverter and it's not trying to use my ConfigurationService despite having a bean method for it.

Comment From: wilkinsona

Sorry, I missed that you were already using @ConfigurationPropertiesBinding.

The code should work as documented – we have tests that verify this is the case – but evidently that's not the case for you. Unfortunately, I can't tell why from what you've described. If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: toadzky

Tried to copy my converter code into a new project and it seems to work as described, which means something in the real project is either misconfiguring or overriding something to make it not work. For a bit more context, I'm writing the converter in a library so I can use it in my projects and it's failing in the library tests. Based on the minimal project working as expected, I decided to try commenting out the failing library tests and just using the snapshot build in one of my app projects. The converter was found and used as expected, without issue. So it appears that this problem is somehow related to things going on with @SpringBootTest - though even using that annotation I wasn't able to reproduce the issue in the minimal project.

What else can I do to help track down why the tests aren't finding it but the application is?

Comment From: wilkinsona

Unfortunately, without some code that reproduces the problem, I don't think we'll be able to figure this one out.

@SpringBootTest creates a SpringApplication instance in much the same way as your application's main method does. It should create a conversion service and register it with the application context in the same way in each case. In your position, I would try debugging a situation where it works and a situation where it does not work and try to identify the point at which things diverge.

If that investigation reveals any further information or you're able to create a reproducer based on what you learn from it, please share it with us here and we can take another look.

Comment From: toadzky

Ok, I spent several hours debugging inside Spring-Boot to try and figure out why it isn't able to find it but was unable to make any progress at all. I don't even really know where to start looking. There's dozens of classes that seem like they are involved, but I've yet to find a clear way to debug "why isn't spring finding this component?".

I'll let you know if I'm able to reproduce it in a separate project because it's a very frustrating experience as a user to have it failing unit tests and working fine in an actual application.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.