-
-
Notifications
You must be signed in to change notification settings - Fork 2k
[Spring] Exception is thrown complaining about multiple matching beans with version 1.2.5 #1225
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
Comments
It appears to be that CoffeeSteps twice is registered twice. Once because it has the I do believe Cucumber should be smart enough to handle this but I don't know how to achieve this yet. For the time being though you can declare
|
This bug is also present is 2.0.x. |
@mpkorstanje Thanks for the analysis. So it looks like I can't solve one issue without triggering the other. |
@EugeneS30 If your only put the |
@brasmusson Hi, thanks for your input. Yes, I have already tried different combinations but I always end up getting this error one way or another. Initially I used a parent class Now I removed this class to make things a bit clearer and annotated all the classes that used to inherit from it with: Most of these classes do not need to be annotated with |
@mpkorstanje @brasmusson Hi, I have just removed all double annotations so that all glue including classes only have Even in such case I get the double bean exception for one of the classes annotated with |
Just an update. As a workaround I was able to avoid the exception by using |
I reckon the problem can be found at SpringFactory.java#L114 @Override
public void start() {
if (stepClassWithSpringContext != null) {
testContextManager = new CucumberTestContextManager(stepClassWithSpringContext);
} else {
if (beanFactory == null) {
beanFactory = createFallbackContext();
}
}
notifyContextManagerAboutTestClassStarted();
if (beanFactory == null || isNewContextCreated()) {
beanFactory = testContextManager.getBeanFactory();
for (Class<?> stepClass : stepClasses) {
registerStepClassBeanDefinition(beanFactory, stepClass);
}
}
GlueCodeContext.getInstance().start();
} All |
Unfortunately we can't resolve this by simply skipping the registration of stepClassWithSpringContext when it is already defined. We can't detect duplicate registrations. Bean registration is done by name. This is the fully qualified name when the bean is registered through class path scanning by cucumber, but only the fqn minus the root scanning package when done by Spring. I reckon the current code is correct. But we could improve it somewhat by throw an exception when
@EugeneS30 do you by any chance happen to have multiple component scans going on? If they're using different but related base packages all components will be registered twice with different names (fqn minus the root scanning package). |
@mpkorstanje The project I am working on is dependent on few other modules where different |
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
@EugeneS30 possibly. You'd have to put a break poing at |
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
…ponent When step definitions are annotated with @component or other related annotations they can be picked up by springs class path scanning. This conflicts with cucumbers class path scanning and may result in multiple bean definitions for the same class. This problem is hard to understand and hard to trace. By making the problem explicit and providing a clear instruction on how to resolve this we can hopefully avoid future confusion. The current implementation only checks the a subset of all annotations. This will hopefully be sufficient. Closes #1225
In the process of transitioning from version Cucumber 1.1.8 to 1.2.5 I have ran into an issue where the below exception is thrown:
CucumberException No qualifying bean of type x is defined: expected single matching bean but found 2
I tried to dig a bit deeper and I see that the
<T> T getInstance(final Class<T> type)
method inSpringFactory
class had changed and apparently is somehow responsible for that behavior.I was able to replicate this behavior in a simple project which I uploaded to github and the link is below.
Cucumber Version: 1.2.5
Operating System and version: Windows 7
Link to your project: https://github.com/EugeneS30/cucumber-bean-defect-verification.git
The text was updated successfully, but these errors were encountered: