Hi Konstantin,
Am 08.12.2014 um 22:10 schrieb Konstantin Kolinko:
2014-12-08 23:51 GMT+03:00 <rj...@apache.org>:
Author: rjung
Date: Mon Dec 8 20:51:01 2014
New Revision: 1643912
URL: http://svn.apache.org/r1643912
Log:
Add support for Log4J2 to juli.
Log4J2 has builtin support for commons logging.
But using that would mean the Log4J2 jar files have
to be put on the CLASSPATH. One can instead integrate
Log4J2 similar to Log4J and the code is very similar
to what is in org.apache.logging.log4j.jcl.
Needs documentation.
1. Log4J2 can also be plugged into JUL. (I think that would be the
easiest approach, using already existing library).
http://logging.apache.org/log4j/2.x/log4j-jul/index.html
But that means you have to add 3 log4j2 jar files to the CLASSPATH.
Since we usually tell people to be restrictive with adding jars to the
CLASSPATH, I found it nicer to do it in a way analogous with our log4j
integration.
2. I thought that the way to leverage commons logging for Log4j is to
take their jcl bridge (3 classes)
http://logging.apache.org/log4j/2.x/log4j-jcl/index.html
and
1) apply package renaming to those 3 classes
2) compile those 3 classes against our package-renamed
extra/tomcat-juli[-adapters].jar and package into separate JAR with a
separate ant target.
It shall be close to what you are doing, but it looks that you are
patching commons-logging build file.
Tried that, but I didn't find it satisfying:
The jcl package contains a Factory class that is meant to replace the
factory class that is available in jcl. It will be found by a services
entry. Now that factory is not as flexible as the default one: the
default one will find jcl implementations per classloader. Example when
log4j is in place: Since the implementations are in the juli-adapters
jar, the first created logger - before the common loader is active -
will be a JDK4 logger, then after the common loader was started, it will
find juli-adapters and use a log4j logger, the same for the tomcat
loggers initialized for the webapps.
When using the log4j2 jcl bridge, again the three jar files (api, core
and jcl) of log4j2 must be in the CLASSPATH. Otherwise the factory fails.
That's why I extended the existing IMHO more clever factory to log4j2
and provide a jcl Log impl based on log4j2 (similar to Log4JLogger).
This impl can now be copied with only small adjustments from log4j2
jcl/Log4jLog.
3. Generally, I do not like <patch> as a long-term solution, as that
tool is not available under Windows, unless you specifically configure
it (needs update to BUILDING.txt)/
Any better idea? I can try to get the stuff in upstream jcl, but I think
it's not very likely they'll do a release.
Should I instead check in the resulting build2.xml and the 2 classes
into a res sub directory and copy the files out from there? The files
would hevae to be updated if we move to a newer jcl version, which might
well happen never. I could keep the patch file for reference and to make
merging after upgrading jcl easier.
4. When I downloaded commons-logging 1.2 from commons site, I noted
that there is a difference in packaging.
Version 1.1.3 had two jars (.jar and adapters.jar), where 1.2 only
one jar (with all classes from the adapters file). I have not
investigated whether that was an intended change.
You changed version to 1.2. Does the build still produce the
-adapters.jar file. If it does not then installation instruction
(logging-howto) and build file that uploads jars to Maven need to be
updated.
It does produce commons-logging-1.2.jar, commons-logging-api-1.2.jar and
commons-logging-adapters-1.2.jar. But: our two juli artefacts are not
created using the build(2).xml from jcl. Instead we already have
separate jar tasks in our own build.xml, because our two juli jar files
do not fit any of the existing build artefacts of jcl, even before the
switch to 1.2. So that part does not change.
I will care about docs as soon as the log4j2 integration stabilizes. It
is what I came up with after experimenting with the out-of-the-box
integration of log4j2 into jul and jcl. I didn't like the need to put
all the jars on the CLASSPATH, thus tried to provide an integration with
the same formal properties as our log4j integration. Do your share that
goal, or do you think adding all log4j2 jars on the CLASSPATH is OK? Of
course that yould be much easier from an integration point of view. I'm
simply not sure about negative consequences.
Best regards,
Thanks a bunch for your review.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
