Ok, I've looked through your example, and I think I understand now. I think that we interpreted the comments as saying that you are not able to construct the Streams app using Spring. But it seems like what you were actually saying was that you prefer to let Spring construct the exception handler (for example) rather than having Streams do it.
Just to be super clear, the situation is currently that you register the exception handler *class*, and Streams uses reflection to invoke the 0-arg constructor and passes the config to the new instance's "configure" method. Thus, if your exception handler needs some other dependency, you have to construct it ahead of time and insert it into the config Properties, and then get it back out inside the `configure` method of your exception handler. Your preference would be to override part of the StreamsConfig class to replace the reflection-based instantiation with Spring's mechanism. This yields two advantages: 1. Spring can search the classpath to satisfy the dependency, so you don't need to construct it and register it in the config ahead of time. 2. Spring can invoke other constructors besides the 0-arg one, so you can "configure" the handler at construction time, rather than at configuration time. The primary benefit here seems to be that you can store the dependencies in final fields. This seems reasonable to me. Essentially, making the construction of configured classes pluggable would let anyone plug in Spring or Guice or whatever and get more featureful dependency injection than the default, reflection/configure, mechanism. Sorry it took so long to digest what you were getting at. That said, this change does need a KIP, since it alters the public interface. This is actually a good thing, since it gives you the opportunity to propose not only adding this constructor to `TopologyTestDriver` but also de-deprecating the `KafkaStreams` constructor you're using. I can also imaging the community wanting to discuss if there's a more ergonomic approach than overriding `getConfiguredInstance`, and also if there are any similar changes we'd consider making to Producer and Consumer. [ Full content available at: https://github.com/apache/kafka/pull/5344 ] This message was relayed via gitbox.apache.org for [email protected]
