Part of my Hackweek project. Please don't merge yet (we want to have a stable release of nakadi-mock first), but comments are already appreciated.
This is a Proof-of-concept of how to use my nakadi-mock project to test the event sending of spring-boot applications.
It turned out to be more complicated than I thought, because Spring-Boot-Autoconfigure detected that Undertow (an alternative web server, which I'm using in nakadi-mock) is on the class path, and tried to set it up as the application's web server (beside the Tomcat).
I solved that on the library side by shading undertow (renaming all class names and including in the Jar, thus removing the dependency).
Another issue is that we need to get the port number for the mock before configuring our Nakadi-Producer, which is why we are now using an ApplicationContextInitializer instead of normal @Configuration classes for that.
Includes the changes of #107 and #108, so those should be merged first.
Part of my Hackweek project. Please don't merge yet (we want to have a stable release of nakadi-mock first), but comments are already appreciated.
This is a Proof-of-concept of how to use my nakadi-mock project to test the event sending of spring-boot applications.
It turned out to be more complicated than I thought, because Spring-Boot-Autoconfigure detected that Undertow (an alternative web server, which I'm using in nakadi-mock) is on the class path, and tried to set it up as the application's web server (beside the Tomcat). I solved that on the library side by shading undertow (renaming all class names and including in the Jar, thus removing the dependency).
Another issue is that we need to get the port number for the mock before configuring our Nakadi-Producer, which is why we are now using an ApplicationContextInitializer instead of normal
@Configurationclasses for that.Includes the changes of #107 and #108, so those should be merged first.