C0urante commented on pull request #9806: URL: https://github.com/apache/kafka/pull/9806#issuecomment-756841881
@gharris1727 thanks for taking a look. It's an interesting question about isolating plugins in that way... I have to wonder if it's possible to do that in a way that doesn't break as much as it fixes. Shared global JVM state isn't necessarily a bad thing and disallowing cross-plugin communication by mutating that state might cause issues in other cases than this one. Presumably, if some client application is using the JVM-global JAAS config, it's because it _wants_ to pick up on mutations to that config. In practice this doesn't seem to happen as often, but ruling that out completely may not be safe. We allow for dynamically-constructed JAAS configs in other places to avoid using/mutating the global JAAS config; I think that approach might be the optimal way to address problems like this, at least when JAAS is involved. This goes back to the point about wanting to pick up mutations to the JVM-global JAAS config; in the case of the basic auth REST extension, we don't really want to do that, and so we shouldn't rely on that global mutable state in the first place. Would probably require a KIP to add dynamic JAAS configs to the basic auth extension though, so this placeholder bug fix is hopefully sufficient for until then. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
