Now you can use 

spring.jms.subscription-shared=true
spring.jms.subscription-durable=true

for making your jms subscription shared or/and durable.

With these changes you can use default auto-configuration from org.springframework.boot.autoconfigure.jms.JmsAnnotationDrivenConfiguration#jmsListenerContainerFactory And you don't need to make your own bean just for that.

There is example without these changes:

@Configuration
@EnableJms
public class JmsConfig {

    @Bean
    DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
            DefaultJmsListenerContainerFactoryConfigurer configurer, ConnectionFactory connectionFactory) {
        DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
        factory.setSubscriptionShared(true);
        factory.setSubscriptionDurable(true);
        configurer.configure(factory, connectionFactory);
        return factory;
    }
}

There is example with these changes:

@Configuration
@EnableJms
public class JmsConfig {
}

And some properties in your config:

spring.jms.subscription-shared=true
spring.jms.subscription-durable=true

I think it is more comfortable, Thanks!

Comment From: pivotal-issuemaster

@oodmi Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-issuemaster

@oodmi Thank you for signing the Contributor License Agreement!

Comment From: snicoll

Thanks for the PR but I think exposing these properties in isolation can be confusing. As the Javadoc of setSubscriptionShared states, using this flag means two things:

  • A subscription name must be set (altought the FQN of the class is going to be used by default). I don't like the idea of enabling that flag without an explicit name
  • This only makes sense with a topic listener so you could have incompatible combinations with no proper heads-up:
spring.jms.subscription-shared=true
spring.jms.pub-sub-domain=false

The current @Bean method is quite concise and DefaultJmsListenerContainerFactoryConfigurer was designed exactly for the purpose of tuning things without losing auto-configuration.

Comment From: yiliuTo

Hi @snicoll , I have some different thoughts for the two points you mentioned about spring.jms.subscription-shared configuration:

A subscription name must be set (altought the FQN of the class is going to be used by default). I don't like the idea of enabling that flag without an explicit name

I think it's a common behavior to use the default value if there is no specific value set for a property in spring boot auto-configuration, besides, I think it could be solved by adding another property of spring.jms.subscription-name to enable setting the subscription name?

This only makes sense with a topic listener so you could have incompatible combinations with no proper heads-up:

spring.jms.subscription-shared=true spring.jms.pub-sub-domain=false

Would the solution be accepted that use Validator to check the configured properties? Also we can design the behavior here of how to configure the properties for an incorrect case like the one you mentioned.

If the above ideas could be accepted, then I would like to create a PR for more detailed design and implemention, like how to check the correctness of combined properties, and how to configure for incompatible combinations.

And if more discussion is needed, I could create another issue to track this topic for the current one was created 2 years ago. Thanks.

Comment From: snicoll

I think it's a common behavior to use the default value if there is no specific value set for a property in spring boot auto-configuration, besides, I think it could be solved by adding another property of spring.jms.subscription-name to enable setting the subscription name?

Not really, no. You'd have to default a subscription name and we can't have a sensible default for that property.

Would the solution be accepted that use Validator to check the configured properties? Also we can design the behavior here of how to configure the properties for an incorrect case like the one you mentioned.

Sure, we can validate any combination and throw a meaningful exception. The point I was trying to make is that exposing properties that contradict each other is something we try to avoid.

All in all, creating your own JmsListenerContainerFactory is very easy (we even have a configurer if you want to reuse the auto-configured defaults, as showcase in the example above), and not everything has to be exposed using properties.

Comment From: yiliuTo

creating your own JmsListenerContainerFactory is very easy (we even have a configurer if you want to reuse the auto-configured defaults, as showcase in the example above)

Yes, I can understand the way of providing a JmsListenerContainerFactory with my customzied configuration, and also the usage of DefaultJmsListenerContainerFactoryConfigurer. That way is not difficult or complicate. But I suppose it's still valuable to provide such configuration is that, from the user's point of view, I think it would be easier to write properties than wirting code for a customized bean. And I suppose one of the aims of spring boot autoconfiguration is trying to simplify / decrease developers' efforts of configuration.

Comment From: snicoll

But I suppose it's still valuable to provide such configuration is that, from the user's point of view, I think it would be easier to write properties than wirting code for a customized bean.

That's again eluding my comment on having contradicting properties and I am not sure I agree with that, especially when defaults are in place and certain features require you to provide additional info. spring.jms.pub-sub-domain default to false as it should IMO so enabling a durable subscription with spring.jms.subscription-shared alone wouldn't work. Also that's for the default container factory. Do we want every listeners of your app to use a durable subscription on a topic? Not a mainstream use case as far as I know.

I suppose one of the aims of spring boot autoconfiguration is trying to simplify / decrease developers' efforts of configuration.

Yes, but that doesn't mean exposing properties for every use cases.

Comment From: yiliuTo

Well my opinion for contradicing properties is that we can use other post processing method to handle each imcompable case, but I can understand the rejection: handling every case of incompatable combinations would be complicated, especially when this could be simply solved by providing a bean of JmsListenerContainerFactory. So that cost might not deserve. Thanks for the explanation.