Provide ApplicationContext instead of Config classes #3
Conversation
…g, made objects that can potentially be shared by multiple tests classes and methods beans.
|
In the latest commit I've added the ability to initialize the library with an implementation of WebApplicationContext, would that work? |
…ationContext. Added the ability to specify whether or not applicationContext should be refreshed during initialization. This is necessary because if you are using the application context that is automatically generated when running Spring tests, calling refresh() on the application context is not allowed.
|
It's a little more complicated than just adding this. The main issue is that if you are using an applicationContext generated by Spring when running tests, making a call to The other fix here is that the tests were not using the Spring test framework, which I think is important because that's how Spring developers are going to be using this library. By adding that, I was able to catch the refresh issue above. I also made the |
|
I see, makes sense. The only change I would suggest from your last commit is that we don't use the refreshContext boolean as a constructor parameter, instead we create a setter for it. This way, the constructor remains clean and simple with a single parameter and you can call the setter only from your unit tests - the default value for refreshContext is true. What do you think? Also, can you change the scope of the spring-test dependency to |
…ApplicationInitializer and SpringLambdacontainerHandler. Added setter for refreshContext. Added Spring test dependencies to test scope
|
Sure makes sense. Just pushed changes for this. |
Added ability to provide custom ApplicationContext. For Spring testing, made objects that can potentially be shared by multiple tests classes and methods beans.