Manually registered transaction manager are not recognized by qualifiedBeanOfType [SPR-11915]

[spring-projects-issues]

Michael McCarthy opened SPR-11915 and commented

As per the StackOverflow question above, I've been trying to use an @Transactional annotation with a qualifier, and was hoping that my manually registered singleton bean would get picked up but sadly it doesn't.

If I debug the method public static <T> T qualifiedBeanOfType(BeanFactory beanFactory, Class<T> beanType, String qualifier) and evaluate beanFactory.containsBean(qualifier) in my IDE before the method executes, the result of that evaluation is 'true'.

Unfortunately, qualifiedBeanOfType throws a NoSuchBeanDefinitionException before that fallback method gets a chance to run.

Is it just me or will the fallback never get invoked?

---

Affects: 3.2.9, 4.0.5

Reference URL: http://stackoverflow.com/questions/24385151/can-i-programatically-add-a-qualifier-to-a-bean?noredirect=1#comment37747172_24385151

Referenced from: commits 67ebef6, b9935e9, 5ed20d2, f8b6114

Backported to: 3.2.10

[spring-projects-issues]

Stéphane Nicoll commented

It looks like that particular use case relies on bean definitions and that's not strictly necessary on a first look because it's not invoked as part of the application context initialization.

Some proxy setup routine actually can't look at anything else than the bean definition as some of the beans are not fully initialized yet.

Could you please setup a small example that demonstrates this issue (check the spring-framework-issues repo).

Thanks!

[spring-projects-issues]

Michael McCarthy commented

Thanks for looking! I'll see if I can knock up a test this weekend and put it on GitHub.

[spring-projects-issues]

Stéphane Nicoll commented

no worries. The reason I am asking is that I would see when/how those beans are registered. Besides, having a simple test would really speed the resolution of this one if necessary (4.1 RC1 is around the corner).

You can look at this project that already uses transaction-related stuff if you want to get started more easily. I don't need anything fancy for the test, if it just blows up because it can't find the transaction manager, that's enough.

[spring-projects-issues]

Michael McCarthy commented

Done, have a look at spring-attic/spring-framework-issues#81. It is probably looks a bit contrived but hopefully shows what is happening here. Thanks

[spring-projects-issues]

Stéphane Nicoll commented

repro project available here: https://github.com/spring-projects/spring-framework-issues/tree/master/SPR-11915

Thanks.

[spring-projects-issues]

Michael McCarthy commented

If you need any background on why someone might be registering Spring beans in this way, check out https://github.com/nhuray/dropwizard-spring, and in particular https://github.com/nhuray/dropwizard-spring/blob/master/src/main/java/com/github/nhuray/dropwizard/spring/SpringBundle.java.

Not my project BTW but we're using it.

Thanks
Michael

[spring-projects-issues]

Stéphane Nicoll commented

This is now fixed in master and will be soon backported to 3.2.x and 4.0.x

You have a very good point: that fallback method should run no matter what. That's what we've done and your test project runs fine now against a local build of 4.1.0.BUILD-SNAPSHOT.

Thanks for the report!

[spring-projects-issues]

Michael McCarthy commented

That's brilliant, thanks for the quick turnaround! I'll take a look at fisheye to see the change just out of curiosity.