Hi Konstantine, Thank you so much for driving this! The connector classpath mess is driving me nuts (or worse, driving me to use Docker).
I like the proposal for micro-benchmarks to test the context switching overhead. I have a difficult time figuring out the module.isolation.enabled. Especially with a default to false. I can't think of a reason that anyone will not want classpath isolation. "No! I want my connectors to mess up each other's dependencies" said no one ever. So it looks like this is mostly for upgrade purpose? Because the initial upgrade will not have the module.path set and therefore classpath isolation will simply not work by default? In that case, why don't we simply use the existence of non-empty module.path as an indicator of whether isolation should work or not? seem simpler and intuitive to me. Thanks! Gwen On Sat, Apr 29, 2017 at 9:16 AM, Konstantine Karantasis < konstant...@confluent.io> wrote: > * Because of KIP number collision, please disregard my previous KIP > announcement and use this thread for discussion instead * > > > Hi everyone, > > we aim to address dependency conflicts in Kafka Connect soon by applying > class loading isolation. > > Feel free to take a look at KIP-146 here: > > *https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 146+-+Classloading+Isolation+in+Connect > <https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 146+-+Classloading+Isolation+in+Connect>* > > which describes minimal required changes to public interfaces and the > general implementation approach. > > This is a much wanted feature for Kafka Connect. Your feedback is highly > appreciated. > > -Konstantine > -- *Gwen Shapira* Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter <https://twitter.com/ConfluentInc> | blog <http://www.confluent.io/blog>
