version of Apache Tomcat uses any log4j version.
If log4j is used, it is by a specific application (not provided by the ASF)
deployed to Tomcat. (Or an admin changed the default install to add it)
-Tim
On Fri, Jan 28, 2022 at 10:36 AM Samuel Anderson-Burrell | Cloud21
wrote:
Good Afternoon
I hope this helps
https://lists.apache.org/thread/m3bhytsh3yrhsxvo98vcyx4q6w0m1d4v
On Fri, Jan 28, 2022, 9:58 AM Tim Funk wrote:
> Out of the box, no version of Apache Tomcat uses any log4j version.
>
> If log4j is used, it is by a specific application (not provided by the ASF)
>
Out of the box, no version of Apache Tomcat uses any log4j version.
If log4j is used, it is by a specific application (not provided by the ASF)
deployed to Tomcat. (Or an admin changed the default install to add it)
-Tim
On Fri, Jan 28, 2022 at 10:36 AM Samuel Anderson-Burrell | Cloud21
wrote
Good Afternoon Apache
Hope your well, my name is Samuel I work for a Security firm Cloud 21 and we
have been working with a client who uses your software in particular Tomcat.
We are looking to see if there is a security patch against log4j. The version
they are using is tomcat 7, checking your
> I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing
> > this issue. Is there any workaround or the only option is to upgrade
> > Java?
>
> Note that if you are trying to "upgrade to the latest log4j" due to
&
Daniela,
On 12/20/21 13:15, Daniela Morais wrote:
I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing
this issue. Is there any workaround or the only option is to upgrade
Java?
Note that if you are trying to "upgrade to the latest log4j" due to
revent CVEs,
that is a class that is being loaded on java 8 and it wants java 9
but log4j as far as i know supports even java 7.. so i have a feeling that
can't be it (that it won't run on java 8)
On Mon, 20 Dec 2021 at 19:15, Daniela Morais wrote:
> I'm trying to upgrade Log4j2 dependen
We are running Tomcat 9 on Java 11 without any issues, but you probably want to
test it with your application.
> Am 20.12.2021 um 19:15 schrieb Daniela Morais :
>
> I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing
> this issue. Is there any workaround or the only option is to u
I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing
this issue. Is there any workaround or the only option is to upgrade
Java?
Configs
Java 8
Tomcat 9.0.56
Log
20-Dec-2021 15:10:45.177 SEVERE [RMI TCP Connection(2)-127.0.0.1]
org.apache.catalina.core.StandardContext.listenerStart E
given that much
of it involves Java functionality I'd never heard of.
After re-reading the Veracode article in light of what you said, I
then found a couple of Wikipedia articles that further clarify
things, for me at least:
https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wik
James,
On 12/13/21 19:24, James H. H. Lampert wrote:
I can *barely* wrap my mind around the idea of getting executable code
from an RMI server, but what legitimate purpose could be served by
allowing a *logger* to resolve executable code?
None. The designers of log4j probably were thinking
LOG4J2 allows for multiple keyword types of keyword expansions in the logs.
Keyword expansion is a "great way" to log items possibly only known at run
time. And with trace, debug level logging - Comparing those expanded values
to logged values makes debugging "easier". (The closest you'll get to
br
versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on any version of log4j.
Web applications deployed on Tomcat may have a dependency on log4j. You
should seek support from your application vendors on how best to address
this vulnerability.
Tomcat 8.0.x and earlier as well as the
Thanks. I think I understand now.
All except for one thing:
I can *barely* wrap my mind around the idea of getting executable code
from an RMI server, but what legitimate purpose could be served by
allowing a *logger* to resolve executable code?
--
JHHL
(And I have a fair amount of experienc
es that further clarify things, for me
at least:
https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell
So it's the ability to resolve stuff of the general format
"${prefix:name}" within a log string, that's the problem.
It's starting to reach a poin
chris
-Original Message-
From: Christopher Schultz
Sent: Monday, December 13, 2021 11:39 AM
To: users@tomcat.apache.org
Subject: Re: log4j CVE general question
Jon,
On 12/13/21 11:51, jonmcalexan...@wellsfargo.com.INVALID wrote:
So, based on these entries on the log4j apache pages, I c
n.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell
So it's the ability to resolve stuff of the general format
"${prefix:name}" within a log string, that's the problem.
It's starting to reach a point where I can wrap my 59-year-old
Le lun. 13 déc. 2021 à 14:11, Thomas Meyer a écrit :
> Hi,
>
> Interesting. I know a bit off topic..
>
> Does it make a difference for the vulnerability if I log with:
>
> a) log.warn("log msg param {}", userControlledParam);
>
> Or
>
> b) log.warn(log msg param " + userControlledParam);
>
>
No.
ser can do the following:
>- provide input that includes the log4j2 format string for a JNDI lookup
>- on the first iteration log4j2 builds the log message that includes
> the user provided string
>- on the second iteration log4j processes the user provided format
> string and p
iteration log4j2 builds the log message that includes
the user provided string
- on the second iteration log4j processes the user provided format
string and performs a JNDI lookup
For an example of how a JNDI lookup can be leveraged to trigger code
execution in Tomcat see this artic
The thing I'm still utterly unclear about is how simply logging traffic
could, by itself, create a vulnerability.
In our case, the log entries are not even viewable unless you are signed
on to a command line session on the server (ssh for headless Linux; a
physical Twinax terminal, or a 5250 e
Ok, so I have been given clearance to share the stance that we are taking with
log4j. We have contacted Apache Security and are awaiting a response.
Before making a final decision around log4j 1.x, consider the following:
-Initially, 1.x wasn’t assessed for the vulnerability, because, it is end
our cooperation.
> -Original Message-
> From: Christopher Schultz
> Sent: Monday, December 13, 2021 11:39 AM
> To: users@tomcat.apache.org
> Subject: Re: log4j CVE general question
>
> Jon,
>
> On 12/13/21 11:51, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > So, bas
Jon,
On 12/13/21 11:51, jonmcalexan...@wellsfargo.com.INVALID wrote:
So, based on these entries on the log4j apache pages, I can't see
that any 1x product is vulnerable. Mark, is there some message from
Apache that we can share with those that need to know that for
certain 1x log4j i
So, based on these entries on the log4j apache pages, I can't see that any 1x
product is vulnerable. Mark, is there some message from Apache that we can
share with those that need to know that for certain 1x log4j is NOT vulnerable?
News
CVE-2021-44228
The Log4j team has been made aware
Thanks, very useful information to channel back to my team and beyond.
-
Daniel Savard
stating that the presence of tomcat alone would
open up another attack vector through log4j2.
Best regards,
David
-Original Message-
From: Juri Berlanda
Sent: Monday, 13 December 2021 16:03
To: users@tomcat.apache.org
Subject: Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time
> From: Juri Berlanda
> Sent: 13 December 2021 15:03
> Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs
> compile time Java version
> Hi,
> we were affected - we use an AccessLogValve, which logs to Log4j2 and we
> use Log4j as java.util.logging L
-44228 Log4j 2 Vulnerability - Runtime vs compile time
Java version
Hi,
we were affected - we use an AccessLogValve, which logs to Log4j2 and we use
Log4j as java.util.logging LogManager. We already patched, but only on Saturday.
In any case: in a lot of places I saw "recent JRE versions h
caused by use of log4j and not by
Tomcat on the other hand it would be way harder to leverage the attack, if the
BeanFactory could be modified.
> Am 13.12.2021 um 16:03 schrieb Juri Berlanda :
>
> Hi,
>
> we were affected - we use an AccessLogValve, which logs to Log4j2 and
Hi,
we were affected - we use an AccessLogValve, which logs to Log4j2 and we
use Log4j as java.util.logging LogManager. We already patched, but only
on Saturday.
In any case: in a lot of places I saw "recent JRE versions have a
mitigation in place", but I can't seem to
:36
To: users@tomcat.apache.org
Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs
compile time Java version
On 13/12/2021 09:21, David Weisgerber wrote:
> Hi,
> as far as I read through the details, it is a runtime option of the JRE. So,
> it does not need any recompila
of action would be to upgrade log4j if possible, or use
one of the several other mitigations available for recent versions. If
you aren't running a recent version, RUN ONE.
-chris
-
To unsubscribe, e-mail: users-unsubscr.
log4j 1.x information).
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on log4j.
Applications may have a dependency on log4j. You should seek support
from your application vendors on how best to address this vulnerability
although disabling the vulnerable
that you address
this issue with the log4j2 update or configuration.
Mark
Best regards,
David
From: Scott,Tim
Sent: Monday, 13 December 2021 09:57
To: users@tomcat.apache.org
Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java
version
Hi all,
Suspecting that
: users@tomcat.apache.org
Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java
version
Hi all,
Suspecting that someone here knows the answer immediately, I thought I’d ask.
If you do not know the answer, please don’t spend any time investigating: I’ll
do that later today
Hi all,
Suspecting that someone here knows the answer immediately, I thought I'd ask.
If you do not know the answer, please don't spend any time investigating: I'll
do that later today and update everyone whether or not I find an answer.
Our security team advise that "Certain versions of the Ja
,
> > but rather in custom applications that pass user-controllable data to
> > the "InitialContext.lookup()" function, as it still represents a
> > security risk even in fully patched JDK installations.
> >
> >
> > Any application that takes any user
eate a security vulnerability in the application.
+1
*This* is what makes the log4j vulnerability such a problem: it takes
something that should be allowed to be untrustworthy (raw user input)
and turns it into logic signalling.
It is very easy to write an application that contains vulnerab
lso, another person already thought about digging this up (even
before we were aware of the log4j problem):
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736
Rémy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 11/12/2021 22:04, Sebastian Hennebrüder wrote:
Hi all,
I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11.
Actually the Java path version is not relevant.
Utter nonsense. Tomcat is not vulnerable to this attack.
It is possible with a deployed Tomcat 9 and Spring
To be more precise. It depends on how you configure log4j. By default Spring
boot installs
org.apache.logging.log4j
log4j-to-slf4j
In that case the default NullConfiguration of Log4j is not executed and the
JNDI lookup is not configured.
The chance to be impacted is smaller.
>
ot relevant.
>>
>> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat
>> embedded.
>>
>
> Does this affect pre-2.x log4j's? (I am using tomcat 9.0.35 with log4j
> 1.2.17)
>
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.
gt; embedded.
>
Does this affect pre-2.x log4j's? (I am using tomcat 9.0.35 with log4j
1.2.17)
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Correction for Spring Boot with embedded Tomcat
The attack does not work by default.
> Am 11.12.2021 um 23:04 schrieb Sebastian Hennebrüder :
>
> Hi all,
>
> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11.
> Actually the Java path version is not relevant.
>
> It
Hi all,
I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11.
Actually the Java path version is not relevant.
It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.
If your server can reach arbitrary servers on the Internet, you can execute
rando
.*
Can anybody here shed any light?
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on log4j.
Applications may have a dependency on log4j. You should seek support
from your application vendors on how best to address this vulnerability
although disabling
.*
Can anybody here shed any light?
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on log4j.
+1
Applications may have a dependency on log4j.
+1
-Dlog4j2.formatMsgNoLookups=true
This feature should have been disabled by default in the first place
supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on log4j.
Applications may have a dependency on log4j. You should seek support
from your application vendors on how best to address this vulnerability
although disabling the vulnerable feature is likely to be the
. Thank you for
your cooperation.
> -Original Message-
> From: James H. H. Lampert
> Sent: Friday, December 10, 2021 4:17 PM
> To: Tomcat Users List
> Subject: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect
> Tomcat?
>
> A customer brought this to my
A customer brought this to my attention:
https://www.randori.com/blog/cve-2021-44228/
I have no idea how (or if) Tomcat is affected. I have only the vaguest
idea what this vulnerability even *is.*
Can anybody here shed any light?
--
JHHL
-
apter version from tomcat version 7 and
use it for 9 or similar.
I guess that might work but I'd be surprised.
Mark
Regards,
Niranjan
On 6/29/21 12:24 AM, Mark Thomas wrote:
On 29/06/2021 01:11, Niranjan Rao wrote:
Greetings,
I wanted to setup log4j for tomcat logs and google searche
9 or similar.
Regards,
Niranjan
On 6/29/21 12:24 AM, Mark Thomas wrote:
On 29/06/2021 01:11, Niranjan Rao wrote:
Greetings,
I wanted to setup log4j for tomcat logs and google searches seems to
indicate that this is possible. Many articles speak about downloading
tomcat-juli-adapters.jar fro
On 29/06/2021 01:11, Niranjan Rao wrote:
Greetings,
I wanted to setup log4j for tomcat logs and google searches seems to
indicate that this is possible. Many articles speak about downloading
tomcat-juli-adapters.jar from bin/extras directory.
I found out that for tomcat version 9, extras
Greetings,
I wanted to setup log4j for tomcat logs and google searches seems to
indicate that this is possible. Many articles speak about downloading
tomcat-juli-adapters.jar from bin/extras directory.
I found out that for tomcat version 9, extras directory is last present
on version 9.0.14
y when there is no double class loading.
>
> -aj
>
>
> On Thu, May 7, 2020 at 1:53 PM Mark Thomas wrote:
>
>> On 07/05/2020 21:40, AJ Chen wrote:
>> > I use eclipse to develop web app for tomcat, Web app has a dependent
>> > project and so the depen
ars are added on the
> > classpath for tomcat runtime. Log4j works on tomcat 6. But after upgrate
> to
> > tomcat 9, log4j failed to start with the following error. Anyone has seen
> > similar problem? log4j2 also failed. Thanks.
>
> Note: log4j is no longer supported.
>
Hi Chris,
my web app META-INF/lib has log4j jar, but CATALINA_BASE/lib does not have
log4j jar listed.
It should be double loading class issue. I need to find out how to exclude
the unwanted classloading.
-aj
On Thu, May 7, 2020 at 2:48 PM Christopher Schultz <
ch...@christopherschultz.
t;) escribió:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > AJ,
> >
> > On 5/7/20 16:40, AJ Chen wrote:
> > > I use eclipse to develop web app for tomcat, Web app has a
> > > dependent project and so the dependent project and a
ject and so the dependent project and all jars are
> > added on the classpath for tomcat runtime. Log4j works on tomcat 6.
> > But after upgrate to tomcat 9, log4j failed to start with the
> > following error. Anyone has seen similar problem? log4j2 also
> > failed. Thanks.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
AJ,
On 5/7/20 16:40, AJ Chen wrote:
> I use eclipse to develop web app for tomcat, Web app has a
> dependent project and so the dependent project and all jars are
> added on the classpath for tomcat runtime. Log4j works on tomcat 6.
&g
On 07/05/2020 21:40, AJ Chen wrote:
> I use eclipse to develop web app for tomcat, Web app has a dependent
> project and so the dependent project and all jars are added on the
> classpath for tomcat runtime. Log4j works on tomcat 6. But after upgrate to
> tomcat 9, log4j failed to st
I use eclipse to develop web app for tomcat, Web app has a dependent
project and so the dependent project and all jars are added on the
classpath for tomcat runtime. Log4j works on tomcat 6. But after upgrate to
tomcat 9, log4j failed to start with the following error. Anyone has seen
similar
t: Mittwoch, 20.
> > Februar 2019 16:41 An: users@tomcat.apache.org Betreff: Re: Logging
> > web applications with log4j 1.2
> >
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>>
> >>> Thomas,
> >>>
> >>> On 2/
org Betreff: Re: Logging
> web applications with log4j 1.2
>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> Thomas,
>>>
>>> On 2/20/19 08:00, Thomas Rohde wrote:
>>>> I've some basic questions regarding the usage of lo
1 - DevOps can alleviate this issue .. implicit in the model.
2 - exploded directory deployment would allow you to change log4j
assuming log4j is configured to reload its configuration on change
I'm not sure how classpath contexts are assigned to war files .. but
I'm sure there is wa
Hi Chris,
-Ursprüngliche Nachricht-
Von: Christopher Schultz [mailto:ch...@christopherschultz.net]
Gesendet: Mittwoch, 20. Februar 2019 16:41
An: users@tomcat.apache.org
Betreff: Re: Logging web applications with log4j 1.2
> > -BEGIN PGP SIGNED MESSAGE-
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thomas,
On 2/20/19 08:00, Thomas Rohde wrote:
> I've some basic questions regarding the usage of log4j 1.2 in
> Tomcat 8.5.
>
> We are running more than one web application in Tomcat. Each
> application uses log4j via slf4j and
I'm using 7.x still .. I put my log4j file in the classes folder of my web app.
On 2/20/19, Thomas Rohde wrote:
> Hi!
>
> I've some basic questions regarding the usage of log4j 1.2 in Tomcat 8.5.
>
> We are running more than one web application in Tomcat. Each applicati
Hi!
I've some basic questions regarding the usage of log4j 1.2 in Tomcat 8.5.
We are running more than one web application in Tomcat. Each application uses
log4j via slf4j and ships the log4j.jar in WEB-INF/lib. The Tomcat itself uses
JULI.
We are using a common log4j.xml fil
12:42, Lemke, Michael ST/HZA-ZIC2 wrote:
>> >>> I have an old webapp that uses log4j 1.2 and which I am trying to
>> >>> deploy on tomcat. For the heck of it I can't get tomcat to use the
>> >>> log4.properties file. What am I doing wrong?
On Wed, Dec 19, 2018 at 06:52:20PM +, Lemke, Michael ST/HZA-ZIC2 wrote:
> On December 19, 2018 6:54 PM Lemke, Michael wrote:
> >On December 18, 2018 8:52 PM Christopher Schultz wrote:
> >>On 12/18/18 12:42, Lemke, Michael ST/HZA-ZIC2 wrote:
> >>> I have an old
On December 19, 2018 6:54 PM Lemke, Michael wrote:
>On December 18, 2018 8:52 PM Christopher Schultz wrote:
>>On 12/18/18 12:42, Lemke, Michael ST/HZA-ZIC2 wrote:
>>> I have an old webapp that uses log4j 1.2 and which I am trying to
>>> deploy on tomcat. For the heck
Christopher,
On December 18, 2018 8:52 PM Christopher Schultz wrote:
>On 12/18/18 12:42, Lemke, Michael ST/HZA-ZIC2 wrote:
>> I have an old webapp that uses log4j 1.2 and which I am trying to
>> deploy on tomcat. For the heck of it I can't get tomcat to use the
>> log
log4j.PropertyConfigurator;
import org.apache.log4j.Logger;
import org.apache.log4j.LogManager;
/**
* A listener to initialize log4j.
*
* @author Chris Schultz
* @version $Revision: 17834 $ $Date: 2015-12-16 11:03:13 -0500 (Wed,
16 Dec 2015) $
*/
public class Log4jListener
implements ServletCo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 12/18/18 12:42, Lemke, Michael ST/HZA-ZIC2 wrote:
> I have an old webapp that uses log4j 1.2 and which I am trying to
> deploy on tomcat. For the heck of it I can't get tomcat to use the
> log4.properties file. What am
ichael,
Tomcat uses JULI internally. Have you taken necessary steps to redirect JULI to
log4j?
Thanks,
Ryan
From: Lemke, Michael ST/HZA-ZIC2
Sent: Tuesday, December 18, 2018 10:20 AM
To: Tomcat Users List
Subject: RE: log4j app logging
On December 18, 2018
Michael,
Tomcat uses JULI internally. Have you taken necessary steps to redirect JULI to
log4j?
Thanks,
Ryan
From: Lemke, Michael ST/HZA-ZIC2
Sent: Tuesday, December 18, 2018 10:20 AM
To: Tomcat Users List
Subject: RE: log4j app logging
On December 18, 2018 6
ging system.
>On Dec 18, 2018, at 9:42 AM, "Lemke, Michael ST/HZA-ZIC2" wrote:
>
>I have an old webapp that uses log4j 1.2 and which I am trying to deploy on
>tomcat. For the heck of it I can't get tomcat to use the
>log4.properties<http://log4.properties> fi
ST/HZA-ZIC2"
mailto:lemke...@schaeffler.com>> wrote:
I have an old webapp that uses log4j 1.2 and which I am trying to deploy on
tomcat. For the heck of it I can't get tomcat to use the
log4.properties<http://log4.properties> file. What am I doing wrong?
tomcat 9.0.6 is installed as a
I have an old webapp that uses log4j 1.2 and which I am trying to deploy on
tomcat. For the heck of it I can't get tomcat to use the log4.properties file.
What am I doing wrong?
tomcat 9.0.6 is installed as a Windows service and does serve my webapp, so the
app is working fine. The proje
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 10/8/18 14:27, David Filip wrote:
> Dear Tomcat Users,
>
> Apologies if this is more of a log4j question, but I thought that
> I'd start here, in case Tomcat has any easy remedies.
>
> I have a common webapp th
Dear Dave,
I walk through that years before, too.
Yes - you can't let write different Log4J Appenders to the same file or you get
this garbage.
Yes - you have property resolving here, but there are no properties you need.
We did a solution using an additional servlet called at applic
Dear Tomcat Users,
Apologies if this is more of a log4j question, but I thought that I'd start
here, in case Tomcat has any easy remedies.
I have a common webapp that I deploy to multiple, different contexts.
In log4j.properties, I have a few different log files defined, e.g., for l
Hello Chris,
You can have a look here:
https://logging.apache.org/log4j/2.x/log4j-appserver/index.html
Hope it helps,
Luis
2018-05-18 19:55 GMT+02:00 George Stanchev :
> Depends on what you're asking. If you're asking to use log4j to capture
> Tomcat logging, then the answe
Depends on what you're asking. If you're asking to use log4j to capture Tomcat
logging, then the answer is - you can't but you can use Log4j2 or JULI. If the
question is how to use log4j for your apps deployed under Tomcat, then answer
can be found easily...
From: Cheltenh
Also, it may make more sense to code log4j into your app. If you change
servers the logging goes with it.
Best,
J
On Fri, May 18, 2018 at 8:06 AM M. Manna wrote:
> Hi Chris,
>
> How r u planning to use Log4j (or log4j2, which solves a lot of performance
> issues for 1.2.x)?
Hi Chris,
How r u planning to use Log4j (or log4j2, which solves a lot of performance
issues for 1.2.x)?
Are you bridging with SLF4J or or using directly?
All log4j configuration are automatically discovered and configured
provided that you have set up your appplication log4j properties file
Hello,
How do I configure Tomcat 8.5.x to use log4j?
Is there a good document to follow?
I am not very familiar with java but it looks like you configure to logs
to accept java logging for Tomcat.
===
Thank You;
Chris Cheltenham
Technology Services
On 02/02/17 21:53, George Stanchev wrote:
Hi,
I am transitioning from Tomcat 7.0 to Tomcat 8.5 and I was wondering what do I
need to do to use log4j in 8.5. Reading this bug [1], it states that the
support for the for log4j has been dropped since it is EOLed. Now, there is a
comment on this
Hi,
I am transitioning from Tomcat 7.0 to Tomcat 8.5 and I was wondering what do I
need to do to use log4j in 8.5. Reading this bug [1], it states that the
support for the for log4j has been dropped since it is EOLed. Now, there is a
comment on this issue from Mark that says that it is applied
Syed,
Please do not top post. See:
http://tomcat.apache.org/lists.html#tomcat-users
item 6.
My responses are inline.
On 8/10/2016 1:43 AM, Syed Mudassir Ahmed wrote:
> Mark,
> Thanks for the response.
> Indeed I am using Log4j-2. Below is my
Mark,
Thanks for the response.
Indeed I am using Log4j-2. Below is my xml file:
date:%d, millisecs:%r, level:%p, logger:%c, thread:[%t],
file:%F, method:%M, line:%L, message:%m%n%n
Syed,
On 8/9/2016 10:08 PM, Syed Mudassir Ahmed wrote:
> I am using Log4j in my web app to write the logs to a separate file.
> Surprisingly, that log file is not at all getting created. I run
> the logger logic as a standalone application and the log file indeed
> gets created. I
I am using Log4j in my web app to write the logs to a separate file.
Surprisingly, that log file is not at all getting created. I run the
logger logic as a standalone application and the log file indeed gets
created. I am assuming tomcat is not allowing me to write my logs to a
file. It is
0, 2016 5:48 PM
> To: Tomcat Users List
> Subject: Re: Understanding how to controlling what data is written to
> log4j appenders
>
> Thanks for the tips. I have to use the perl program for now to accomplish
> the task for the company but l'll continue to work this for the sake
inal Message-
From: Joleen Barker [mailto:oldenuf2no...@gmail.com]
Sent: Thursday, March 10, 2016 5:48 PM
To: Tomcat Users List
Subject: Re: Understanding how to controlling what data is written to log4j
appenders
Thanks for the tips. I have to use the perl program for now to accomplish the
Thanks for the tips. I have to use the perl program for now to accomplish
the task for the company but l'll continue to work this for the sake of
learning and getting this changed through to application.
Joleen
On Mar 10, 2016 7:42 PM, "Konstantin Kolinko"
wrote:
> 2016-03-11 2:49 GMT+03:00 Jole
2016-03-11 2:49 GMT+03:00 Joleen Barker :
> I wanted to let you know that I really tried at this and feel the changes I
> made should be working and it is a matter of the developer hard coding the
> log messages to go to the stdout/stderr and became lazy as one of the other
> that commented had sta
n't require any
> > changes to the application's configuration.
>
> The swallowOutput option is a remedy for direct System.out.println()
> calls. One should not expect it to work with something that gets a
> direct reference to System.out stream before Tomcat replaces i
1 - 100 of 770 matches
Mail list logo
