Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register custom converters in two independent modules [DATAJDBC-499] #723

spring-projects-issues opened this issue Mar 2, 2020 · 2 comments
in: repository status: duplicate type: enhancement


Copy link

@spring-projects-issues spring-projects-issues commented Mar 2, 2020

Tom Hombergs opened DATAJDBC-499 and commented

I'm using Spring Data JDBC in two modules of a modular Spring Boot application. I want to build the modules completely self-sufficient so they don't know each other. Each module has its own package, and its own @Configuration.

Now, I want to register custom converters for each of the modules extending AbstractJdbcConfiguration:

class PerformanceServiceDatabaseConfiguration extends AbstractJdbcConfiguration {

  public JdbcCustomConversions jdbcCustomConversions() {
    return new JdbcCustomConversions(Arrays.asList(
      new SiteIdReadingConverter(),
      new SiteIdWritingConverter()


(similar for the other module, with different converters)

When I'm starting up the application, only the converters of one of my modules are being loaded. When I'm trying to persist entities from the other modules I get errors.

The tests in each module run fine, because the tests each only load the part of the application context that belongs to the respective module.

Two things to point out:

  • I think the solution to register converters via AbstractJdbcConfiguration lacks flexibility for modular applications. Is there another way to register converters?
  • Spring Boot (or Spring in general) doesn't complain about the fact that I have two AbstractJdbcConfigurations in my application context, but it silently ignores one of them.


Issue Links:

Copy link

@spring-projects-issues spring-projects-issues commented Mar 2, 2020

Jens Schauder commented

If you want to actually have two different configurations, including two datasources, this would be a duplicate of DATAJDBC-321.

If you just want to combine converters, shouldn't you be able to have converters as beans and get a list of those beans injected or obtained from the application context, so all modules can contribute converters?

I also think the actual configuration should be in a separate module, but from your description it seems the current setup with two configurations kind of works if both behave the same

Copy link

@spring-projects-issues spring-projects-issues commented Mar 2, 2020

Tom Hombergs commented

My modules are using the same datasource, but I guess they could just as well use two separate datasources, so yes, this would probably be solved with DATAJDBC-321.

What you describe is exactly what I have done as a workaround:

  • contribute converter @Beans in the two modules (actually, the modules don't contribute Converters directly, but rather a wrapper around the Converter interface, so I can access them in a targeted fashion...I can't just take ALL Converter implementations from the application context because there may be some contributed by non-database modules without the @ReadingConverter or @WritingConverter annotation)
  • create a common module that picks up those converter-wrappers from the application context, unwraps them, and then registers them in a single Abstract JdbcConfiguration. 

This works fine, but I would have liked to not need the wrapper and the common module.

However, if having two DataSources means I can have multiple AbstractJdbcConfigurations, then feel free to consider this a duplicate of DATAJDBC-321

@spring-projects-issues spring-projects-issues added in: repository type: enhancement status: duplicate labels Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: repository status: duplicate type: enhancement
None yet

No branches or pull requests

2 participants