Use default Spring ResourceLoader ?

[dnovitski]

Affects Version(s): All versions

---

Enhancement

In RabbitConnectionFactoryBean.java the PathMatchingResourcePatternResolver is used. This doesn't seem to work with a Spring Boot app that populates custom ResourceLoaders.

As an example, we have a very simple custom base64: resource loader, and we'd like to use this to load the trust store and key store resources. Is it possible to change the resolver into Spring's default ResourceLoader so that it can use all of the application's currently populated resource loaders?

[garyrussell]

That would be a breaking change - would it be sufficient to allow you to inject a resource loader of your choice?

[dnovitski]

I think it can work. But this would be best discussed with the Spring Boot team that handles the RabbitMQ autoconfiguration to allow for this behavior of using the 'default' Spring ResourceLoader so that no application changes are needed besides updating the spring boot dependency.

[dnovitski]

The current workaround I am using is manually creating the RabbitConnectionFactoryBean and manually resolving the truststore and keystore resources. This is more or less a copy of the existing RabbitMqAutoConfiguration:

    @Primary
    @Bean
    public CachingConnectionFactory rabbitConnectionFactory(ResourceLoader resourceLoader, RabbitProperties config) throws Exception {
        RabbitConnectionFactoryBean factory = new RabbitConnectionFactoryBean();
        if (config.determineHost() != null) {
            factory.setHost(config.determineHost());
        }
        factory.setPort(config.determinePort());
        if (config.determineUsername() != null) {
            factory.setUsername(config.determineUsername());
        }
        if (config.determinePassword() != null) {
            factory.setPassword(config.determinePassword());
        }
        if (config.determineVirtualHost() != null) {
            factory.setVirtualHost(config.determineVirtualHost());
        }
        if (config.getRequestedHeartbeat() != null) {
            factory.setRequestedHeartbeat(config.getRequestedHeartbeat());
        }
        RabbitProperties.Ssl ssl = config.getSsl();
        if (ssl.isEnabled()) {
            factory.setUseSSL(true);
            if (ssl.getAlgorithm() != null) {
                factory.setSslAlgorithm(ssl.getAlgorithm());
            }

            factory.setKeyStoreResource(resourceLoader.getResource(ssl.getKeyStore())); // <- CHANGE HERE
            factory.setKeyStorePassphrase(ssl.getKeyStorePassword());
            factory.setTrustStoreResource(resourceLoader.getResource(ssl.getTrustStore()));  // <- CHANGE HERE
            factory.setTrustStorePassphrase(ssl.getTrustStorePassword());
        }
        if (config.getConnectionTimeout() != null) {
            factory.setConnectionTimeout(config.getConnectionTimeout());
        }
        factory.afterPropertiesSet();
        CachingConnectionFactory connectionFactory = new CachingConnectionFactory(factory.getObject());
        connectionFactory.setAddresses(config.determineAddresses());
        connectionFactory.setPublisherConfirms(config.isPublisherConfirms());
        connectionFactory.setPublisherReturns(config.isPublisherReturns());
        if (config.getCache().getChannel().getSize() != null) {
            connectionFactory.setChannelCacheSize(config.getCache().getChannel().getSize());
        }
        if (config.getCache().getConnection().getMode() != null) {
            connectionFactory.setCacheMode(config.getCache().getConnection().getMode());
        }
        if (config.getCache().getConnection().getSize() != null) {
            connectionFactory.setConnectionCacheSize(config.getCache().getConnection().getSize());
        }
        if (config.getCache().getChannel().getCheckoutTimeout() != null) {
            connectionFactory.setChannelCheckoutTimeout(config.getCache().getChannel().getCheckoutTimeout());
        }
        return connectionFactory;
    }

[garyrussell]

I don't think Boot can auto configure it because existing users might be relying on the pattern matching features.

Perhaps it could in 2.4.

cc/ @snicoll WDYT?

[snicoll]

@garyrussell I am not sure I understood the problem. As far as I can tell the default is to use PathMatchingResourcePatternResolver so only a user that has customized the root ResourceLoader of the context would be broken.

IMO, it is more consistent to use the ResourceLoader of the context (unless I've missed something). I agree that we should only do that in a new feature release.

[garyrussell]

@snicoll

I am not sure I understood the problem.

The problem is the some existing application might have spring.rabbitmq.ssl.truststore=/foo/**/my.truststore - unlikely, perhaps, but possible.

Changing the loader to one that doesn't match ant patterns would break this app.

I do not think this will be an issue, as long as the change is in 2.4; I'll add a setter.