IllegalStateException on Transaction Scoped Beans

[seandcrouse]

spring-amqp/spring-rabbit/src/main/java/org/springframework/amqp/rabbit/core/RabbitAdmin.java

Line 438 in bf5498d

if (collection.size() > 0 && collection.iterator().next() instanceof Declarable) {

Beans using org.springframework.transaction.support.SimpleTransactionScope fail to get instantiated because RabbitAdmin is not operating inside a transaction. I have a message producer that filters out duplicate messages per transaction. This is done with a transaction scoped Set bean. I know that my producer will only use this bean within that transaction. However, RabbitAdmin is getting every Collection bean, calling the size() method, which causes the class scoped proxy to try to instantiate the bean. This fails because it's not happening inside a transaction.

Sample code:

    public static String TRANSACTION_SCOPE = "transaction";
    
    @Bean(name = "sentBundles")
    @Scope(value = TRANSACTION_SCOPE, proxyMode = ScopedProxyMode.TARGET_CLASS)
    public Set<MessageBundle> sentBundles() {
        return new HashSet<>();
    }

    @Bean
    public static CustomScopeConfigurer customScope() {
        CustomScopeConfigurer configurer = new CustomScopeConfigurer();
        configurer.addScope(TRANSACTION_SCOPE, new SimpleTransactionScope());
        return configurer;
    }

[garyrussell]

I am not sure there's much we can do about this, except, perhaps, add a boolean property to the admin to disable provisioning of Collection<Declarable>.

In the meantime, if you can live without the Admin declaring the exchanges/queues/bindings automatically, set its autoStartup property to false; you would then have to declare your elements yourself using the Admin's API.

[seandcrouse]

For now I'm wrapping my Set in another object, which simply exposes the add, remove, contains, and size methods of the Set. This gets around the problem because my wrapper is not, itself, a subclass of Collection.

[artembilan]

I think this is exactly the way we should go in the Framework.
Since we can't predict what end-user can do with his/her beans, we have only the way as simple Declarables object with the some fluent builder API to add instances to declare in the end.
And, therefore, deprecate Collection approach to avoid similar problems in the future.
Plus the custom type will make the solution robust.

WDYT?

[garyrussell]

Issued a PR with the boolean; we can consider a strong type in future.

That said, @seandcrouse - what version are you using? We already suppressed fetching non-singletons here: #406

Fixed in 1.5.6 and later.

[seandcrouse]

We're using:

[INFO] +- org.springframework.cloud:spring-cloud-starter-bus-amqp:jar:1.1.0.RELEASE:compile
[INFO] | +- org.springframework.cloud:spring-cloud-starter-stream-rabbit:jar:1.0.2.RELEASE:compile
[INFO] | | +- org.springframework.cloud:spring-cloud-stream-binder-rabbit:jar:1.0.2.RELEASE:compile
[INFO] | | | +- org.springframework.boot:spring-boot-starter-amqp:jar:1.3.6.RELEASE:compile
[INFO] | | | | - org.springframework.amqp:spring-rabbit:jar:1.5.6.RELEASE:compile
[INFO] | | | | +- org.springframework.amqp:spring-amqp:jar:1.5.6.RELEASE:compile

I'll take a look at #406. Thanks for the great work all of you do!

[garyrussell]

Hmmm... Strange...

The fix (AMQP-598) should be in 1.5.6

4ef35bf8 [artifactory-release] Next development version
7b0f9b54 [artifactory-release] Release version 1.5.6.RELEASE
df8249f8 AMQP-605: Expose RabbitMQ ClientProperties
9db4aba2 AMQP-599: Log Appenders - Add addresses Property
3e6fa687 AMQP-598: Admin: Ignore Scoped and Prototype Beans
26d02f62 AMQP-595: Fix Auto-Startup for @RabbitListener
861ac882 AMQP-591: Fix Permit Release on Factory Destroy
14db8cb7 [artifactory-release] Next development version
5f117e72 [artifactory-release] Release version 1.5.5.RELEASE