> Btw who would use remote logging to begin with?
It's not about remote logging like "we log to somewhere else" but rather about including information from remote sources (specifically JDNI) in your log messages. If you are ingesting logs from a bunch of microservices, it would obviously be desirable to know which instance you're in, and just include that in the logger pattern. Or if you have multiple containers in a single tomcat instance, you might want to have the log message include which container it's coming from (especially for the console). Multi-container tomcat used to be VERY common in pet-style legacy java deployments - it's much slimmer on memory, although it does come with the caveat that GC pauses affect all containers. But that container/server information isn't built into the jar, it's runtime data, and the easiest source for getting that information is... connecting to the tomcat server via JNDI and pulling instance information.
But oops, they populated the JDNI string values after the message was already built, meaning that any log message that included a JDNI handle would be executed automatically on its own. And JNDI is basically a whole inner-platform, including the ability to classload arbitrary code from remote sources, because "lol why not, it's java enterprise code, we're building the future here!", so basically any user-controlled log message could include a JDNI link to arbitrary code and it would be downloaded and run.
(the JDNI being built after the rest of the message was populated was obviously the wrong place to do it for exactly this reason... that is really the core problem here, user-controlled JDNI is absolutely not acceptable given the capabilities, but, it's not like I've never written bad code... there but by the grace of god, go I. Although again, that one is pretty obviously a problem just conceptually.)
Incidentally though "remote logging" really isn't inherently insane as a concept, it's conceptually reasonable that some kinds of important messages might want to be logged into Kafka or JDBC, and 15 years ago there wasn't the overwhelming consensus on "write to disk first, ingest it later" being the right way to get it there. If you want to be really really sure that certain super-important messages are committed, and you don't mind the latency, why not just poke it directly? Then you never have to worry about logs getting dropped on disk/etc and not making it there. And by running it through log4j you don't have to do anything special at an application level, you just define certain packages and message levels as being important and you don't have to re-invent the wheel on the message-building framework/etc. And sure log4j ended up having vulnerabilities but your personal implementation may have vulnerabilities too - how sure are you about your string handling and escaping, could a message spoof what looks like a valid log entry? that's a common one. It just turns out that JDNI was a vastly bigger attack surface than initially realized...