On Fri, 18 Mar 2022 at 10:50, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
> I am trying to understand the way the context classloader and
> `ServiceLoader` are used in Log4j 2.x[1].
Since I accidentally clicked "Send" on the previous email before
finishing it, I should probably add some context to the questions
above.
At work we are still using JCL with Log4j 1.x. The nice feature of JCL
is that even if we need to distribute `commons-logging` in the WAR
files, we don't need to attach `log4j`: a server admin can simply add
it to Tomcat's classloader. Log4j 2.x API (and SLF4J) can not work
like this unless:
1. The admin changes the delegation model of the web application
classloader (to look up in the parent's classloader first) and adds
Log4j Core to the server's classloader. Honestly I don't see anything
wrong in doing this on a clean Tomcat, but it is not the way webapps
were designed to work,
OR
2. The admin adds Log4j Core to each application, either by physically
adding the file to `/WEB-INF/lib` or using Tomcat's virtual resources.
I don't like the former, because it modifies the contents of the WAR
file, while the latter requires some knowledge of Tomcat
administration. Our clients often don't have professional admins or at
least admins with some expertise in Tomcat's administration and my
colleagues in the Call Center really don't like modified installations
and they often forward those problems to us.
Therefore my ideal solution would be to only include `log4j-api` (and
`log4j-web) in our applications (99% of our clients just log to the
console), but with a simple way to use the full version of Log4j 2.x
Core. This could be done:
* either by writing a Log4j API implementation that delegates to
Tomcat JULI (Tomcat does not allow applications to override
`org.apache.juli` classes),
* or by writing an implementation that delegates each call to the
Log4j API copy in the server's classloader.
Piotr
