You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tomcat Random <to...@gmail.com> on 2013/11/27 17:45:23 UTC

Logging Best Practices on RHEL

I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are handled
with e.printStackTrace() and go to catalina.out, which doesn't rotate.

Could someone be so kind as to recommend a better way to handle logging,
with specific steps. Daily error logs would be a good start, instead of one
giant catalina.out file.

Best,
Alec

Re: Logging Best Practices on RHEL

Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/11/30 Christopher Schultz <ch...@christopherschultz.net>:
>
> On 11/27/13, 5:00 PM, Tomcat Random wrote:
>
>> "I find java.logging to be... frankly frustrating to configure."
>> Totally agree, I feel like the Tomcat logging.properties file is
>> weirdly clunky.
>
> Yes. That's because out of the box it uses java.util.logging, or
> actually an adaptation of it. That choice was probably made to limit
> the number of 3rd-party (though log4j is ASF) libraries required to
> run Tomcat. Since java.util.logging comes with the JRE... may we wsll
> use it.
>

1) java.util.logging is always there, regardless of whether you use it
or not. Even if you do not use it, you need to know that it exists and
to be able to configure it.

An empty conf/logging.properties file (mentioned in the "Log4J"
section of the logging guide) is one of such explicit configurations.

2) Pure java.util.logging is frustrating at places.

First, it is hard to configure (from API point of view).

Tomcat's ClassLoaderLogManager solves this and makes it usable in
multi-classloader environments. Internally it is not pretty, using
ThreadLocals to pass information that cannot be passed via APIs, but
it fills the gap.

Note that ClassLoaderLogManager allows to use any 3-rd party
java.util.logging libraries. The default configuration uses
JRE-provided classes (e.g. ConsoleHandler).

A Syslog JUL handler should exist somewhere, and from quick googling
it does exist:

[1] http://stackoverflow.com/questions/2311697/is-there-a-robust-java-util-logging-handler-implementation-of-syslog
[2] http://code.google.com/p/agafua-syslog/


Second, it is hard to use java.util.logging APIs from the code that
generates log information.
The java.util.logging API is too generic and too limited in places.

E.g. there exists java.util.logging.Logger.warning(String)  method,
but there is no warning(String, Throwable) method.  One can call the
Logger.log(Level,...) method, but essentially, one needs an adapter
that provides more friendly interface.

Apache Tomcat uses Apache Commons Logging as an adapter here. The
commons logging classes are renamed into a different package, to avoid
conflict if a web application uses the same library.


3) Personally, my logging experience started with Log4J 1. It was when
Java 1.3 was the current version and java.util.logging did not exist.

I do not use Log4J nowadays (all my needs are covered by JULI and
Apache Commons Logging), but I still like to use their terminology
like "categories" and "appenders".

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Logging Best Practices on RHEL

Posted by Tomcat Random <to...@gmail.com>.
Chris, thanks. That's good to know since I just implemented 1.2.17.


On Mon, Dec 2, 2013 at 5:27 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alec,
>
> On 12/2/13, 3:48 PM, Tomcat Random wrote:
> > Thanks Chris, Are you using log4j 1.x or 2.beta?
>
> I've been using 1.x for quite a long time. I haven't looked much into
> the new version. I'd be surprised if it's a mind-blowing upgrade. :)
>
> - -chris
>
> > On Fri, Nov 29, 2013 at 6:06 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Alec,
> >
> > On 11/27/13, 5:00 PM, Tomcat Random wrote:
> >>>> Thanks Dave, I'll take a look at it.
> >>>>
> >>>> Chris, thanks as well. Out of curiosity, do either of you
> >>>> know if/how you'd consolidate logging for things like say
> >>>> clustering. I have clustering configured for two physical
> >>>> servers each running an instance of tomcat. I have logging
> >>>> configured as per the clustering docs, and it works, but I'm
> >>>> not clear on how it would be reported by log4j, instead of
> >>>> JULI.
> >
> > For my money, I'd use log4j's syslog appender and use syslog to
> > aggregate everything on a single server. I'd have no idea where to
> > begin to use JULI for that, but I'm sure that's more because I have
> > a greater familiarity with log4j.
> >
> >>>> "I find java.logging to be... frankly frustrating to
> >>>> configure." Totally agree, I feel like the Tomcat
> >>>> logging.properties file is weirdly clunky.
> >
> > Yes. That's because out of the box it uses java.util.logging, or
> > actually an adaptation of it. That choice was probably made to
> > limit the number of 3rd-party (though log4j is ASF) libraries
> > required to run Tomcat. Since java.util.logging comes with the
> > JRE... may we wsll use it.
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSnQleAAoJEBzwKT+lPKRYm5sP/1kmwvayu1pRI/F247WYv6B3
> bsLJo2jEFiWINxpvkhIAgqPHAwBIwGKoepWdnZFtQVzXxbxy5yCzP0P9eFOCBbUk
> KDSrEdHK+eu+Py6BoSntvT7wtpV/7pzzGDDR1v0CzyHjuy0OV60NUv5F2zDsukp/
> ls/9pi0WO5ncns4BShj/eu51IDTyZUQP6k8wamTqRx4HaFWdMGdYbrNTq3jtuP+p
> gpwTjO45bE1PGE8BthRzOE4v11cNpJhS6spNaK/Qy61EaTSXfGAtg0ZSQbcx1HK9
> r4lJZ0CQVL2oXWVat0cN9Ipy5q82Zw8PTfXUF66Vrx/1qdsSXdS4ceFwe2DaVLUn
> xIOrb0zd8PKXyGIRvlmLuVNX/vioYFF43T5SNlj51rIFhQ7oeu/F+tvqRqztdC8g
> snkLWa4vHGNwmbhy6FepP6CXmXCiWgtU0UzP1S6yFsWlVgR+dJJ/4rVtOhwh3/T0
> I7KdPYWwmoJYvULA7GDbtsR9zrN42wdSSFXdhrg5STImA5+O8lky6xO5UEWvvSuw
> NWLzhb+cGDkrdvKtyPzGtH4EJayItUlYXMDjG6xwla6LHxi27FD3gV+uJxVlgoVU
> yxRMcdG1f2Z087Gl/XNCkhy7TmO4RDIUqL/9wwjOSfD1SvVMa8B9SyY6+qz7f8ag
> bOpbUovSflMUfKCfz8KR
> =DCTU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Logging Best Practices on RHEL

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alec,

On 12/2/13, 3:48 PM, Tomcat Random wrote:
> Thanks Chris, Are you using log4j 1.x or 2.beta?

I've been using 1.x for quite a long time. I haven't looked much into
the new version. I'd be surprised if it's a mind-blowing upgrade. :)

- -chris

> On Fri, Nov 29, 2013 at 6:06 PM, Christopher Schultz < 
> chris@christopherschultz.net> wrote:
> 
> Alec,
> 
> On 11/27/13, 5:00 PM, Tomcat Random wrote:
>>>> Thanks Dave, I'll take a look at it.
>>>> 
>>>> Chris, thanks as well. Out of curiosity, do either of you
>>>> know if/how you'd consolidate logging for things like say
>>>> clustering. I have clustering configured for two physical
>>>> servers each running an instance of tomcat. I have logging
>>>> configured as per the clustering docs, and it works, but I'm
>>>> not clear on how it would be reported by log4j, instead of
>>>> JULI.
> 
> For my money, I'd use log4j's syslog appender and use syslog to 
> aggregate everything on a single server. I'd have no idea where to 
> begin to use JULI for that, but I'm sure that's more because I have
> a greater familiarity with log4j.
> 
>>>> "I find java.logging to be... frankly frustrating to
>>>> configure." Totally agree, I feel like the Tomcat
>>>> logging.properties file is weirdly clunky.
> 
> Yes. That's because out of the box it uses java.util.logging, or 
> actually an adaptation of it. That choice was probably made to
> limit the number of 3rd-party (though log4j is ASF) libraries
> required to run Tomcat. Since java.util.logging comes with the
> JRE... may we wsll use it.
> 
> -chris
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSnQleAAoJEBzwKT+lPKRYm5sP/1kmwvayu1pRI/F247WYv6B3
bsLJo2jEFiWINxpvkhIAgqPHAwBIwGKoepWdnZFtQVzXxbxy5yCzP0P9eFOCBbUk
KDSrEdHK+eu+Py6BoSntvT7wtpV/7pzzGDDR1v0CzyHjuy0OV60NUv5F2zDsukp/
ls/9pi0WO5ncns4BShj/eu51IDTyZUQP6k8wamTqRx4HaFWdMGdYbrNTq3jtuP+p
gpwTjO45bE1PGE8BthRzOE4v11cNpJhS6spNaK/Qy61EaTSXfGAtg0ZSQbcx1HK9
r4lJZ0CQVL2oXWVat0cN9Ipy5q82Zw8PTfXUF66Vrx/1qdsSXdS4ceFwe2DaVLUn
xIOrb0zd8PKXyGIRvlmLuVNX/vioYFF43T5SNlj51rIFhQ7oeu/F+tvqRqztdC8g
snkLWa4vHGNwmbhy6FepP6CXmXCiWgtU0UzP1S6yFsWlVgR+dJJ/4rVtOhwh3/T0
I7KdPYWwmoJYvULA7GDbtsR9zrN42wdSSFXdhrg5STImA5+O8lky6xO5UEWvvSuw
NWLzhb+cGDkrdvKtyPzGtH4EJayItUlYXMDjG6xwla6LHxi27FD3gV+uJxVlgoVU
yxRMcdG1f2Z087Gl/XNCkhy7TmO4RDIUqL/9wwjOSfD1SvVMa8B9SyY6+qz7f8ag
bOpbUovSflMUfKCfz8KR
=DCTU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Logging Best Practices on RHEL

Posted by Tomcat Random <to...@gmail.com>.
Thanks Chris, Are you using log4j 1.x or 2.beta?


On Fri, Nov 29, 2013 at 6:06 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alec,
>
> On 11/27/13, 5:00 PM, Tomcat Random wrote:
> > Thanks Dave, I'll take a look at it.
> >
> > Chris, thanks as well. Out of curiosity, do either of you know
> > if/how you'd consolidate logging for things like say clustering. I
> > have clustering configured for two physical servers each running an
> > instance of tomcat. I have logging configured as per the clustering
> > docs, and it works, but I'm not clear on how it would be reported
> > by log4j, instead of JULI.
>
> For my money, I'd use log4j's syslog appender and use syslog to
> aggregate everything on a single server. I'd have no idea where to
> begin to use JULI for that, but I'm sure that's more because I have a
> greater familiarity with log4j.
>
> > "I find java.logging to be... frankly frustrating to configure."
> > Totally agree, I feel like the Tomcat logging.properties file is
> > weirdly clunky.
>
> Yes. That's because out of the box it uses java.util.logging, or
> actually an adaptation of it. That choice was probably made to limit
> the number of 3rd-party (though log4j is ASF) libraries required to
> run Tomcat. Since java.util.logging comes with the JRE... may we wsll
> use it.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSmR4GAAoJEBzwKT+lPKRY9JgQAJrQjbnlxLaOexDcDpxNUSZs
> GSgnCKmbOjUSgwAiPE5LbqjHGu+HkdC4rKfM+sGy4F466wxKVcZAmCCETIrKwHLd
> BaRsNB9pZ8gV/hQH3tf52fI8UEFc48K/obm97t3R+Apjmr58UC0uZc0OFM7ukXk0
> E0M/bLQRJl39uZvwvFUJcoYi5jn5XKsqdYHoI9AbVn5DvmQkvPK2BzFqSd37Sm3T
> RGAFiZuUlTPPWA1nTKT+XHyb5YI8fmxo6Jt1dNi5qSaU9xB8ZgKbE+TabZ4fUVaF
> 7eRo+mS6CDPe5BHsne9bShFaIhljyQdmu/QNNTfstUDUiFgAF3zAzAbEMmeYYtFs
> +pHdMWeExt+MTVlppJtTEEiPYtJDbR+ZE/r6Zligm8+Rx43Mhx59iAEO8+UYguyE
> +7IPtLFuSM+hzhjjUvwgSMdgNn2Fm3mg+NOVHL4rQC2MDewv256Hd/wZb7D/5Shp
> KEx9epFB78jW+Qq+dQmiW0o8yD0duWU9uENnrweTkFq/alYWtQZy3DbJBYQ1x+wX
> c+C6xlX69mu5Xpg0IIoLCcRHny+0B0cyWXgGMQfbAq0gfgF7oWGpSeZmopDD3OMU
> JwSU1BmEADH8RGs0zR0TXpw+SmjXYpADp6a9AK1wY3pRt4KS6BMX3ttJpxKhsO9d
> bgJvjWLNingPvlaaIlCS
> =Y2aT
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Logging Best Practices on RHEL

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alec,

On 11/27/13, 5:00 PM, Tomcat Random wrote:
> Thanks Dave, I'll take a look at it.
> 
> Chris, thanks as well. Out of curiosity, do either of you know
> if/how you'd consolidate logging for things like say clustering. I
> have clustering configured for two physical servers each running an
> instance of tomcat. I have logging configured as per the clustering
> docs, and it works, but I'm not clear on how it would be reported
> by log4j, instead of JULI.

For my money, I'd use log4j's syslog appender and use syslog to
aggregate everything on a single server. I'd have no idea where to
begin to use JULI for that, but I'm sure that's more because I have a
greater familiarity with log4j.

> "I find java.logging to be... frankly frustrating to configure."
> Totally agree, I feel like the Tomcat logging.properties file is
> weirdly clunky.

Yes. That's because out of the box it uses java.util.logging, or
actually an adaptation of it. That choice was probably made to limit
the number of 3rd-party (though log4j is ASF) libraries required to
run Tomcat. Since java.util.logging comes with the JRE... may we wsll
use it.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSmR4GAAoJEBzwKT+lPKRY9JgQAJrQjbnlxLaOexDcDpxNUSZs
GSgnCKmbOjUSgwAiPE5LbqjHGu+HkdC4rKfM+sGy4F466wxKVcZAmCCETIrKwHLd
BaRsNB9pZ8gV/hQH3tf52fI8UEFc48K/obm97t3R+Apjmr58UC0uZc0OFM7ukXk0
E0M/bLQRJl39uZvwvFUJcoYi5jn5XKsqdYHoI9AbVn5DvmQkvPK2BzFqSd37Sm3T
RGAFiZuUlTPPWA1nTKT+XHyb5YI8fmxo6Jt1dNi5qSaU9xB8ZgKbE+TabZ4fUVaF
7eRo+mS6CDPe5BHsne9bShFaIhljyQdmu/QNNTfstUDUiFgAF3zAzAbEMmeYYtFs
+pHdMWeExt+MTVlppJtTEEiPYtJDbR+ZE/r6Zligm8+Rx43Mhx59iAEO8+UYguyE
+7IPtLFuSM+hzhjjUvwgSMdgNn2Fm3mg+NOVHL4rQC2MDewv256Hd/wZb7D/5Shp
KEx9epFB78jW+Qq+dQmiW0o8yD0duWU9uENnrweTkFq/alYWtQZy3DbJBYQ1x+wX
c+C6xlX69mu5Xpg0IIoLCcRHny+0B0cyWXgGMQfbAq0gfgF7oWGpSeZmopDD3OMU
JwSU1BmEADH8RGs0zR0TXpw+SmjXYpADp6a9AK1wY3pRt4KS6BMX3ttJpxKhsO9d
bgJvjWLNingPvlaaIlCS
=Y2aT
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Logging Best Practices on RHEL

Posted by Tomcat Random <to...@gmail.com>.
Thanks Dave, I'll take a look at it.

Chris, thanks as well. Out of curiosity, do either of you know if/how you'd
consolidate logging for things like say clustering. I have clustering
configured for two physical servers each running an instance of tomcat. I
have logging configured as per the clustering docs, and it works, but I'm
not clear on how it would be reported by log4j, instead of JULI.

"I find java.logging to be... frankly frustrating to configure." Totally
agree, I feel like the Tomcat logging.properties file is weirdly clunky.

Cheers,
Alec




On Wed, Nov 27, 2013 at 3:34 PM, Dale Ogilvie <Da...@trimble.com>wrote:

> We chose slf4j with log4j underneath.
>
> 1. slf4j has nice optimal syntax:
>
> Log.debug("The logged in user is {} {}",firstName,lastName);
> http://www.slf4j.org/faq.html#logging_performance
>
> 2. It has bridging apis to route other logging frameworks. If you are
> using other libraries which use a different logging framework, you could
> capture these logs via a bridge.
> http://www.slf4j.org/legacy.html
>
> Dale
>
> -----Original Message-----
> From: Tomcat Random [mailto:tomcat.random@gmail.com]
> Sent: Thursday, 28 November 2013 5:45 a.m.
> To: Tomcat Users List
> Subject: Logging Best Practices on RHEL
>
> I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are
> handled with e.printStackTrace() and go to catalina.out, which doesn't
> rotate.
>
> Could someone be so kind as to recommend a better way to handle logging,
> with specific steps. Daily error logs would be a good start, instead of
> one giant catalina.out file.
>
> Best,
> Alec
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Logging Best Practices on RHEL

Posted by Dale Ogilvie <Da...@trimble.com>.
We chose slf4j with log4j underneath.

1. slf4j has nice optimal syntax:

Log.debug("The logged in user is {} {}",firstName,lastName);
http://www.slf4j.org/faq.html#logging_performance

2. It has bridging apis to route other logging frameworks. If you are
using other libraries which use a different logging framework, you could
capture these logs via a bridge.
http://www.slf4j.org/legacy.html

Dale

-----Original Message-----
From: Tomcat Random [mailto:tomcat.random@gmail.com] 
Sent: Thursday, 28 November 2013 5:45 a.m.
To: Tomcat Users List
Subject: Logging Best Practices on RHEL

I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are
handled with e.printStackTrace() and go to catalina.out, which doesn't
rotate.

Could someone be so kind as to recommend a better way to handle logging,
with specific steps. Daily error logs would be a good start, instead of
one giant catalina.out file.

Best,
Alec

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Logging Best Practices on RHEL

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alec,

On 11/27/13, 12:35 PM, Tomcat Random wrote:
> Yes, Yuk indeed.
> 
> So just to clarify, you recommend using log4j, and replacing all
> my printStackTrace with log4j specific code. Would that be
> correct?

It's really a matter of personal preference which API you use. You can
use the logger's API or you can use a façade API like slf4j or
commons-logging. For building frameworks, use of something like slf4j
or commons-logging makes sense because you want "the user" to be able
to use whatever logger they want with your software.

Since you are the user, you get to pick no matter what so I think they
are not necessary in your case.

As for logging framework, yes, I would recommend using log4j because I
believe it to be superior to java.util.logging.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSljeIAAoJEBzwKT+lPKRYQnAP/2N0Vnf1vT9cVLipp9x2wWDQ
qOzSoeGVG22EKdSxkfXY7Ny9ikNQkL42VDHEjTW/J2vZPnL4qx4auBSZW3GdSN86
n3eTBqwEk/atyJJNDPWfXFo3uwZBp5odiWRW3dqQ5Ej9lWk7MnV8woH+fsC94FUb
FyyBCftoE6GK4+6uM4SpNt18jKznPqMtP5VNjpl0o4Gzi3er1rmOwMymJHyfhbAF
iuVQ6H3j+Ves4RhOVwFvZ1/yHmfXRIy0JxwvNid+WsdRcQ1CgmvTKXcWu+5m8izU
+64YX5Tpr8Uzu9g18myf4qocuIrLQnaA2oXVDNJbSqNSLHXnIGvq0nX/zGRNwRYi
s1ZheMqyOoZ8+WxeeF6wO4szOu6K2t8/oQL7hrKPGV+76n+GfDgRYtFbrxq10c+s
s6VG71j5XyIe06x731m9M7sehbkV8yp4/mHwpGm2M2dYhOBewuxh9Mdm/Dc5eVLC
KqNYdO+oT3FtQZNKSyz/IpVUQ/E3D0j6FvAlLFSQqiptd6qOaHEgFzzeB7DkK1cb
iKMHF5q8LxTBKvazhDqFWZ2SGuhPu38X3+FgTvleoZ1qbx+Ow2Vmnks95Lt88wP5
1Y6mMx8ld7NF3syjL8zX+jpHVHaxUFfX3E3/5ZSp3Uz0FCV6e6ksPDG4a7RG3CZw
VkPIKkWMIwsL8278rFNJ
=0Q+K
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Logging Best Practices on RHEL

Posted by Tomcat Random <to...@gmail.com>.
Yes, Yuk indeed.

So just to clarify, you recommend using log4j, and replacing all my
printStackTrace with log4j specific code. Would that be correct?

Cheers,
Alec


On Wed, Nov 27, 2013 at 12:18 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alec,
>
> On 11/27/13, 11:45 AM, Tomcat Random wrote:
> > I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are
> > handled with e.printStackTrace() and go to catalina.out, which
> > doesn't rotate.
>
> Yuk.
>
> > Could someone be so kind as to recommend a better way to handle
> > logging, with specific steps.
>
> Yes and no. How to handle logging? Use a logging framework. log4j,
> java.logging are popular and there are others. I find java.logging to be
> ... frankly frustrating to configure. I would recommend log4j.
>
> As for API, both Apache commons-logging and slf4j are popular. Note that
> you need a "real" logging framework underneath to actually do the
> logging. I'm not sure if it's worthwhile adding that extra layer rather
> than simply coding directly to the logging framework's API. I have used
> log4j directly for years and I'm quite happy.
>
> The biggest problem is that you are going to have to modify a lot of
> your code. Every modification is trivial and easy, but if you are
> logging properly, then you probably have a big job ahead of you. Since
> you aren't using a logging framework, you probably don't have trace,
> debug, etc. logging so that makes things a bit easier... you just have
> to grep for "printStackTrace" and replace that with something like
> "logger.error("Bad stuff", exception);".
>
> > Daily error logs would be a good start, instead of one giant
> > catalina.out file.
>
> Any logging framework will be able to roll your files for you. Just read
> the docs for how to configure them to behave that way.
>
> There is a stop-gap measure if you are running on a reliable system:
> you can modify catalina.sh (or however you launch Tomcat) to pipe
> stdout to a program like chronolog instead of redirecting to a file.
> Chronolog was made to take stdin and write to a rolling file. I'm sure
> a setup like that is a big fragile, so keep your eyes on it. But it
> can get you out of a bind while you re-work your application to log
> properly.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSlilNAAoJEBzwKT+lPKRYi54P/2FpcDnAWieUq25COU+V294K
> wCNqBBc3cXMyHKF7x7PljUa5muZD/P6MjfnROzuQh9FPbhgpaSIGnShFdmDL5FGj
> BFzTItda8gV2iGWaW5J6ttO4S6IlaTsTLnQ0twDpu08dt5gkAWNDQKjP3fgZLySd
> GMhuwUm55wCiWNwVeRUbsvBvSj90lgM8ix0SA0s192/p6JUIEqkka9yNVmK5IDiE
> siwIM/k4X+g95wfBvT/Kxvh4j9/G+Nl/M/OQ7OIfNpDvJrTMKOya32n8N+OIGh3X
> 51vre9VPL0k5SRRupmfKb4iLNpR+5JKvDYmUsGKwWsJztMaEDU0b4ff03iisOv0o
> V0wH7++QnvRAa2rXQ2YVVtMR/sm/8PmG5olOr+nopcM8ZYF8j86WqjHW3lE1mddM
> k++KW8q+YgTNGn5i7z3LEQ67P3jCB0enrflPa2uqH1A2XhEdmTQR2k72TB4brF5t
> uyc5es8ZfMvKer69wlcAlgLYX8Z+HvPikE+KTV2zsaRPU+Aiy02jLp65peXn6NGh
> TJyeihZbnjMrN7/mv1HlRcNzU1RY14Vi2+VXS0aHh35lfSE8qqcPSEakw3w/jRRO
> VVNMus3VTuU/BehpauRtSsmha6bN7v0mZH1cH8NZLh3Qq0KfD67UreWGqDKpqCLQ
> 6rcewerS2IVIU947dJv+
> =lcU5
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Logging Best Practices on RHEL

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alec,

On 11/27/13, 11:45 AM, Tomcat Random wrote:
> I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are 
> handled with e.printStackTrace() and go to catalina.out, which 
> doesn't rotate.

Yuk.

> Could someone be so kind as to recommend a better way to handle 
> logging, with specific steps.

Yes and no. How to handle logging? Use a logging framework. log4j,
java.logging are popular and there are others. I find java.logging to be
... frankly frustrating to configure. I would recommend log4j.

As for API, both Apache commons-logging and slf4j are popular. Note that
you need a "real" logging framework underneath to actually do the
logging. I'm not sure if it's worthwhile adding that extra layer rather
than simply coding directly to the logging framework's API. I have used
log4j directly for years and I'm quite happy.

The biggest problem is that you are going to have to modify a lot of
your code. Every modification is trivial and easy, but if you are
logging properly, then you probably have a big job ahead of you. Since
you aren't using a logging framework, you probably don't have trace,
debug, etc. logging so that makes things a bit easier... you just have
to grep for "printStackTrace" and replace that with something like
"logger.error("Bad stuff", exception);".

> Daily error logs would be a good start, instead of one giant 
> catalina.out file.

Any logging framework will be able to roll your files for you. Just read
the docs for how to configure them to behave that way.

There is a stop-gap measure if you are running on a reliable system:
you can modify catalina.sh (or however you launch Tomcat) to pipe
stdout to a program like chronolog instead of redirecting to a file.
Chronolog was made to take stdin and write to a rolling file. I'm sure
a setup like that is a big fragile, so keep your eyes on it. But it
can get you out of a bind while you re-work your application to log
properly.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSlilNAAoJEBzwKT+lPKRYi54P/2FpcDnAWieUq25COU+V294K
wCNqBBc3cXMyHKF7x7PljUa5muZD/P6MjfnROzuQh9FPbhgpaSIGnShFdmDL5FGj
BFzTItda8gV2iGWaW5J6ttO4S6IlaTsTLnQ0twDpu08dt5gkAWNDQKjP3fgZLySd
GMhuwUm55wCiWNwVeRUbsvBvSj90lgM8ix0SA0s192/p6JUIEqkka9yNVmK5IDiE
siwIM/k4X+g95wfBvT/Kxvh4j9/G+Nl/M/OQ7OIfNpDvJrTMKOya32n8N+OIGh3X
51vre9VPL0k5SRRupmfKb4iLNpR+5JKvDYmUsGKwWsJztMaEDU0b4ff03iisOv0o
V0wH7++QnvRAa2rXQ2YVVtMR/sm/8PmG5olOr+nopcM8ZYF8j86WqjHW3lE1mddM
k++KW8q+YgTNGn5i7z3LEQ67P3jCB0enrflPa2uqH1A2XhEdmTQR2k72TB4brF5t
uyc5es8ZfMvKer69wlcAlgLYX8Z+HvPikE+KTV2zsaRPU+Aiy02jLp65peXn6NGh
TJyeihZbnjMrN7/mv1HlRcNzU1RY14Vi2+VXS0aHh35lfSE8qqcPSEakw3w/jRRO
VVNMus3VTuU/BehpauRtSsmha6bN7v0mZH1cH8NZLh3Qq0KfD67UreWGqDKpqCLQ
6rcewerS2IVIU947dJv+
=lcU5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org