Storage-related auto-configurations must be ordered after the auto-configurations they rely upon

[jobrunr]

Storage-related auto-configurations must be ordered after the auto-configurations they rely upon

[snicoll]

The team is not planning to do this at this time.

[rdehuyss]

Hey @snicoll ,

thanks for your valuable input. I'm a bit lost of what to do with the Lettuce and Redis related autoconfiguration.

I see the LettuceConnectionConfiguration but it does not export a RedisClient bean. Same goes for the JedisConnectionConfiguration which does not export a JedisPool bean. Do you know in which configuration I can find them or am I missing something?

[snicoll]

As you've noticed yourself, we don't export those. If your code is relying on that, users will have to create the bean.

[mp911de]

Jedis and Lettuce drivers use different client implementations (RedisClient/Jedis/JedisPool/JedisSentinelPool vs. RedisClusterClient/JedisCluster) depending on the mode of operation (standalone, Sentinel, Cluster). That makes the actual client object an implementation detail of Spring Data Redis' RedisConnectionFactory. Exposing these details makes probably sense to some extent (e.g. via JedisConnectionFactory/LettuceConnectionFactory.getNativeClient) but it doesn't make sense to expose these objects as beans since their lifecycle is tied to RedisConnectionFactory.

If we consider an arrangement without Spring Data Redis, then client object beans such as RedisClient would make sense on their own as that would be the primary interaction API.

[rdehuyss]

If we consider an arrangement without Spring Data Redis, then client object beans such as RedisClient would make sense on their own as that would be the primary interaction API.

This is indeed how it is done for others like the MongoDB driver.

Are you guys planning to do it also for the Lettuce/Jedis?

[mp911de]

Part of the rationale is that configuring the right client correctly is tied to a lot of complexity (Pooling vs. non pooling, Standalone, Sentinel, Cluster, Master/Replica operation modes) and that complexity is already encapsulated in Spring Data Redis.

[rdehuyss]

Part of the rationale is that configuring the right client correctly is tied to a lot of complexity (Pooling vs. non pooling, Standalone, Sentinel, Cluster, Master/Replica operation modes) and that complexity is already encapsulated in Spring Data Redis.

I completely understand - supporting all the different data stores in JobRunr, also took me quite some time to understand how each client library uses pooling/ non-pooling/ ... .

[rdehuyss]

I'll then close this issue as the requested change is done for the other providers (ElasticSearch, MongoDB and Sql DataSource)