Allowed customization of Spring step definitions context #203
Conversation
SpringFactory now searches for cucumber-steps.xml and if found it - uses for configuring step definitions context.
|
@ConradMueller you contributed the last major changes here. Can you look over this and let us know if you agree? I'm not familiar enough with Spring to understand all of this. |
| autowirer.setBeanFactory(stepContext.getBeanFactory()); | ||
| stepContext.getBeanFactory().addBeanPostProcessor(autowirer); | ||
| stepContext.getBeanFactory().addBeanPostProcessor(new CommonAnnotationBeanPostProcessor()); | ||
| stepContext = new ClassPathXmlApplicationContext(new String[]{"classpath*:cucumber-steps.xml"}, |
There was a problem hiding this comment.
can you rename this to cucumber-glue.xml instead please?
|
Looks like a good idea to me (and it simplifies the code, too...). |
|
@vladimirkl and @ConradMueller this chance have the side effect that a new spring context (for the cucumber-glue.xml) is created for each senario. This gives me a big performance hit. I am not absolutely sure about the intention of this. But I am guessing that if the cucumber-glue.xml is loaded once the same functionality would achieved and execution a lot faster. |
|
New spring child context was always created for new scenario. This is behaviour by design - so that each scenarion is completely isolated. My contribution did not change this - I only allowed customization of child context. And parent context from cucumber.xml is still singleton |
|
Yes Before this fix the first scenario to about 3 seconds to run and the following about 0.3-0.4 seconds. No every feature takes about 3-4 seconds. |
|
Old behaviour registered AutowiredAnnotationBeanPostProcessor - that was doing annotation scan on every bean in child context. I replaced it with context:annotation-config. According to docs it registers PersistenceAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor, CommonAnnotationBeanPostProcessor and RequiredAnnotationBeanPostProcessor. This of course adds some overhead but not much. I've never experienced such delays like you. Without those PostProcessors spring autowiring in glue code is very limited |
|
Could the classpath* search slow it down that much? |
|
I am not sure what the reason for the slow down is. |
|
@TeDDaN, I've made some optimizations - so classpath scanning occurs only ones. Please check this in my repository: vladimirkl/cucumber-jvm, branch spring-optimization. Let me know if this solves your issue |
|
Also cucumber core calls SpringFactory.addClass() several times for single glue code class - so same bean definintions were registered multiple times. I've fixed this by storing classes in HashSet - so we have exactly one bean definition for every glue code class |
|
It didn't solve the performance issue. |
|
I've created a feature with scenario outline including 500 examples, so I have spring context created 500 times. This scenario executed in 7 seconds - it's really fast. So I cannot reproduce performance issue. Is it possible that you create a testcase that performs really slow? |
|
@TeDDaN I suggest you create a new ticket for the performance degradation. This ticket is closed, and closed tickets tend to be forgotten. |
|
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. |
Hi,
I've created this pull request because current implementation of SpringFactory makes impossible to customize step definitions context. Actually we have singleton parent context configured in cucumber.xml and child StaticApplicationContext that is created on the fly for every scenario. SpringFactory registers only AutowiredAnnotationBeanPostProcessor in child context and that's all. There is no way to register any additional bean post processor or bean factory post processor. We cannot have PropertyPlaceholderConfigurer in child context, @PersistenceContext annotation support and many other useful things.
So I made the following:
So any additional cucumber-steps.xml files may add customization to step definitions context. I've added one with PropertyPlaceholderConfigurer to test suite and added a test checking that it is working.