I would like to implement this, but I need some more guidance from the maintainers. In the documentation of redisson-spring-boot-starter it states that you can use "Common Spring Boot settings" or "Redisson settings". It would be nice if we can use both and merge them in some order. Or we can add some additional documentation about how the settings are prioritized (Redisson settings at the moment).

We can use common Spring Boot settings to setup Redisson:

spring:
  redis:
    secure: false
    host: localhost
    port: 6379
---
spring:
  redis:
    url: redis://localhost:6379

We can achieve the same with Redisson settings:

spring:
  redis:
    redisson: 
      config: |
        singleServerConfig:
          address: redis://localhost:6379
---
spring:
  redis:
    redisson: 
      # Put the configuration into seperate file:
      file: classpath:redisson.yaml

The common Spring Boot settings allow us to dynamically (via externalized configuration) set the properties for Redisson. But there are limitations: there is only a small set of properties we can set with the common Spring Boot settings, described in org.springframework.boot.autoconfigure.data.redis.RedisProperties.

The Redisson settings do not allow us to dynamically (via externalized configuration) set the properties for Redisson. But it also adds a lot of more possibilities. Just take a look at some of the server configurations (ClusterServersConfig, SingleServerConfig) that are available. These configuration let us configure Redisson very precisely, something that is not possible with the common Spring Boot settings.

Can we combine the best of the two settings options: externalized configuration and precise configuration?

I am thinking of the different possibilities: the seperate file for redisson.yaml is nice, but is there some Spring Boot method to include that file into the application configuration? Could we maybe add an additional field to the RedissonProperties so that we more options than only a block (starting with "|") or a file?

Also what should the priority be in merging: The common Spring Boot settings, the Redisson settings. And in turn of Redisson settings, what should overwrite what? We could have file, config, and maybe an additional field.

"Redisson settings" has priority due to limited set of common Spring Boot settings.

but is there some Spring Boot method to include that file into the application configuration?

I'm afraid no.

Could we maybe add an additional field to the RedissonProperties so that we more options than only a block (starting with "|") or a file?

No. Since we need to add all of configuration fields in this case. Which I would like to avoid.

In this case we need to have a direct reference to PropertyResolver object. This makes spring-core as required dependency. Can you suggest better solution?

I have implemented the following workaround for this:

• A RedissonAutoConfigurationCustomizer that stores the config in a static class -> RedissonConfigAccessor
• A custom RedissonRegionFactory which reads the config object from the RedissonConfigAccessor

Due to the order in which the classes are called it works just fine. However, I consider this more like a workaround than a proper solution. Maybe there's a better way of making the config available in the RedissonRegionFactory.

  @Bean
  public RedissonAutoConfigurationCustomizer redissonConfigCustomizer() {
    return new RedissonAutoConfigurationCustomizer() {

      private String database;

      @SuppressWarnings("synthetic-access")
      @Override
      public void customize(Config config) {
        log.info("Redisson config: {}", ToStringBuilder.reflectionToString(config, new RecursiveToStringStyle()));
        RedissonConfigAccessor.setConfig(config);
      }

    };
  }

public class RedissonConfigAccessor {

  private static Config config;

  public static void setConfig(Config config) {
    RedissonConfigAccessor.config = config;
  }

  public static Config getConfig() {
    return config;
  }

}

public class ConfigEnabledRedissonRegionFactory extends RedissonRegionFactory {

  @Override
  protected RedissonClient createRedissonClient(Map properties) {
    Config config = RedissonConfigAccessor.getConfig();
    log.info("Using the existing redisson config: {}", ToStringBuilder.reflectionToString(config, new RecursiveToStringStyle()));
    if (config == null) {
      throw new IllegalArgumentException(
          "Redisson configuration is null -> expecting configuration to be set");
    }
    return Redisson.create(config);
  }

}

@anessi

How does your solution solves the problem of merging of two configurations - Spring Redis common config and Redisson's?

I'm relying on the logic in org.redisson.spring.starter.RedissonAutoConfiguration.redisson() for the initial configuration, which is reading the values from org.springframework.boot.autoconfigure.data.redis.RedisProperties. Then I'm customization that configuration to my need in Java using the RedissonAutoConfigurationCustomizer.

I found it quite hard to understand the logic in org.redisson.spring.starter.RedissonAutoConfiguration.redisson() and what is set from where. Without the source code it would be impossible 😄.

IMO the ideal way would be to have a simple POJO that has all the possible Redisson conf values (similar to org.springframework.boot.autoconfigure.data.redis.RedisProperties). This POJO is populated in a defined way, e.g. reading the values from:

• spring.redis.redisson.config
• spring.redis.redisson.file
• org.springframework.boot.autoconfigure.data.redis.RedisProperties

and merging this into the single Redisson properties POJO. Maybe it would make sense to allow either config or file only. The POJO approach similar to org.springframework.boot.autoconfigure.data.redis.RedisProperties would support setting/overriding any value as defined in chapter Externalized Configuration, e.g. using environment variables. The Redisson properties POJO could also be created/modified in another way if needed as it's a normal Spring bean.

This POJO could then be converted to the Redisson Config object. If needed there is still the possibility to customize the result using the RedissonAutoConfigurationCustomizer approach, which is a good thing IMO.

Probably the approach needs a bit more thinking.

I found it quite hard to understand the logic in org.redisson.spring.starter.RedissonAutoConfiguration.redisson() and what is set from where. Without the source code it would be impossible 😄.

Source code deployed in maven repo.
https://repo1.maven.org/maven2/org/redisson/redisson-spring-boot-starter/3.16.2/redisson-spring-boot-starter-3.16.2-sources.jar

IMO the ideal way would be to have a simple POJO that has all the possible Redisson conf values

I would like to find a way to reuse existing Config classes.

Source code deployed in maven repo.
https://repo1.maven.org/maven2/org/redisson/redisson-spring-boot-starter/3.16.2/redisson-spring-boot-starter-3.16.2-sources.jar

Thanks. I found that, so I was able to understand what is happening.

I would like to find a way to reuse existing Config classes.

I guess you could use a org.redisson.config.Configas the POJO class and then use

@Bean
@ConfigurationProperties(prefix="spring.redis.redisson.config")
public Config redissonConfig() {
    return new Config();
}

Spring would automatically populate all properties using the rules mentioned in the link above.

After having the initial values populated you could 'merge' it with spring.redis.redisson.file and org.springframework.boot.autoconfigure.data.redis.RedisProperties.

Any news on this @mrniko ? It's been quite some time now since this feature request has been submitted but it does not seem to be implemented yet right ? I'm very interested in this !

@Blockost

I'm ready to consider any contribution.