3 ms·
Yet the exact same kind of feature for Logback requires _explicit opt-in_ on the part of the application developer, via a system property (`logback.ContextSelec
by svieira 5y ago
Yet the exact same kind of feature for Logback requires _explicit opt-in_ on the part of the application developer, via a system property (`logback.ContextSelector=JNDI`) that _must be set before Logback is first instantiated_. If you want custom behavior then you, the application developer must write extra configuration or even code in order to wire Logback into your system correctly. Logback doesn't attempt to make this work for everyone for everything. It's a library. Log4J implemented the same thing and tried to make it Just Work for everyone. Unfortunately, that "everyone" includes people who are not even legitimate end-users of the application. Make the hard cases "possible", don't try to make them "easy" (especially not without several solid use-cases around "hard-but-should-be-easy".)
- mjr00 5y agoOh yeah don't get me wrong, the implementation wasn't great. It should have been opt-in at a minimum, and in some kind of separate extension ideally. But there's been so much incredulity in these comment sections about the log4j issue, as if it were totally obvious that the feature was inherently bad and should have never been in an enterprise logging framework, which I don't think is true.