Am 10.01.2019 um 15:01 schrieb Rémy Maucherat:
On Thu, Jan 10, 2019 at 2:53 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
Am 10.01.2019 um 13:16 schrieb Rémy Maucherat:
On Thu, Jan 10, 2019 at 1:09 PM Mark Thomas <ma...@apache.org> wrote:
There is the possibility that an alternative logging JAR could return.
https://markmail.org/message/gdmffcyporhcmqge
Whether that needs an optional / alternative JAR or whether it could be
handled via configuration is TBD.
Ok, so I'm not doing anything immediately but I'll put my patch in a BZ
instead. It does remove a chunk of build.xml, which is good.
In the meantime Log4J2 (I think starting with 2.10.0) added the artefact
log4j-appserver.jar and support for an additional config file
log4j2-tomcat.xml:
https://logging.apache.org/log4j/2.x/log4j-appserver/index.html
That allows for clean integration, so I currently do no longer see a
need for an alternative JULI jar.
Ok. I find the proposed setup rather lame looking however.
log4j2/[lib|conf] + modify classpath ? It should be in bin and conf
respectively to blend in, but adding to the classpath manually is still
needed (bad).
You are totally right, I lik that aspect neither, but even with my
propsed minimal alternative juli jar it would have been necessary to
include the log4j2 core and api jar in the classpath. I must confess I
don't remember whether it would be feasible to combine java.util.logging
with log4j2 without putting log4j2 into the classpath. At least I'm
pretty sure log4j2 doesn't provide such a deploment out of the box.
I would also find it much cleaner than the default approach, no doubt.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
