Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Jun 25, 2014 · 8 comments
Assignees
Labels
in: core status: backported type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jun 25, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 26, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 26, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 26, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 28, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 30, 2014

Stéphane Nicoll commented

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

Thanks.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 30, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 1, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 1, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants