Re: Logging format (port %p)

[Christoph Kukulies]

Sorry, a bit searching revealed: /var/lib/tomcat9/server.xml:




> Am 18.11.2023 um 14:48 schrieb Christoph Kukulies :
> 
> I'm running tomcat9 as a backend server and I have configured different 
> ports. For debugging purposes I would like to log the port
> a request is being sent through.
> 
> Where is the logging format "wired" into the config? At the moment I'm seeing 
> this
> (in root@mail:/var/lib/tomcat9/logs# tail -f  
> localhost_access_log.2023-11-18.txt ):
> 
> 127.0.0.1 - - [18/Nov/2023:14:41:08 +0100] "GET / HTTP/1.1" 404 5679
> 
> 
> 
> --
> Christoph
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Logging

[Christopher Schultz]

Kevin,

On 4/3/23 12:32, Kevin Huntly wrote:
ok, can you tell me what your thoughts are? I'm always interested in new 
things


I would recommend sending an alert to a realtime management system, if 
at all possible. There are no guarantees if the JVM experiences some 
trouble, but in my experience, OOME -> script to ping a management 
system is fairly reliable.


-chris


On Mon, Apr 3, 2023 at 12:31 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Kevin,

On 4/3/23 12:10, Kevin Huntly wrote:
 > idk why i add the typeset, but I do everywhere just out of habit.
i was
 > trained that way many many moons ago.
 >
 > Is there anything else in my setenv that needs work?

That mostly depends upon your environment. The only thing that stuck
out
to me was the JAVA_OPTS versus CATALINA_OPTS. I didn't even notice that
all the JMX configuration would have caused port conflicts, too. So
there is another reason to only use CATALINA_OPTS for that stuff.

Some of what you have in that script is not having any effect on Tomcat
itself. But it may be serving other purposes.

I have some personal thoughts about things like what should be done on
OOMEs but again those are very environment-specific.

-chris

 > On Mon, Apr 3, 2023 at 11:57 AM Christopher Schultz <
 > ch...@christopherschultz.net
> wrote:
 >
 >> Kevin,
 >>
 >> On 4/3/23 10:07, Kevin Huntly wrote:
 >>> I'm launching with startup.sh and I have a setenv:
 >>>
 >>> https://pastebin.com/PKRgz2y1 
 >>   >
 >>   > typeset JAVA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
 >> -Djava.awt.headless=true";
 >>
 >> You don't want this. You want:
 >>
 >> typeset CATALINA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
 >> -Djava.awt.headless=true";
 >>
 >> (I'm not sure why you are bothering with "typeset". IMHO it adds
nothing
 >> but extra characters to the file and or someone so say "what the
hell is
 >> typset?")
 >>
 >> CATALINA_OPTS are used when launching Tomcat. JAVA_OPTS are used
when
 >> launching any kind of JVM. An example is when shutting-down
Tomcat. Your
 >> JAVA_OPTS sets the heap size to 4 GiB, but you only need like
5MiB to
 >> launch the "please shutdown" process, so a 4GiB heap for that is
overkill.
 >>
 >> -chris
 >>
 >>> 
 >>>
 >>> Kevin Huntly
 >>> Email: kmhun...@gmail.com 
 >>> Cell: 716/424-3311
 >>> 
 >>>
 >>> -BEGIN GEEK CODE BLOCK-
 >>> Version: 1.0
 >>> GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
 >>> W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
 >>> PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
 >>> G++ e(+) h--- r+++ y+++*
 >>> --END GEEK CODE BLOCK--
 >>>
 >>>
 >>> On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
 >>> ch...@christopherschultz.net
> wrote:
 >>>
  Kevin,
 
  On 4/2/23 09:08, Kevin Huntly wrote:
 > Couple questions:
 >
 > 1. Is there a way to change the default "stdout" to a
different name?
  e.g.
 > SystemOut.log (and by extension, can syserr be printed to
something
 > SystemErr.log?)
 
  How are you launching Tomcat?
 
 > 2. When verbose:gc is turned on it logs a ton of stuff to
stdout, can
  that
 > output be redirected to a different file?
 
  Have you tried google or "java -X"?
 
  -chris
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

  For additional commands, e-mail: users-h...@tomcat.apache.org

 
 
 >>>
 >>
 >>
-
 >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

 >> For additional commands, e-mail: users-h...@tomcat.apache.org

 >>
 >>
 >



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

Re: Logging

[Kevin Huntly]

ok, can you tell me what your thoughts are? I'm always interested in new
things


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 12:31 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Kevin,
>
> On 4/3/23 12:10, Kevin Huntly wrote:
> > idk why i add the typeset, but I do everywhere just out of habit. i was
> > trained that way many many moons ago.
> >
> > Is there anything else in my setenv that needs work?
>
> That mostly depends upon your environment. The only thing that stuck out
> to me was the JAVA_OPTS versus CATALINA_OPTS. I didn't even notice that
> all the JMX configuration would have caused port conflicts, too. So
> there is another reason to only use CATALINA_OPTS for that stuff.
>
> Some of what you have in that script is not having any effect on Tomcat
> itself. But it may be serving other purposes.
>
> I have some personal thoughts about things like what should be done on
> OOMEs but again those are very environment-specific.
>
> -chris
>
> > On Mon, Apr 3, 2023 at 11:57 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Kevin,
> >>
> >> On 4/3/23 10:07, Kevin Huntly wrote:
> >>> I'm launching with startup.sh and I have a setenv:
> >>>
> >>> https://pastebin.com/PKRgz2y1
> >>   >
> >>   > typeset JAVA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
> >> -Djava.awt.headless=true";
> >>
> >> You don't want this. You want:
> >>
> >> typeset CATALINA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
> >> -Djava.awt.headless=true";
> >>
> >> (I'm not sure why you are bothering with "typeset". IMHO it adds nothing
> >> but extra characters to the file and or someone so say "what the hell is
> >> typset?")
> >>
> >> CATALINA_OPTS are used when launching Tomcat. JAVA_OPTS are used when
> >> launching any kind of JVM. An example is when shutting-down Tomcat. Your
> >> JAVA_OPTS sets the heap size to 4 GiB, but you only need like 5MiB to
> >> launch the "please shutdown" process, so a 4GiB heap for that is
> overkill.
> >>
> >> -chris
> >>
> >>> 
> >>>
> >>> Kevin Huntly
> >>> Email: kmhun...@gmail.com
> >>> Cell: 716/424-3311
> >>> 
> >>>
> >>> -BEGIN GEEK CODE BLOCK-
> >>> Version: 1.0
> >>> GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> >>> W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> >>> PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> >>> G++ e(+) h--- r+++ y+++*
> >>> --END GEEK CODE BLOCK--
> >>>
> >>>
> >>> On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
> >>> ch...@christopherschultz.net> wrote:
> >>>
>  Kevin,
> 
>  On 4/2/23 09:08, Kevin Huntly wrote:
> > Couple questions:
> >
> > 1. Is there a way to change the default "stdout" to a different name?
>  e.g.
> > SystemOut.log (and by extension, can syserr be printed to something
> > SystemErr.log?)
> 
>  How are you launching Tomcat?
> 
> > 2. When verbose:gc is turned on it logs a ton of stuff to stdout, can
>  that
> > output be redirected to a different file?
> 
>  Have you tried google or "java -X"?
> 
>  -chris
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>

Re: Logging

[Christopher Schultz]

Kevin,

On 4/3/23 12:10, Kevin Huntly wrote:

idk why i add the typeset, but I do everywhere just out of habit. i was
trained that way many many moons ago.

Is there anything else in my setenv that needs work?


That mostly depends upon your environment. The only thing that stuck out 
to me was the JAVA_OPTS versus CATALINA_OPTS. I didn't even notice that 
all the JMX configuration would have caused port conflicts, too. So 
there is another reason to only use CATALINA_OPTS for that stuff.


Some of what you have in that script is not having any effect on Tomcat 
itself. But it may be serving other purposes.


I have some personal thoughts about things like what should be done on 
OOMEs but again those are very environment-specific.


-chris


On Mon, Apr 3, 2023 at 11:57 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kevin,

On 4/3/23 10:07, Kevin Huntly wrote:

I'm launching with startup.sh and I have a setenv:

https://pastebin.com/PKRgz2y1

  >
  > typeset JAVA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
-Djava.awt.headless=true";

You don't want this. You want:

typeset CATALINA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
-Djava.awt.headless=true";

(I'm not sure why you are bothering with "typeset". IMHO it adds nothing
but extra characters to the file and or someone so say "what the hell is
typset?")

CATALINA_OPTS are used when launching Tomcat. JAVA_OPTS are used when
launching any kind of JVM. An example is when shutting-down Tomcat. Your
JAVA_OPTS sets the heap size to 4 GiB, but you only need like 5MiB to
launch the "please shutdown" process, so a 4GiB heap for that is overkill.

-chris




Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kevin,

On 4/2/23 09:08, Kevin Huntly wrote:

Couple questions:

1. Is there a way to change the default "stdout" to a different name?

e.g.

SystemOut.log (and by extension, can syserr be printed to something
SystemErr.log?)


How are you launching Tomcat?


2. When verbose:gc is turned on it logs a ton of stuff to stdout, can

that

output be redirected to a different file?


Have you tried google or "java -X"?

-chris

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






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






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

Re: Logging

[Kevin Huntly]

idk why i add the typeset, but I do everywhere just out of habit. i was
trained that way many many moons ago.

Is there anything else in my setenv that needs work?


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 11:57 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Kevin,
>
> On 4/3/23 10:07, Kevin Huntly wrote:
> > I'm launching with startup.sh and I have a setenv:
> >
> > https://pastebin.com/PKRgz2y1
>  >
>  > typeset JAVA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
> -Djava.awt.headless=true";
>
> You don't want this. You want:
>
> typeset CATALINA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8
> -Djava.awt.headless=true";
>
> (I'm not sure why you are bothering with "typeset". IMHO it adds nothing
> but extra characters to the file and or someone so say "what the hell is
> typset?")
>
> CATALINA_OPTS are used when launching Tomcat. JAVA_OPTS are used when
> launching any kind of JVM. An example is when shutting-down Tomcat. Your
> JAVA_OPTS sets the heap size to 4 GiB, but you only need like 5MiB to
> launch the "please shutdown" process, so a 4GiB heap for that is overkill.
>
> -chris
>
> > 
> >
> > Kevin Huntly
> > Email: kmhun...@gmail.com
> > Cell: 716/424-3311
> > 
> >
> > -BEGIN GEEK CODE BLOCK-
> > Version: 1.0
> > GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> > W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> > PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> > G++ e(+) h--- r+++ y+++*
> > --END GEEK CODE BLOCK--
> >
> >
> > On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Kevin,
> >>
> >> On 4/2/23 09:08, Kevin Huntly wrote:
> >>> Couple questions:
> >>>
> >>> 1. Is there a way to change the default "stdout" to a different name?
> >> e.g.
> >>> SystemOut.log (and by extension, can syserr be printed to something
> >>> SystemErr.log?)
> >>
> >> How are you launching Tomcat?
> >>
> >>> 2. When verbose:gc is turned on it logs a ton of stuff to stdout, can
> >> that
> >>> output be redirected to a different file?
> >>
> >> Have you tried google or "java -X"?
> >>
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Logging

[Christopher Schultz]

Kevin,

On 4/3/23 10:07, Kevin Huntly wrote:

I'm launching with startup.sh and I have a setenv:

https://pastebin.com/PKRgz2y1

>
> typeset JAVA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8 
-Djava.awt.headless=true";


You don't want this. You want:

typeset CATALINA_OPTS="-Xms4096m -Xmx4096m -Dfile.encoding=utf-8 
-Djava.awt.headless=true";


(I'm not sure why you are bothering with "typeset". IMHO it adds nothing 
but extra characters to the file and or someone so say "what the hell is 
typset?")


CATALINA_OPTS are used when launching Tomcat. JAVA_OPTS are used when 
launching any kind of JVM. An example is when shutting-down Tomcat. Your 
JAVA_OPTS sets the heap size to 4 GiB, but you only need like 5MiB to 
launch the "please shutdown" process, so a 4GiB heap for that is overkill.


-chris




Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kevin,

On 4/2/23 09:08, Kevin Huntly wrote:

Couple questions:

1. Is there a way to change the default "stdout" to a different name?

e.g.

SystemOut.log (and by extension, can syserr be printed to something
SystemErr.log?)


How are you launching Tomcat?


2. When verbose:gc is turned on it logs a ton of stuff to stdout, can

that

output be redirected to a different file?


Have you tried google or "java -X"?

-chris

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






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

Re: Logging

[Christopher Schultz]

Kevin,

On 4/3/23 10:07, Kevin Huntly wrote:

I'm launching with startup.sh and I have a setenv:


bin/startup.sh calls bin/catalina.sh. Have a look at the top few pages 
of catalina.sh to see what environment variables can be used to 
customize stuff like log file names.



https://pastebin.com/PKRgz2y1


It looks like you are already setting CATALINA_OUT. You should just be 
able to change the value to use a different file name.


The existing catalina.sh does not allow separate stdout and stderr 
streams. You could modify catalina.sh to easily redirect stderr to a 
different file if you wanted to.


-chris




Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kevin,

On 4/2/23 09:08, Kevin Huntly wrote:

Couple questions:

1. Is there a way to change the default "stdout" to a different name?

e.g.

SystemOut.log (and by extension, can syserr be printed to something
SystemErr.log?)


How are you launching Tomcat?


2. When verbose:gc is turned on it logs a ton of stuff to stdout, can

that

output be redirected to a different file?


Have you tried google or "java -X"?

-chris

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






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

Re: Logging

[Kevin Huntly]

I'm launching with startup.sh and I have a setenv:

https://pastebin.com/PKRgz2y1


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 3, 2023 at 10:03 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Kevin,
>
> On 4/2/23 09:08, Kevin Huntly wrote:
> > Couple questions:
> >
> > 1. Is there a way to change the default "stdout" to a different name?
> e.g.
> > SystemOut.log (and by extension, can syserr be printed to something
> > SystemErr.log?)
>
> How are you launching Tomcat?
>
> > 2. When verbose:gc is turned on it logs a ton of stuff to stdout, can
> that
> > output be redirected to a different file?
>
> Have you tried google or "java -X"?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Logging

[Christopher Schultz]

Kevin,

On 4/2/23 09:08, Kevin Huntly wrote:

Couple questions:

1. Is there a way to change the default "stdout" to a different name? e.g.
SystemOut.log (and by extension, can syserr be printed to something
SystemErr.log?)


How are you launching Tomcat?


2. When verbose:gc is turned on it logs a ton of stuff to stdout, can that
output be redirected to a different file?


Have you tried google or "java -X"?

-chris

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

Re: Logging "location" header from the HTTP response

[Robert Hicks]

On Thu, May 26, 2022 at 11:37 AM Konstantin Kolinko 
wrote:

> чт, 26 мая 2022 г. в 18:19, Robert Hicks :
> >
> > We would like to start logging the response location in Tomcat. I am not
> > sure where to look something like that up.
>
> You are not mentioning the version number, but from other threads I
> assume that it is 9.0.x.
>
> Here:
> https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
>
> Look for "%{xxx}o"
>
> Best regards,
> Konstantin Kolinko
>

Thanks! I see how to do it now.

Bob

Re: Logging "location" header from the HTTP response

[Konstantin Kolinko]

чт, 26 мая 2022 г. в 18:19, Robert Hicks :
>
> We would like to start logging the response location in Tomcat. I am not
> sure where to look something like that up.

You are not mentioning the version number, but from other threads I
assume that it is 9.0.x.

Here:
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve

Look for "%{xxx}o"

Best regards,
Konstantin Kolinko

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

Re: Logging Information when Tomcat reaches max thread limit

[Suvendu Sekhar Mondal]

Hello Aquib,

On Mon, Nov 2, 2020 at 10:09 AM Aquib Khan  wrote:
>
> Hi,
>
> We have a usecase where we want that our application should indicate when it 
> reaches maximum thread limit. Our application is deployed in tomcat. Maximum 
> thread limit of tomcat is 200,  so If 200 threads are reached, does tomcat 
> provide any logger information?
>

As far as I know, there is no logging which will tell you that the
thread pool got exhausted but I am pretty sure your application will
react to it by throwing connection related exception as you mentioned
below.
> We tried making multiple rest calls and reducing max threads to 2-3. We faced 
> ConnectionRefused and socketTimeout Exceptions on client side. But no 
> exception or logger in Catalina logs. We changed Logging level as well in 
> logging.properties.
>
> We tried Changing values of maxThreads, minspareThread, acceptCount in 
> server.xml. We used Jmeter for making rest calls.
>
> Can we get any help here? Does tomcat provides any information when it 
> reaches max thread limit? Do we have to change any property in server.xml or 
> in logging.properties
>

Tomcat exposes different thread pool properties via JMX which are
available under JMX Object Name:"Catalina:type=ThreadPool". I think in
your case "currentThreadCount" and "currentThreadsBusy" will be
helpful. "currentThreadCount" will give you thread pool size.
"currentThreadsBusy" will tell you how many threads are busy
processing requests. Normally if the "currentThreadsBusy" count goes
up then it indicates either you have thread blocking or lots of
requests are coming in. Based on those numbers, you need to decide on
the thread pool size. There are more properties and operations exposed
via JMX. You can explore all of them by using jconsole or JMC. If you
have any Application Performance Management(APM) tool like
AppDynamics, Dynatrace, New Relic etc. it will make your life a bit
easier. Those tools usually can throw alerts if thread pool
utilization is high and based on which you can act.

> Any help in this regard would be highly appreciable.
> Thanks in Advance.
>
> Regards,
> Aquib

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

Re: Logging Rewrite Activity

[Felix Schumacher]

Am 06.08.20 um 21:36 schrieb Jerry Malcolm:
> How do configure TC to log the activities of the RewriteValve?  I added
>
> org.apache.catalina.valves.rewrite.RewriteValve.level = FINE
>
> to logging.properties.  But I'm not seeing any output related to
> rewrite. Do I have the logging config wrong?  Am I looking in the
> wrong place for the log data?

Where are you looking?

The config in logging.properties is the right place (assuming you edited
the $CATALINA_BASE/conf/logging.properties file).

Felix

>
> Thx
>
> Jerry
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: Logging web applications with log4j 1.2

[John Dale]

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 way.  Anyone else have a suggestion?

On 2/21/19, Thomas Rohde  wrote:
> 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-
>> > 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 ships the log4j.jar in
>> > WEB-INF/lib. The Tomcat itself uses JULI.
>> >
>> > We are using a common log4j.xml file for configuration.
>> >
>> > The file path is set as system property in CATALINA_OPTS as
>> > follows: -Dlog4j.configuration=/path/to/file/log4j.xml
>> >
>> > 1. Is this a valid setup or are there any side effects in
>> > initialization log4j by the different WebAppClassLoaders?
>>
>> You are not using classpath-based config-file-loading, so it should not be
>> a problem[*].
>>
>> > 2. We are observing weird things in rolling the files hourly. The
>> > timestamp of the log messages doesn't fit to the timestamp suffix of
>> > the file. Why does this happen?
>>
>> Possibly conflicting time zones, somewhere? Because log4j.jar is in each
>> application's class loader, they CAN have different in-memory
>> configurations.
> No there are no different time zones in use.
>
>>
>> [*] While this will work, why would you ever want multiple applications to
>> have their logging configuration all tied together?
>> Why not separate the logging configuration into one config-per web
>> application? OR are you trying to unify all logging into the same file(s
>> )?
> Yes I would like to do that, but I'm not sure how to achieve it without
> putting the log4j.xml into the WAR file. Do you have any hint?
>
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxtdSUACgkQHPApP6U8
>> pFhxow//T+5ALVYJcljqLxykHND7ZSy9NHf0+a+jnWzlDO5S6oO+bxjso9raJZYC
>> jUG4nhBwuAtD5MWyS04t0UedYUBP+n1iw4aAGs7PrhFgPxLiHZpMOTBBaeDSYgny
>> bI+7GuqOhkiauPA8Jb6guE8SkrT18d9X+k7xzy6puYgqbTws0iwk2yEmSV+KNtXy
>> 0EsVC20KGhU9pCdD7MLSpYX8PaM8sctazxSSVMygL9Ed03WKkJ6BRPavq4ao1uGg
>> V0ZlTQb7f9PRPOXOQzoAlsaWNTCVRKQES82/HHJE/uJG5tg7jnQ5Syjs53FyfVwH
>> 0AtfNpJiOI4LES5ejR7E5JZ8Lx0/J41XwsPO5hOmYaiHHs35EFtozCETNNwjYxcb
>> 245z++YsBw0bnBDRpAFi5Kq5UL8ludo0CqDTfKQSIqrMoNHoiULm4U3niGl2P01w
>> O8k2KrwqtYWu77esh+TpJpXTTaLnEhCc+YWFGWnER3w8WAOHitvjbmAi21gL3NIG
>> 3PJEFEdrNMaoI2h3SkK+DJzuVVJRmXRMV2wduX4+3qGW6l31Jo3ihFiDDdXyGB+b
>> jtpU1JHYfYP+ck8mEXgOvI6RXZEG7R8Ef7ectYuKdhRRpE+S9wx1llZminsxY/fr
>> 0apA+L6paBo9R7EGxJVt237wx/L+tRnfF5raLZoAJrkks7SkWgE=
>> =sjai
>> -END PGP SIGNATURE-
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: Logging web applications with log4j 1.2

[Christopher Schultz]

-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 ships the log4j.jar in
> WEB-INF/lib. The Tomcat itself uses JULI.
> 
> We are using a common log4j.xml file for configuration.
> 
> The file path is set as system property in CATALINA_OPTS as
> follows: -Dlog4j.configuration=/path/to/file/log4j.xml
> 
> 1. Is this a valid setup or are there any side effects in
> initialization log4j by the different WebAppClassLoaders?

You are not using classpath-based config-file-loading, so it should
not be a problem[*].

> 2. We are observing weird things in rolling the files hourly. The
> timestamp of the log messages doesn't fit to the timestamp suffix
> of the file. Why does this happen?

Possibly conflicting time zones, somewhere? Because log4j.jar is in
each application's class loader, they CAN have different in-memory
configurations.

[*] While this will work, why would you ever want multiple
applications to have their logging configuration all tied together?
Why not separate the logging configuration into one config-per web
application? OR are you trying to unify all logging into the same file(s
)?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxtdSUACgkQHPApP6U8
pFhxow//T+5ALVYJcljqLxykHND7ZSy9NHf0+a+jnWzlDO5S6oO+bxjso9raJZYC
jUG4nhBwuAtD5MWyS04t0UedYUBP+n1iw4aAGs7PrhFgPxLiHZpMOTBBaeDSYgny
bI+7GuqOhkiauPA8Jb6guE8SkrT18d9X+k7xzy6puYgqbTws0iwk2yEmSV+KNtXy
0EsVC20KGhU9pCdD7MLSpYX8PaM8sctazxSSVMygL9Ed03WKkJ6BRPavq4ao1uGg
V0ZlTQb7f9PRPOXOQzoAlsaWNTCVRKQES82/HHJE/uJG5tg7jnQ5Syjs53FyfVwH
0AtfNpJiOI4LES5ejR7E5JZ8Lx0/J41XwsPO5hOmYaiHHs35EFtozCETNNwjYxcb
245z++YsBw0bnBDRpAFi5Kq5UL8ludo0CqDTfKQSIqrMoNHoiULm4U3niGl2P01w
O8k2KrwqtYWu77esh+TpJpXTTaLnEhCc+YWFGWnER3w8WAOHitvjbmAi21gL3NIG
3PJEFEdrNMaoI2h3SkK+DJzuVVJRmXRMV2wduX4+3qGW6l31Jo3ihFiDDdXyGB+b
jtpU1JHYfYP+ck8mEXgOvI6RXZEG7R8Ef7ectYuKdhRRpE+S9wx1llZminsxY/fr
0apA+L6paBo9R7EGxJVt237wx/L+tRnfF5raLZoAJrkks7SkWgE=
=sjai
-END PGP SIGNATURE-

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

Re: Logging web applications with log4j 1.2

[John Dale]

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 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 file for configuration.
>
> The file path is set as system property in CATALINA_OPTS as follows:
> -Dlog4j.configuration=/path/to/file/log4j.xml
>
> 1. Is this a valid setup or are there any side effects in initialization
> log4j by the different WebAppClassLoaders?
>
> 2. We are observing weird things in rolling the files hourly. The timestamp
> of the log messages doesn't fit to the timestamp suffix of the file. Why
> does this happen?
>
> Regards,
> Thomas
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: Logging framework

[Daniel Baktiar]

Hi Mirunalini,

Are you sure that the catalina.sh that you execute is actually picking up
from the one that you have downloaded?
Do you have any tomcat installed from other sources, such as from the
centos 7.3?

For a very long period of time, I have never seen Tomcat written as
"jakarta-tomcat" in any of recent download versions (including version
7.0). It's been spun off from Apache Jakarta project long time ago. I
suspect some of your configuration is actually picking up from the centos
packaged version of tomcat.

You can see whether there's a centos bundled tomcat installed by executing:

sudo yum list | grep tomcat

If it shows any tomcat, uninstall it using (I am assuming this is your
development machine, not production machine):

sudo yum remove 

Regards,
Daniel Baktiar


On Tue, Dec 12, 2017 at 5:43 PM, mirunalini Chandrasekaran <
miru3...@gmail.com> wrote:

> Hi,
>
> This is how i guess tomcat starts, and also it uses the startup script with
> catalina.sh file.
>
> ps -ef | grep tomcat
>
> root  1357 1  0 11:53 ?00:00:08
> /usr/local/thirdparty/java/jdk/bin/java -classpath
> :/usr/local/thirdparty/jakarta-tomcat/lib/javax.ws.
> rs-api-2.0.jar:/usr/local/thirdparty/jakarta-tomca
> /lib/jersey-client.jar:/usr/local/thirdparty/jakarta-
> tomcat/lib/jersey-common.jar:/usr/local/thirdparty/jakarta-
> tomcat/lib/hk2-api-2.3.0-b05.jar:/usr/local/thirdparty/
> jakarta-tomcat/lib/jersey-guava-2.10.1.jar:/usr/local/
> thirdparty/jakarta-tomcat/lib/javax-inject.jar:/usr/local/
> thirdparty/jakarta-tomcat/lib/hk2-locator-2.3.0-b05.jar:/
> usr/local/thirdparty/jakarta-tomcat/lib/hk2-utils-2.3.0-
> b05.jar:/usr/local/thirdparty/jakarta-tomcat/lib/javax.
> annotation-api-1.2.jar:/usr/local/thirdparty/jakarta-
> tomcat/lib/catalina.jar:/usr/local/platform/jar/
> cucminventory-tcpserver.jar
> com.cisco.cucminventory.server.MultiThreadedTCPServer
> root  6115  5927  0 15:05 pts/000:00:00 grep --color=auto tomcat
> root 27529 1  0 11:57 ?00:00:00 /home/tomcat/tomcat -user
> tomcat -home /usr/local/thirdparty/java/j2sdk -pidfile
> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
> /home/tomcat/tomcat -outfile
> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
> -Djava.library.path=/usr/local/cm/lib:/usr/local/lib:/
> usr/local/thirdparty/java/j2sdk/jre/lib/i386:/usr/local/
> thirdparty/java/j2sdk/jre/lib/i386/server:/usr/lib/pgsql:/
> usr/lib:/usr/local/cm/lib::/usr/local/platform/lib
> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/
> tomcat/trust-certs/tomcat-trust.keystore
> -Djavax.net.ssl.trustStorePassword=
> -XX:ErrorFile=/usr/local/thirdparty/jakarta-tomcat/
> logs/diagnostic-info.jvm-crash.%p.tomcat.txt
> -Dsun.zip.disableMemoryMapping=true
> -XX:OnOutOfMemoryError=/tomcat_diagnostics.sh
> -XX:OnError=/tomcat_diagnostics.sh -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Dlog4j.configuration=file:/usr/local/thirdparty/jakarta-
> tomcat/webapps/log4jinit/log4j.xml
> -Xmx1824m -Xms256m -XX:MaxPermSize=448m
> -Djava.endorsed.dirs=/usr/local/thirdparty/jakarta-tomcat/endorsed -cp
> :/common/download:/usr/local/platform/application_locale/
> platform-api:/usr/local/platform/application_locale/cmplatform:/usr/local/
> platform/application_locale:/usr/local/cm/application_
> locale/cmservices:/usr/local/cm/application_locale/car:/
> usr/local/cm/application_locale/ccmadmin:/usr/local/cm/
> application_locale/ucmuser:/usr/local/cm/application_
> locale:/etc/opt/cisco/elm/server/resource:/usr/local/
> thirdparty/jakarta-tomcat/bin/bootstrap.jar::/usr/local/
> thirdparty/jakarta-tomcat/bin/tomcat-juli.jar
> -Djava.security.policy==/usr/local/thirdparty/jakarta-
> tomcat/conf/catalina.policy
> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
> org.apache.catalina.startup.Bootstrap start
> tomcat   27530 27529  6 11:57 ?00:12:50 /home/tomcat/tomcat -user
> tomcat -home /usr/local/thirdparty/java/j2sdk -pidfile
> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
> /home/tomcat/tomcat -outfile
> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
> -Djava.library.path=/usr/local/cm/lib:/usr/local/lib:/
> usr/local/thirdparty/java/j2sdk/jre/lib/i386:/usr/local/
> thirdparty/java/j2sdk/jre/lib/i386/server:/usr/lib/pgsql:/
> usr/lib:/usr/local/cm/lib::/usr/local/platform/lib
> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/
> tomcat/trust-certs/tomcat-trust.keystore
> -Djavax.net.ssl.trustStorePassword=
> -XX:ErrorFile=/usr/local/thirdparty/jakarta-tomcat/
> logs/diagnostic-info.jvm-crash.%p.tomcat.txt
> -Dsun.zip.disableMemoryMapping=true
> -XX:OnOutOfMemoryError=/tomcat_diagnostics.sh
> -XX:OnError=/tomcat_diagnostics.sh -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Re: Logging framework

[mirunalini Chandrasekaran]

Hi,

This is how i guess tomcat starts, and also it uses the startup script with
catalina.sh file.

ps -ef | grep tomcat

root  1357 1  0 11:53 ?00:00:08
/usr/local/thirdparty/java/jdk/bin/java -classpath
:/usr/local/thirdparty/jakarta-tomcat/lib/javax.ws.rs-api-2.0.jar:/usr/local/thirdparty/jakarta-tomca
/lib/jersey-client.jar:/usr/local/thirdparty/jakarta-tomcat/lib/jersey-common.jar:/usr/local/thirdparty/jakarta-tomcat/lib/hk2-api-2.3.0-b05.jar:/usr/local/thirdparty/jakarta-tomcat/lib/jersey-guava-2.10.1.jar:/usr/local/thirdparty/jakarta-tomcat/lib/javax-inject.jar:/usr/local/thirdparty/jakarta-tomcat/lib/hk2-locator-2.3.0-b05.jar:/usr/local/thirdparty/jakarta-tomcat/lib/hk2-utils-2.3.0-b05.jar:/usr/local/thirdparty/jakarta-tomcat/lib/javax.annotation-api-1.2.jar:/usr/local/thirdparty/jakarta-tomcat/lib/catalina.jar:/usr/local/platform/jar/cucminventory-tcpserver.jar
com.cisco.cucminventory.server.MultiThreadedTCPServer
root  6115  5927  0 15:05 pts/000:00:00 grep --color=auto tomcat
root 27529 1  0 11:57 ?00:00:00 /home/tomcat/tomcat -user
tomcat -home /usr/local/thirdparty/java/j2sdk -pidfile
/usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
/home/tomcat/tomcat -outfile
/usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
-Djava.library.path=/usr/local/cm/lib:/usr/local/lib:/usr/local/thirdparty/java/j2sdk/jre/lib/i386:/usr/local/thirdparty/java/j2sdk/jre/lib/i386/server:/usr/lib/pgsql:/usr/lib:/usr/local/cm/lib::/usr/local/platform/lib
-Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-certs/tomcat-trust.keystore
-Djavax.net.ssl.trustStorePassword=
-XX:ErrorFile=/usr/local/thirdparty/jakarta-tomcat/logs/diagnostic-info.jvm-crash.%p.tomcat.txt
-Dsun.zip.disableMemoryMapping=true
-XX:OnOutOfMemoryError=/tomcat_diagnostics.sh
-XX:OnError=/tomcat_diagnostics.sh -Djdk.tls.ephemeralDHKeySize=2048
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Dlog4j.configuration=file:/usr/local/thirdparty/jakarta-tomcat/webapps/log4jinit/log4j.xml
-Xmx1824m -Xms256m -XX:MaxPermSize=448m
-Djava.endorsed.dirs=/usr/local/thirdparty/jakarta-tomcat/endorsed -cp
:/common/download:/usr/local/platform/application_locale/platform-api:/usr/local/platform/application_locale/cmplatform:/usr/local/platform/application_locale:/usr/local/cm/application_locale/cmservices:/usr/local/cm/application_locale/car:/usr/local/cm/application_locale/ccmadmin:/usr/local/cm/application_locale/ucmuser:/usr/local/cm/application_locale:/etc/opt/cisco/elm/server/resource:/usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar::/usr/local/thirdparty/jakarta-tomcat/bin/tomcat-juli.jar
-Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catalina.policy
-Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
-Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
-Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
org.apache.catalina.startup.Bootstrap start
tomcat   27530 27529  6 11:57 ?00:12:50 /home/tomcat/tomcat -user
tomcat -home /usr/local/thirdparty/java/j2sdk -pidfile
/usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
/home/tomcat/tomcat -outfile
/usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
-Djava.library.path=/usr/local/cm/lib:/usr/local/lib:/usr/local/thirdparty/java/j2sdk/jre/lib/i386:/usr/local/thirdparty/java/j2sdk/jre/lib/i386/server:/usr/lib/pgsql:/usr/lib:/usr/local/cm/lib::/usr/local/platform/lib
-Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-certs/tomcat-trust.keystore
-Djavax.net.ssl.trustStorePassword=
-XX:ErrorFile=/usr/local/thirdparty/jakarta-tomcat/logs/diagnostic-info.jvm-crash.%p.tomcat.txt
-Dsun.zip.disableMemoryMapping=true
-XX:OnOutOfMemoryError=/tomcat_diagnostics.sh
-XX:OnError=/tomcat_diagnostics.sh -Djdk.tls.ephemeralDHKeySize=2048
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Dlog4j.configuration=file:/usr/local/thirdparty/jakarta-tomcat/webapps/log4jinit/log4j.xml
-Xmx1824m -Xms256m -XX:MaxPermSize=448m
-Djava.endorsed.dirs=/usr/local/thirdparty/jakarta-tomcat/endorsed -cp
:/common/download:/usr/local/platform/application_locale/platform-api:/usr/local/platform/application_locale/cmplatform:/usr/local/platform/application_locale:/usr/local/cm/application_locale/cmservices:/usr/local/cm/application_locale/car:/usr/local/cm/application_locale/ccmadmin:/usr/local/cm/application_locale/ucmuser:/usr/local/cm/application_locale:/etc/opt/cisco/elm/server/resource:/usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar::/usr/local/thirdparty/jakarta-tomcat/bin/tomcat-juli.jar
-Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catalina.policy
-Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
-Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
-Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
org.apache.catalina.startup.Bootstrap start

Regards,
Mirunalini


On Fri, Dec 8, 2017 at 12:56 PM, Konstantin 

Re: Logging framework

[Konstantin Kolinko]

2017-12-08 9:58 GMT+03:00 mirunalini Chandrasekaran :
> Hi All,
>
> I am using Tomcat 7.0.81 on centos 7.3 and using openjdk 1.7.0.141. Tomcat
> was downloaded from http://tomcat.apache.org/
>
> The problem I am seeing recently is manager*.log and localhost*.log files
> are not created. Instead, I see the messages that were to be written into
> manager.log are going into Catalina.out. catalina.out and
> localhost_access.log continue to work like before. May I know how and from
> where to start debugging this?
> I have verified logging.properties, there is no issue with it.

How do you start Tomcat?

Overall, Tomcat uses the standard java.uti.logging API to perform its
logging. The java.util.logging is configured via the following two
system properties:

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties

These two properties are set by catalina.sh wrapper script when it
launches java process for Tomcat
If those properties are missing, the default configuration of
java.util.logging is to log everything to a
java.util.logging.ConsoleHandler.

The stdout and stderr of the java process are redirected to
"catalina.out" file by catalina.sh script. It is not a proper log
file.

Best regards,
Konstantin Kolinko

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

Re: Logging framework !

[Konstantin Kolinko]

2017-11-01 8:17 GMT+03:00 Utkarsh Dave :
> Hi All,
>
> I am using Tomcat 7.0.81 on centos 7.2 and using openjdk 1.7.0.141.
> The problem I am seeing recently is manager*.log and localhost*.log files
> are not created. Instead, I see the messages that were to be written into,
> manager.log are going into Catalina.out. catalina.out and
> localhost_access.log continue to work like before.
> May I know how and from where to start debugging this?
> I have verified logging.properties, there is no issue with it.
>

My guess is that "java.util.logging.manager" and
"java.util.logging.config.file" system properties are not set,
and thus java uses default implementation of java.util.logging instead
of the one provided by Tomcat's
org.apache.juli.ClassLoaderLogManager.

Those properties are usually set by catalina.sh (and there is a
comment at that top of that file).

Best regards,
Konstantin Kolinko

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

Re: Logging framework !

[tomcat]

On 01.11.2017 06:17, Utkarsh Dave wrote:

Hi All,

I am using Tomcat 7.0.81 on centos 7.2 and using openjdk 1.7.0.141.
The problem I am seeing recently is manager*.log and localhost*.log files
are not created. Instead, I see the messages that were to be written into,
manager.log are going into Catalina.out. catalina.out and
localhost_access.log continue to work like before.
May I know how and from where to start debugging this?
I have verified logging.properties, there is no issue with it.

Any help will be appreciable.



The first question here is : where does that tomcat 7.0.81 come from ?
If it is the "vanilla" tomcat from the tomcat website, then chances are that we can help 
you. If it is from a centos packaged version of tomcat, then there are less chances that 
we can help you, because we do not know exactly how the packagers of centos have set this up.


You probably need to start in that case by looking at the startup script(s) of tomcat, in 
/etc/init.d or similar, to find out what happens in terms of redirection of logfiles etc.


The people who create the tomcat packaged versions for the different Linux/Unix/Windows 
etc. distributions, each have their own logic about this kind of thing. Their intent is 
usually to try to "force" the tomcat logging to happen according to the general 
conventions on their particular platform, which can be quite different from the standard 
logging conventions of the various pieces of software that should run on each platform.



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

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Thanks,

Will explore JSSE options.

On Thu, Mar 9, 2017 at 7:18 PM, Jammy Chen  wrote:

> If you are using JSSE which you mentioned in earlier post, you probably can
> only enable debug for all or specially one
> -Djavax.net.debug=ssl:record or -Djavax.net.debug=ssl:handshake - but it
> will log all sessions
>
> You could try to register a customized SSL socket factory in JSSE, you may
> extend the default sun impl to overwrite the method, catch the exception
> and log the failure, and throw it.
>
> 2017-03-09 20:04 GMT+08:00 Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com>:
>
> > Our application meaning on RHEL machine within JVM with embedded tomcat
> > (with single web-app)
> >
> > Okay, tomcat may not have this information on handshake failures.
> >
> > I need to see little higher level for capturing these failures.
> >
> > Thanks for answers so far.
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) 
> > wrote:
> >
> > > On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
> > >
> > >> This is one of the requirement from FIPS/CC certification.
> > >>
> > >> Thanks,
> > >> Durga Srinivasu
> > >>
> > >>
> > > Durga,
> > >
> > > I believe that in your original post, you said :
> > > "We have a requirement in our application to log all TLS session
> > failures."
> > >
> > > You should probably have another look a the precise requirements, and
> the
> > > exact definition of "our application".
> > > Because it may be that the requirements are wrong, as far as you are
> > > concerned.
> > >
> > > It depends on what is included in "our application".
> > > In the java servlet container (like Tomcat) terminology, an
> "application"
> > > is a webapp.
> > > A webapp runs inside a servlet container.
> > > The servlet container (here Tomcat) runs inside a java JVM.
> > > The java JVM runs inside an OS.
> > > The OS runs inside a host.
> > >
> > > In that hierarchy, a webapp only sees a request, when the servlet
> > > container has received this request on one of its ports, and
> "delegates"
> > > the request to the webapp.
> > > By that time, the webapp does not even know through which interface the
> > > request came in, nor if that interface required HTTP, HTTPS or whatever
> > > other communications protocol.
> > > And if a TLS connection from a browser failed, the webapp is not even
> > > called, so it does not know anything about it.
> > > Of course the webapp cannot log a failure, if it is never called when
> > that
> > > failure happens.
> > >
> > > To move one level up : if a TLS connection from a browser fails, Tomcat
> > > probably never even sees that (because the connection never reaches
> > > Tomcat). So Tomcat cannot log this failure either. Tomcat is just
> telling
> > > some underlying layer of software (in the JVM, in the OS, or in some
> > > external library), what kind of connections to accept. But it does  not
> > > manage these connections, it just "gets" a connection when it succeeds.
> > >
> > > So if you (your team, your company) is responsible for providing the
> > whole
> > > service, including the host, the OS, the JVM, the servlet container,
> and
> > > the webapp inside it, then the requirement may make sense. And then you
> > > have to look for the component, at the right level, which can provide
> > that
> > > information. (But it is not the webapp, and it is not Tomcat).
> > >
> > > At the other extreme, if you are providing only the web application,
> then
> > > the requirement does not make sense /for you/, because it is
> impossible.
> > > It is not that it does not make sense in general, but "as part of the
> > > webapp" it does not make sense.
> > >
> > > And that is what Christopher is also telling you (in a lot less words).
> > >
> > >
> > >
> > > On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >>> Hash: SHA256
> > >>>
> > >>> Durga,
> > >>>
> > >>> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> > >>>
> >  We are using JSSE only not APR. Looking for handshake failures.
> > 
> >  Yes, using JSSE SSL debug, we are able to get all handshake
> >  (-Djavax.net.debug=ssl:handshake) logs including success cases.
> >  These are still quite bit expense logs and meant for debug
> >  purposes. As you said it might impact performance that's the
> >  reason, trying for any other optimal solution here.
> > 
> > >>>
> > >>> I know of no way to be notified about handshake failures on the
> server
> > >>> side. You may not be able to fulfill this requirement if using Java
> > >>> for your crypto.
> > >>>
> > >>> Honestly, I'm not sure why you care about failed TLS handshakes. Are
> > >>> you trying to implement a NIDS in your application? This is
> > >>> better-handled by a network component specifically-designed for this
> > >>> kind of thing.
> > >>>
> > >>> 

Re: Logging TLS Session Failures

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/9/17 3:34 AM, Durga Srinivasu Karuturi wrote:
> This is one of the requirement from FIPS/CC certification.

Can you provide a reference for this requirement?

- -chris

> On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Durga,
> 
> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
 We are using JSSE only not APR. Looking for handshake
 failures.
 
 Yes, using JSSE SSL debug, we are able to get all handshake 
 (-Djavax.net.debug=ssl:handshake) logs including success
 cases. These are still quite bit expense logs and meant for
 debug purposes. As you said it might impact performance
 that's the reason, trying for any other optimal solution
 here.
> 
> I know of no way to be notified about handshake failures on the
> server side. You may not be able to fulfill this requirement if
> using Java for your crypto.
> 
> Honestly, I'm not sure why you care about failed TLS handshakes.
> Are you trying to implement a NIDS in your application? This is 
> better-handled by a network component specifically-designed for
> this kind of thing.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYwYazAAoJEBzwKT+lPKRYZsAP/2H4FMI9PuZ6/PtwIgpmSea8
k9jJY50HVgf6OP0rYlzR57dvZnL/x3op9kzSCplTmgNZrRnltc36SzDN8dHQMKm6
Xi0MYnC2whf+Y2+Hh/4mvFnP4UCSiUXpTTLcXITG3x3BA84IPS179BMRSlV4W8MW
ZvLJ9z2mi8JZAqZq/aT7/b7Oq46BMSiomsi9so1fxr5PClqASIxFmhhQhIXhwnKx
1MevZ/6ZELD4vs1o9ek79JpVPVb5yillVTEK8RbSzWXEdgzKk26NI4xdRh8MZH6F
HkH358AANspDlhyAB+ofRmr1hzDSJ/kp58KxlQ439i8GqvtFd1TxUkoPF8Yk6aEI
ifv+FBsxsuW3vJFhbVShXJkLBO0GLiYAQezDnQ6tVWPGdeMkRPnQaSioaFrmsm6z
tL3vbjrj3ynTRadYVAF4mz+7R/uRBt3jUkB93J6dUzZqrBIiB/SwX4i97pKvQfeo
IOqdQAkVJMdb3IHaBJgLQd3No8Kbz/j9hC+VwQZmrpMi5jmjpLkHAjlyUuabvfqU
cko0vuCl/cCMbCBYm9c2J2zuhK3nzTBUpvXNVRP35+dkBSCrz2jYL/chOeqvdzcs
xSImhV4N0vn36lc9E+97ohha2RPR9uPvCp5DW9HFjmP+EqaH8Fbl4z2Wg5Twlaxo
scB4nofvUIxz2n7rRr//
=51TA
-END PGP SIGNATURE-

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

Re: Logging TLS Session Failures

[Jammy Chen]

If you are using JSSE which you mentioned in earlier post, you probably can
only enable debug for all or specially one
-Djavax.net.debug=ssl:record or -Djavax.net.debug=ssl:handshake - but it
will log all sessions

You could try to register a customized SSL socket factory in JSSE, you may
extend the default sun impl to overwrite the method, catch the exception
and log the failure, and throw it.

2017-03-09 20:04 GMT+08:00 Durga Srinivasu Karuturi <
durgasriniv...@gmail.com>:

> Our application meaning on RHEL machine within JVM with embedded tomcat
> (with single web-app)
>
> Okay, tomcat may not have this information on handshake failures.
>
> I need to see little higher level for capturing these failures.
>
> Thanks for answers so far.
>
> Thanks,
> Durga Srinivasu
>
> On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) 
> wrote:
>
> > On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
> >
> >> This is one of the requirement from FIPS/CC certification.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> > Durga,
> >
> > I believe that in your original post, you said :
> > "We have a requirement in our application to log all TLS session
> failures."
> >
> > You should probably have another look a the precise requirements, and the
> > exact definition of "our application".
> > Because it may be that the requirements are wrong, as far as you are
> > concerned.
> >
> > It depends on what is included in "our application".
> > In the java servlet container (like Tomcat) terminology, an "application"
> > is a webapp.
> > A webapp runs inside a servlet container.
> > The servlet container (here Tomcat) runs inside a java JVM.
> > The java JVM runs inside an OS.
> > The OS runs inside a host.
> >
> > In that hierarchy, a webapp only sees a request, when the servlet
> > container has received this request on one of its ports, and "delegates"
> > the request to the webapp.
> > By that time, the webapp does not even know through which interface the
> > request came in, nor if that interface required HTTP, HTTPS or whatever
> > other communications protocol.
> > And if a TLS connection from a browser failed, the webapp is not even
> > called, so it does not know anything about it.
> > Of course the webapp cannot log a failure, if it is never called when
> that
> > failure happens.
> >
> > To move one level up : if a TLS connection from a browser fails, Tomcat
> > probably never even sees that (because the connection never reaches
> > Tomcat). So Tomcat cannot log this failure either. Tomcat is just telling
> > some underlying layer of software (in the JVM, in the OS, or in some
> > external library), what kind of connections to accept. But it does  not
> > manage these connections, it just "gets" a connection when it succeeds.
> >
> > So if you (your team, your company) is responsible for providing the
> whole
> > service, including the host, the OS, the JVM, the servlet container, and
> > the webapp inside it, then the requirement may make sense. And then you
> > have to look for the component, at the right level, which can provide
> that
> > information. (But it is not the webapp, and it is not Tomcat).
> >
> > At the other extreme, if you are providing only the web application, then
> > the requirement does not make sense /for you/, because it is impossible.
> > It is not that it does not make sense in general, but "as part of the
> > webapp" it does not make sense.
> >
> > And that is what Christopher is also telling you (in a lot less words).
> >
> >
> >
> > On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> Durga,
> >>>
> >>> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> >>>
>  We are using JSSE only not APR. Looking for handshake failures.
> 
>  Yes, using JSSE SSL debug, we are able to get all handshake
>  (-Djavax.net.debug=ssl:handshake) logs including success cases.
>  These are still quite bit expense logs and meant for debug
>  purposes. As you said it might impact performance that's the
>  reason, trying for any other optimal solution here.
> 
> >>>
> >>> I know of no way to be notified about handshake failures on the server
> >>> side. You may not be able to fulfill this requirement if using Java
> >>> for your crypto.
> >>>
> >>> Honestly, I'm not sure why you care about failed TLS handshakes. Are
> >>> you trying to implement a NIDS in your application? This is
> >>> better-handled by a network component specifically-designed for this
> >>> kind of thing.
> >>>
> >>> - -chris
> >>> -BEGIN PGP SIGNATURE-
> >>> Comment: GPGTools - http://gpgtools.org
> >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>
> >>> iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
> >>> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
> >>> 

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Our application meaning on RHEL machine within JVM with embedded tomcat
(with single web-app)

Okay, tomcat may not have this information on handshake failures.

I need to see little higher level for capturing these failures.

Thanks for answers so far.

Thanks,
Durga Srinivasu

On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) 
wrote:

> On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
>
>> This is one of the requirement from FIPS/CC certification.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
> Durga,
>
> I believe that in your original post, you said :
> "We have a requirement in our application to log all TLS session failures."
>
> You should probably have another look a the precise requirements, and the
> exact definition of "our application".
> Because it may be that the requirements are wrong, as far as you are
> concerned.
>
> It depends on what is included in "our application".
> In the java servlet container (like Tomcat) terminology, an "application"
> is a webapp.
> A webapp runs inside a servlet container.
> The servlet container (here Tomcat) runs inside a java JVM.
> The java JVM runs inside an OS.
> The OS runs inside a host.
>
> In that hierarchy, a webapp only sees a request, when the servlet
> container has received this request on one of its ports, and "delegates"
> the request to the webapp.
> By that time, the webapp does not even know through which interface the
> request came in, nor if that interface required HTTP, HTTPS or whatever
> other communications protocol.
> And if a TLS connection from a browser failed, the webapp is not even
> called, so it does not know anything about it.
> Of course the webapp cannot log a failure, if it is never called when that
> failure happens.
>
> To move one level up : if a TLS connection from a browser fails, Tomcat
> probably never even sees that (because the connection never reaches
> Tomcat). So Tomcat cannot log this failure either. Tomcat is just telling
> some underlying layer of software (in the JVM, in the OS, or in some
> external library), what kind of connections to accept. But it does  not
> manage these connections, it just "gets" a connection when it succeeds.
>
> So if you (your team, your company) is responsible for providing the whole
> service, including the host, the OS, the JVM, the servlet container, and
> the webapp inside it, then the requirement may make sense. And then you
> have to look for the component, at the right level, which can provide that
> information. (But it is not the webapp, and it is not Tomcat).
>
> At the other extreme, if you are providing only the web application, then
> the requirement does not make sense /for you/, because it is impossible.
> It is not that it does not make sense in general, but "as part of the
> webapp" it does not make sense.
>
> And that is what Christopher is also telling you (in a lot less words).
>
>
>
> On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Durga,
>>>
>>> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
>>>
 We are using JSSE only not APR. Looking for handshake failures.

 Yes, using JSSE SSL debug, we are able to get all handshake
 (-Djavax.net.debug=ssl:handshake) logs including success cases.
 These are still quite bit expense logs and meant for debug
 purposes. As you said it might impact performance that's the
 reason, trying for any other optimal solution here.

>>>
>>> I know of no way to be notified about handshake failures on the server
>>> side. You may not be able to fulfill this requirement if using Java
>>> for your crypto.
>>>
>>> Honestly, I'm not sure why you care about failed TLS handshakes. Are
>>> you trying to implement a NIDS in your application? This is
>>> better-handled by a network component specifically-designed for this
>>> kind of thing.
>>>
>>> - -chris
>>> -BEGIN PGP SIGNATURE-
>>> Comment: GPGTools - http://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
>>> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
>>> pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
>>> onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
>>> yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
>>> VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
>>> rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
>>> mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
>>> e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
>>> 1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
>>> q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
>>> 2WbMcngOqAvk16kPb5u+
>>> =F7yo
>>> -END PGP SIGNATURE-
>>>
>>> 

Re: Logging TLS Session Failures

[tomcat]

On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:

This is one of the requirement from FIPS/CC certification.

Thanks,
Durga Srinivasu



Durga,

I believe that in your original post, you said :
"We have a requirement in our application to log all TLS session failures."

You should probably have another look a the precise requirements, and the exact definition 
of "our application".

Because it may be that the requirements are wrong, as far as you are concerned.

It depends on what is included in "our application".
In the java servlet container (like Tomcat) terminology, an "application" is a 
webapp.
A webapp runs inside a servlet container.
The servlet container (here Tomcat) runs inside a java JVM.
The java JVM runs inside an OS.
The OS runs inside a host.

In that hierarchy, a webapp only sees a request, when the servlet container has received 
this request on one of its ports, and "delegates" the request to the webapp.
By that time, the webapp does not even know through which interface the request came in, 
nor if that interface required HTTP, HTTPS or whatever other communications protocol.
And if a TLS connection from a browser failed, the webapp is not even called, so it does 
not know anything about it.

Of course the webapp cannot log a failure, if it is never called when that 
failure happens.

To move one level up : if a TLS connection from a browser fails, Tomcat probably never 
even sees that (because the connection never reaches Tomcat). So Tomcat cannot log this 
failure either. Tomcat is just telling some underlying layer of software (in the JVM, in 
the OS, or in some external library), what kind of connections to accept. But it does  not 
manage these connections, it just "gets" a connection when it succeeds.


So if you (your team, your company) is responsible for providing the whole service, 
including the host, the OS, the JVM, the servlet container, and the webapp inside it, then 
the requirement may make sense. And then you have to look for the component, at the right 
level, which can provide that information. (But it is not the webapp, and it is not Tomcat).


At the other extreme, if you are providing only the web application, then the requirement 
does not make sense /for you/, because it is impossible.
It is not that it does not make sense in general, but "as part of the webapp" it does not 
make sense.


And that is what Christopher is also telling you (in a lot less words).



On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:

We are using JSSE only not APR. Looking for handshake failures.

Yes, using JSSE SSL debug, we are able to get all handshake
(-Djavax.net.debug=ssl:handshake) logs including success cases.
These are still quite bit expense logs and meant for debug
purposes. As you said it might impact performance that's the
reason, trying for any other optimal solution here.


I know of no way to be notified about handshake failures on the server
side. You may not be able to fulfill this requirement if using Java
for your crypto.

Honestly, I'm not sure why you care about failed TLS handshakes. Are
you trying to implement a NIDS in your application? This is
better-handled by a network component specifically-designed for this
kind of thing.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
2WbMcngOqAvk16kPb5u+
=F7yo
-END PGP SIGNATURE-

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







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

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

This is one of the requirement from FIPS/CC certification.

Thanks,
Durga Srinivasu

On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Durga,
>
> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> > We are using JSSE only not APR. Looking for handshake failures.
> >
> > Yes, using JSSE SSL debug, we are able to get all handshake
> > (-Djavax.net.debug=ssl:handshake) logs including success cases.
> > These are still quite bit expense logs and meant for debug
> > purposes. As you said it might impact performance that's the
> > reason, trying for any other optimal solution here.
>
> I know of no way to be notified about handshake failures on the server
> side. You may not be able to fulfill this requirement if using Java
> for your crypto.
>
> Honestly, I'm not sure why you care about failed TLS handshakes. Are
> you trying to implement a NIDS in your application? This is
> better-handled by a network component specifically-designed for this
> kind of thing.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
> pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
> onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
> yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
> VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
> rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
> mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
> e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
> 1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
> q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
> 2WbMcngOqAvk16kPb5u+
> =F7yo
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Logging TLS Session Failures

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> We are using JSSE only not APR. Looking for handshake failures.
> 
> Yes, using JSSE SSL debug, we are able to get all handshake 
> (-Djavax.net.debug=ssl:handshake) logs including success cases.
> These are still quite bit expense logs and meant for debug
> purposes. As you said it might impact performance that's the
> reason, trying for any other optimal solution here.

I know of no way to be notified about handshake failures on the server
side. You may not be able to fulfill this requirement if using Java
for your crypto.

Honestly, I'm not sure why you care about failed TLS handshakes. Are
you trying to implement a NIDS in your application? This is
better-handled by a network component specifically-designed for this
kind of thing.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
2WbMcngOqAvk16kPb5u+
=F7yo
-END PGP SIGNATURE-

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

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Chris,

We are using JSSE only not APR. Looking for handshake failures.

Yes, using JSSE SSL debug, we are able to get all handshake
(-Djavax.net.debug=ssl:handshake) logs including success cases. These are
still quite bit expense logs and meant for debug purposes. As you said it
might impact performance that's the reason, trying for any other optimal
solution here.


Thanks,
Durga Srinivasu

On Wed, Mar 8, 2017 at 8:10 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Durga,
>
> On 3/8/17 9:29 AM, Durga Srinivasu Karuturi wrote:
> > We have a requirement in our application to log all TLS session
> > failures.
>
> Specifically, what kind of failures? Failed handshakes? Initial or
> re-negotiation? Are you using JSSE or APR? If JSSE, are you using the
> OpenSSL crypto-backend?
>
> > We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any
> > way to configure tomcat to log/trace any TLS Failure on tomcat
> > sessions?
>
> Not at the moment. If you are using JSSE with the Oracle crypto
> backend, you can put it into debug mode, but you don't want to do
> that; it will produce so much output it will measurably slow-down your
> server.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwBfWAAoJEBzwKT+lPKRYPDMP/06EccSRlV9KGNtQ2167Plsw
> PNefVfp4qcSHlsT8xBe2pWDU52ybLqOugBKGtTxa/ZGHDo1aMJCR+HZJqNspujdl
> Qe/7GVFKlzu6d8ucBJ/VgjM/sU+dLQnYW7sLJpfiM7gtOD3zcRYH1BN7iTW1Ij6e
> JYFrqvP6TJpdHtJgQ9n8AXB/+iUzqF6sigJPYFe6HNM4oAiuU6M8AzhNwtNM2AUN
> fnE2OyB+0FNcnwizLqhZ9+RJZeMIbb8wsyUJiOGkqyTBFcYrsPx5VR6A29+u+3R1
> FKES8jgzDAqlztdG2kZK8EmUrJokRT9aDoDKYbuSWW/+QujDDpl76pLdSaTR/eVB
> RuJSRwkyV3VA68Wg6FBGFNNCmV/1t2Yii3dLxa1aLph6TipIyEo16nyDr7yf5HPZ
> hKyfoeyIMVvreN0ldjwNlsKvlHHDheun5l02/h7hE934UYb+9KyfY1vhWuzfNcKu
> QgG8oExdi91GfjAR9vApTuVm5fAra07oqNzlXhFrx3dbYWrJamTL6uymlvxoHhhL
> KkVz6F68sMR0AqDV2+tgcKOxV7GWl+kQueMo7csBZ54kNaNN/Qcw2tRyG4iz0mNk
> ihRG5REvbqTGfN+TQzoeYLdysdU7n1R/tfxb4dHeqP6x8FMOTwz/yRdYywUsX+9e
> 83XGxnDX3Ps0mW9xA8Ab
> =H9l5
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Logging TLS Session Failures

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/8/17 9:29 AM, Durga Srinivasu Karuturi wrote:
> We have a requirement in our application to log all TLS session
> failures.

Specifically, what kind of failures? Failed handshakes? Initial or
re-negotiation? Are you using JSSE or APR? If JSSE, are you using the
OpenSSL crypto-backend?

> We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any
> way to configure tomcat to log/trace any TLS Failure on tomcat
> sessions?

Not at the moment. If you are using JSSE with the Oracle crypto
backend, you can put it into debug mode, but you don't want to do
that; it will produce so much output it will measurably slow-down your
server.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYwBfWAAoJEBzwKT+lPKRYPDMP/06EccSRlV9KGNtQ2167Plsw
PNefVfp4qcSHlsT8xBe2pWDU52ybLqOugBKGtTxa/ZGHDo1aMJCR+HZJqNspujdl
Qe/7GVFKlzu6d8ucBJ/VgjM/sU+dLQnYW7sLJpfiM7gtOD3zcRYH1BN7iTW1Ij6e
JYFrqvP6TJpdHtJgQ9n8AXB/+iUzqF6sigJPYFe6HNM4oAiuU6M8AzhNwtNM2AUN
fnE2OyB+0FNcnwizLqhZ9+RJZeMIbb8wsyUJiOGkqyTBFcYrsPx5VR6A29+u+3R1
FKES8jgzDAqlztdG2kZK8EmUrJokRT9aDoDKYbuSWW/+QujDDpl76pLdSaTR/eVB
RuJSRwkyV3VA68Wg6FBGFNNCmV/1t2Yii3dLxa1aLph6TipIyEo16nyDr7yf5HPZ
hKyfoeyIMVvreN0ldjwNlsKvlHHDheun5l02/h7hE934UYb+9KyfY1vhWuzfNcKu
QgG8oExdi91GfjAR9vApTuVm5fAra07oqNzlXhFrx3dbYWrJamTL6uymlvxoHhhL
KkVz6F68sMR0AqDV2+tgcKOxV7GWl+kQueMo7csBZ54kNaNN/Qcw2tRyG4iz0mNk
ihRG5REvbqTGfN+TQzoeYLdysdU7n1R/tfxb4dHeqP6x8FMOTwz/yRdYywUsX+9e
83XGxnDX3Ps0mW9xA8Ab
=H9l5
-END PGP SIGNATURE-

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

RE: logging to syslog

[Chandrashekar H . S]

Yes,
Its possible, using the below log4j configuration.


http://jakarta.apache.org/log4j/;>

 
 
 
  
  
 
  
   
 

 
  
  
 
  










--Chandra

-Original Message-
From: Schöke, Karsten [mailto:karsten.scho...@geobasis-bb.de] 
Sent: Tuesday, February 14, 2017 7:21 PM
To: users@tomcat.apache.org
Subject: logging to syslog

Hello,

it' possible that all messages in catalina.out also log to syslog?
I use tomcat7 under Debian Jessie.

Thx
Karsten


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

Re: logging to syslog

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Karsten,

On 2/14/17 8:51 AM, Schöke, Karsten wrote:
> Hello,
> 
> it' possible that all messages in catalina.out also log to syslog? 
> I use tomcat7 under Debian Jessie.

I think your best bet is to use log4j as your server logger and use
their SyslogAppender.

But Tomcat doesn't directly-support logging to syslog.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYox2tAAoJEBzwKT+lPKRY5boQAIDISEk5+V8gAqUU1cdbV/OY
UhwD/dSFd3Iofg6ynHBoMdh64NstbWWFytqqXLZ86bAcsITJ4DBo55oqpiS0n0ki
5aMaaCKKmGIfQFsGl+gk7YKdYWrq2wbv4MHkdcArQc14A/gxiy130S8y/FD8aqr/
CtXkLeMj+qXqwC8CBasqBMQ8laF/Thj1reWy/9x1/xQNzASchHA2KHaqWb1atUed
timQMga9t97W3FDxDv68tCcgftS1FEid1PvamjH8r2BPJbxxtTKvhnZl5rReSp6m
+ckzHfKpv4kt1tEK/ta0AaVeKKa3sc8UQDtXBifOMKYoiYTCjKHoEncFCvsVMXED
iGstDBYWDfa+caoW/cosq9ZkyRrP/Qkh1N50wmVz5W9OMTcSzr4qihTDsLz9aZkY
uGZpx8sc5konXPR+9apc3cRf5uOmwsG1AjqYUfuynYai1VWfdtBFW35AUZf0AhDO
Fex/fxQFWCdfZ1mhq4GmM5/y7F7JQc0pbjScXzXfPxrl6xTvml40TdwA5n74okfv
2GDiSVWoSIn9ps/e3lB4/r40JQ9oDzGuDOa/tjtgQ+d578pgf8qQjKkBfLqK/Oxd
z2T/OD8dN75zORi1uwKkYWr6K1R+ojuxzFuxh5VuLyBAvTTYFYlLzBECIF63vPuN
9vOhIybBnfzZGUzzVs66
=xd3v
-END PGP SIGNATURE-

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

Re: logging input and output HTTP message payload

[Frederik Nosi]

Hi Christopher,

On 06/18/2015 05:55 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frederik,

On 6/17/15 8:10 AM, Frederik Nosi wrote:

It helps only with HTTP though, no HTTPS or at least not easily.

All you need is the server's TLS key and Wireshark will look directly
at the HTTP conversation. This is a skill worth developing, especially
since it takes such little effort.


Been there done that, with mildly recent versions of openssl / https 
(PFS) you cant do that:


https://ask.wireshark.org/questions/34393/how-to-decrypt-ssl-traffic-using-wireshark





- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVguoGAAoJEBzwKT+lPKRYp/IP/jlJ8sLXsf0hxL/NE/dZmE/h
rq4kFb3/9itszwJnL7vnaQHetml+JZNAk7fsCvk8wGx4JIX/aYVpmmyJ+A1KsQ+Q
1nZeJ2uSef6iTEtYsypMxUasabguc8LI7KG0QMRyBYSLICcbp/36SLgJmUVLCuvw
ErClKJIlFDetd7r0dUuBIvlixThQ0emSOPRAgutNauiUCb2m6CCFAnFWmmW7Z01/
yLV+AUGHp3b77Yq3jJlKGtlmNmTuJ/tdnY0N7VwYlnA644DkUpetykFZZ/pdLa5p
wYRHXz5qv/tmVT383SAeK3FgSVYIp9EnxVHs44ImZ42XwCnkoHLK9TdzjkS6Cxrs
WHQJcP6vfSWQ7WIGLNpJzUclEkCaJRCLktGcA8SE4aNIg0JvVe2Y25RVWOdYX//E
RHiZxrDJxctoK6zmTuCOpd7DFx1cxSp2s1xXfghl80lFouMryoqwL7vui8/V/8u/
PsxT6/kupsTFTGoTv1RvJdk0rPVhrQnpHneOpQcKyoH/1lJoTswO8j7T6suLACqL
/K1HCVO8E+tu49Mn5bsr9rUb0uUo/qtYUu/cPp4Pv6CkNxLxYw48T1t82HSGkQHr
g7qCt1aWltsfc6O6yx07Zfdair8Hvy/QmOifcnpWlHn01wF6phSjrXhN3t5M7pnt
ScsjQVvlQoi7ATLm+4/a
=f8p5
-END PGP SIGNATURE-

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




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

Re: logging input and output HTTP message payload

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Milinda,

On 6/17/15 5:10 AM, Milinda Perera wrote:
 I need to log HTTP payload content for debugging purposes.
 Following are my findings:
 
 1. Using HTTP message content Access Log Valve [1] and Extended
 Access Log Valve [2] But it does not provide functionality to log
 HTTP payload
 
 2. Then I tried by changing  *org.apache.coyote.level=FINE* With
 this it logs the entire HTTP request (header + payload). But does
 not log response
 
 Since in my 2nd method it logged the request, Is it possible to
 log response also?

http://markmail.org/thread/fumpfuspt7a3nesz

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVguqpAAoJEBzwKT+lPKRYBjgP/jHRe/l712AgiJ8xiEmeuwHn
GaDVYK/RaZ0xEnsgFjCyFPDJnji3fa7T11BuklL1sEnQV+7QovdSEfYstu6yij+M
WIQah/h+fOI4xytp8/vO6AvAah0lBUKJMuGPzJYfUUugGE7w293uzyL15BIUpGM1
WFvbsUMGQO07i2mTnoK60CY7dfiDau9CBALqTZDWBxNofYGj4kSXgT5qhQsc8eUI
x0CMVNUUeYNUL62e+OXYzYbAzMUAG1zkXVbZsP/IajXLHFLpxHcxwu++oTg+Pode
SwemM50ABQYqx4k0iTnR9UJHZeq4WcLhXzd7q9e4chL4OTo3KytFxb1s9FV6p96X
WT6JWG2riBN86vVDnL8w4FeK6ORV/vAtfwHNxHUv+HQNd5AcE/Ls0H019yhK3UC1
OEneSe2tQyPOucTOuQLCn3z5b2AjflRcdJqtJxUH71mc5fzKawDMKHLY93ilIf2N
3QXW/PiI8cK97z+4oTqVKozwcaKckWFV67VQEcyXReIdf1SAUOjiOW0hhCPrqNLi
zu6+2EOzODgTgGsLM0ca4vAwFb035Um91dpxXC+l0LaVtdjnCGbKlaqpHiwBnehz
3KibFSzYr2D0qcY5eAPFDUEMmZGv1Rg7fi7vuruoXQll7Iu1hsLONfeaH0l434mO
anlb6DLXYOWBPdhJpqqD
=stly
-END PGP SIGNATURE-

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

Re: logging input and output HTTP message payload

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frederik,

On 6/17/15 8:10 AM, Frederik Nosi wrote:
 It helps only with HTTP though, no HTTPS or at least not easily.

All you need is the server's TLS key and Wireshark will look directly
at the HTTP conversation. This is a skill worth developing, especially
since it takes such little effort.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVguoGAAoJEBzwKT+lPKRYp/IP/jlJ8sLXsf0hxL/NE/dZmE/h
rq4kFb3/9itszwJnL7vnaQHetml+JZNAk7fsCvk8wGx4JIX/aYVpmmyJ+A1KsQ+Q
1nZeJ2uSef6iTEtYsypMxUasabguc8LI7KG0QMRyBYSLICcbp/36SLgJmUVLCuvw
ErClKJIlFDetd7r0dUuBIvlixThQ0emSOPRAgutNauiUCb2m6CCFAnFWmmW7Z01/
yLV+AUGHp3b77Yq3jJlKGtlmNmTuJ/tdnY0N7VwYlnA644DkUpetykFZZ/pdLa5p
wYRHXz5qv/tmVT383SAeK3FgSVYIp9EnxVHs44ImZ42XwCnkoHLK9TdzjkS6Cxrs
WHQJcP6vfSWQ7WIGLNpJzUclEkCaJRCLktGcA8SE4aNIg0JvVe2Y25RVWOdYX//E
RHiZxrDJxctoK6zmTuCOpd7DFx1cxSp2s1xXfghl80lFouMryoqwL7vui8/V/8u/
PsxT6/kupsTFTGoTv1RvJdk0rPVhrQnpHneOpQcKyoH/1lJoTswO8j7T6suLACqL
/K1HCVO8E+tu49Mn5bsr9rUb0uUo/qtYUu/cPp4Pv6CkNxLxYw48T1t82HSGkQHr
g7qCt1aWltsfc6O6yx07Zfdair8Hvy/QmOifcnpWlHn01wF6phSjrXhN3t5M7pnt
ScsjQVvlQoi7ATLm+4/a
=f8p5
-END PGP SIGNATURE-

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

Re: logging input and output HTTP message payload

[Frederik Nosi]

Some more info,

On 06/18/2015 06:00 PM, Frederik Nosi wrote:

Hi Christopher,

On 06/18/2015 05:55 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frederik,

On 6/17/15 8:10 AM, Frederik Nosi wrote:

It helps only with HTTP though, no HTTPS or at least not easily.

All you need is the server's TLS key and Wireshark will look directly
at the HTTP conversation. This is a skill worth developing, especially
since it takes such little effort.


Been there done that, with mildly recent versions of openssl / https 
(PFS) you cant do that:


https://ask.wireshark.org/questions/34393/how-to-decrypt-ssl-traffic-using-wireshark 



Till some years ago I used tihs technique for troubleshooting. But after 
a webserver upgrade or such, i found that this was no more possible (i'm 
noit going into details now). So the quick and dirty way i had to use 
was with apache mod_bumpio, or strace -fe trace=network -s 1024 -p 
`pidof tomcat`, you got the idea.

With another product i had to put a HTTP/HTTPS proxy in the middle.

That's why i said it's not so quick :-)








- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVguoGAAoJEBzwKT+lPKRYp/IP/jlJ8sLXsf0hxL/NE/dZmE/h
rq4kFb3/9itszwJnL7vnaQHetml+JZNAk7fsCvk8wGx4JIX/aYVpmmyJ+A1KsQ+Q
1nZeJ2uSef6iTEtYsypMxUasabguc8LI7KG0QMRyBYSLICcbp/36SLgJmUVLCuvw
ErClKJIlFDetd7r0dUuBIvlixThQ0emSOPRAgutNauiUCb2m6CCFAnFWmmW7Z01/
yLV+AUGHp3b77Yq3jJlKGtlmNmTuJ/tdnY0N7VwYlnA644DkUpetykFZZ/pdLa5p
wYRHXz5qv/tmVT383SAeK3FgSVYIp9EnxVHs44ImZ42XwCnkoHLK9TdzjkS6Cxrs
WHQJcP6vfSWQ7WIGLNpJzUclEkCaJRCLktGcA8SE4aNIg0JvVe2Y25RVWOdYX//E
RHiZxrDJxctoK6zmTuCOpd7DFx1cxSp2s1xXfghl80lFouMryoqwL7vui8/V/8u/
PsxT6/kupsTFTGoTv1RvJdk0rPVhrQnpHneOpQcKyoH/1lJoTswO8j7T6suLACqL
/K1HCVO8E+tu49Mn5bsr9rUb0uUo/qtYUu/cPp4Pv6CkNxLxYw48T1t82HSGkQHr
g7qCt1aWltsfc6O6yx07Zfdair8Hvy/QmOifcnpWlHn01wF6phSjrXhN3t5M7pnt
ScsjQVvlQoi7ATLm+4/a
=f8p5
-END PGP SIGNATURE-

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




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




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

Re: logging input and output HTTP message payload

[Milinda Perera]

Hi all,

Thanks for suggestions,

Actually I want to log all HTTP / HTTPS requests from client applications
to my Tomcat server and the Response sent back to the client. And logging
requests and payloads are not target specific application running in the
Tomcal server, which means all the request to the Tomcat server and all the
responses from the Tomcat server

My requirement cannot be fulfilled with external tools like wireshark
because:
  1. unable to log HTTPS requests and responses
  2. And I need to get logged requests and responses in server side log
files without external tools.

by changing  *org.apache.coyote.level=FINE *in log properties logs HTTP
requests to the server, but does not log response.

Highly appreciate if you guys can share your thoughts to achieve this.

Thanks,
Milinda



On Wed, Jun 17, 2015 at 5:56 PM, André Warnier a...@ice-sa.com wrote:

 Frederik Nosi wrote:

 It helps only with HTTP though, no HTTPS or at least not easily.

 While we are at this, are you trying to debug a SOAP / REST connection
 from your application running on Tomcat to another server or a connection
 coming from outside to your Tomcat?


 On 06/17/2015 11:16 AM, Mark Thomas wrote:

 On 17/06/2015 10:10, Milinda Perera wrote:

 Hi,

 I need to log HTTP payload content for debugging purposes.

 Use Wireshark. That has the added benefit of not having any unwanted
 side-effects on your application.

 Mark


 If this is for one debugging session, you could also simply use an add-on
 to a browser (such as Fiddler2 for IE), and record the full exchanges there.
 It has the advantage that you see the complete traffic in both directions
 (headers and content), and that you can easily switch between different
 presentations of the data, and save it to file if you need to.  And
 depending on what you are looking for, it may be a lot easier to handle
 than Wireshark.





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




-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
   / \  / \ |  ||
  /   \/   \|  ||  N D A
 /  \   |  | |
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
* please consider our environment before printing this e-mail*

Re: logging input and output HTTP message payload

[Frederik Nosi]

If you have this:

1) Tomcat listening in HTTP, not HTTPS
2) ssh access to the machine
3) administrator access to the machine

and are on Linux (or Unix in general, but my command is linux specific) 
do this as root:



tcpdump -nnpi any -s0 -vvv -w /tmp/dump.pcap port  8080

After the request you're interested in are done press CTRl+C

from your client, assuming it's linux but on win you can use putty or 
whatever:


scp remote-machine:/tmp/dump.pcap .
wireshark dump.pcap


Done.

P.S.
If your tomcat's HTTP Connector isn't listening at port 8080 change the 
port accordingly in my tcpdump command




On 06/17/2015 08:04 PM, Milinda Perera wrote:

Hi all,

Thanks for suggestions,

Actually I want to log all HTTP / HTTPS requests from client applications
to my Tomcat server and the Response sent back to the client. And logging
requests and payloads are not target specific application running in the
Tomcal server, which means all the request to the Tomcat server and all the
responses from the Tomcat server

My requirement cannot be fulfilled with external tools like wireshark
because:
   1. unable to log HTTPS requests and responses
   2. And I need to get logged requests and responses in server side log
files without external tools.

by changing  *org.apache.coyote.level=FINE *in log properties logs HTTP
requests to the server, but does not log response.

Highly appreciate if you guys can share your thoughts to achieve this.

Thanks,
Milinda



On Wed, Jun 17, 2015 at 5:56 PM, André Warnier a...@ice-sa.com wrote:


Frederik Nosi wrote:


It helps only with HTTP though, no HTTPS or at least not easily.

While we are at this, are you trying to debug a SOAP / REST connection
from your application running on Tomcat to another server or a connection
coming from outside to your Tomcat?


On 06/17/2015 11:16 AM, Mark Thomas wrote:


On 17/06/2015 10:10, Milinda Perera wrote:


Hi,

I need to log HTTP payload content for debugging purposes.


Use Wireshark. That has the added benefit of not having any unwanted
side-effects on your application.

Mark



If this is for one debugging session, you could also simply use an add-on
to a browser (such as Fiddler2 for IE), and record the full exchanges there.
It has the advantage that you see the complete traffic in both directions
(headers and content), and that you can easily switch between different
presentations of the data, and save it to file if you need to.  And
depending on what you are looking for, it may be a lot easier to handle
than Wireshark.





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







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

Re: logging input and output HTTP message payload

[André Warnier]

Just to make sure..

Milinda Perera wrote:

Hi all,

Thanks for suggestions,

Actually I want to log all HTTP / HTTPS requests from client applications
to my Tomcat server and the Response sent back to the client. And logging
requests and payloads are not target specific application running in the
Tomcal server, which means all the request to the Tomcat server and all the
responses from the Tomcat server

My requirement cannot be fulfilled with external tools like wireshark
because:
  1. unable to log HTTPS requests and responses
  2. And I need to get logged requests and responses in server side log
files without external tools.


Are you aware of the volume of data that this could be ? and about the performance impact 
? and about the complexity of doing this in any way that would be useful ?


HTTP requests tend to be small  : a request line like GET /mylogo.jpg HTTP/1.1, and a 
few text headers). But the response to that request may be very large (a 120 KB jpeg 
file).  Multiply by the number of requests for your homepage etc. (and never mind if you 
are returning large PDF documents sometimes...)


And then, to log this jpeg logo file in any useful manner, you would have to
a) analyse the response, to see what is sent back
b) encode this in some way, to write it usefully to your logfile (you do not want binary 
data there, I presume)


These are probably some of the reasons why the standard logging methods don't 
do that.



by changing  *org.apache.coyote.level=FINE *in log properties logs HTTP
requests to the server, but does not log response.

Highly appreciate if you guys can share your thoughts to achieve this.



Ask the NSA for some tips ?


Thanks,
Milinda



On Wed, Jun 17, 2015 at 5:56 PM, André Warnier a...@ice-sa.com wrote:


Frederik Nosi wrote:


It helps only with HTTP though, no HTTPS or at least not easily.

While we are at this, are you trying to debug a SOAP / REST connection
from your application running on Tomcat to another server or a connection
coming from outside to your Tomcat?


On 06/17/2015 11:16 AM, Mark Thomas wrote:


On 17/06/2015 10:10, Milinda Perera wrote:


Hi,

I need to log HTTP payload content for debugging purposes.


Use Wireshark. That has the added benefit of not having any unwanted
side-effects on your application.

Mark



If this is for one debugging session, you could also simply use an add-on
to a browser (such as Fiddler2 for IE), and record the full exchanges there.
It has the advantage that you see the complete traffic in both directions
(headers and content), and that you can easily switch between different
presentations of the data, and save it to file if you need to.  And
depending on what you are looking for, it may be a lot easier to handle
than Wireshark.





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








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

Re: logging input and output HTTP message payload

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/17/2015 11:32 AM, André Warnier wrote:
 Just to make sure..
 
 Milinda Perera wrote:
 Hi all,
 
 Thanks for suggestions,
 
 Actually I want to log all HTTP / HTTPS requests from client
 applications to my Tomcat server and the Response sent back to
 the client. And logging requests and payloads are not target
 specific application running in the Tomcal server, which means
 all the request to the Tomcat server and all the responses from
 the Tomcat server
 
 My requirement cannot be fulfilled with external tools like
 wireshark because: 1. unable to log HTTPS requests and responses 
 2. And I need to get logged requests and responses in server side
 log files without external tools.
 
 Are you aware of the volume of data that this could be ? and about
 the performance impact ? and about the complexity of doing this in
 any way that would be useful ?
 
 HTTP requests tend to be small  : a request line like GET
 /mylogo.jpg HTTP/1.1, and a few text headers). But the response to
 that request may be very large (a 120 KB jpeg file).  Multiply by
 the number of requests for your homepage etc. (and never mind if
 you are returning large PDF documents sometimes...)
 
 And then, to log this jpeg logo file in any useful manner, you
 would have to a) analyse the response, to see what is sent back b)
 encode this in some way, to write it usefully to your logfile (you
 do not want binary data there, I presume)
 
 These are probably some of the reasons why the standard logging
 methods don't do that.
 
 
 by changing  *org.apache.coyote.level=FINE *in log properties
 logs HTTP requests to the server, but does not log response.
 
 Highly appreciate if you guys can share your thoughts to achieve
 this.
 
 
 Ask the NSA for some tips ?
 
 Thanks, Milinda
 
 
 
 On Wed, Jun 17, 2015 at 5:56 PM, André Warnier a...@ice-sa.com
 wrote:
 
 Frederik Nosi wrote:
 
 It helps only with HTTP though, no HTTPS or at least not
 easily.
 
 While we are at this, are you trying to debug a SOAP / REST
 connection from your application running on Tomcat to another
 server or a connection coming from outside to your Tomcat?
 
 
 On 06/17/2015 11:16 AM, Mark Thomas wrote:
 
 On 17/06/2015 10:10, Milinda Perera wrote:
 
 Hi,
 
 I need to log HTTP payload content for debugging
 purposes.
 
 Use Wireshark. That has the added benefit of not having any
 unwanted side-effects on your application.
 
 Mark
 
 
 If this is for one debugging session, you could also simply use
 an add-on to a browser (such as Fiddler2 for IE), and record
 the full exchanges there. It has the advantage that you see the
 complete traffic in both directions (headers and content), and
 that you can easily switch between different presentations of
 the data, and save it to file if you need to.  And depending on
 what you are looking for, it may be a lot easier to handle than
 Wireshark.

As others have pointed out, this will potentially generate a huge
amount of information, most of it completely useless (logging your JPG
logo over and over again?), and impact performance . . .

That being said, I suppose one way to do this is to write a servlet
filter, wrap the ServletResponse object, then do the logging in the
filter.

You could be careful in what you log (don't put the filter in front of
images or pdf files, for example), and also have a servlet filter init
parameter which could control the logging (or turn it off).

Consider the volume of information you will generate. For example, I'm
using the standard access logging that is configured with Tomcat
7.0.62. A web site gets about 250K requests per day, and I strip out a
bunch of stuff using Perl. After all is said and done, a day's worth
of logs is about 60 MB.

Now, add response information and do the math. You'll find that it's
not going to be a very pleasant. In order to handle that amount of
data, you'll need to invest in streaming logging, a NoSQL database,
and the infrastructure to support those tools.

If that's what you wish to do, then great. Just be aware of what
you're walking into.

You might want to go back and actually determine the underlying
business requirements before embarking on such a task.

. . . just my two cents
/mde/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVgcQ/AAoJEEFGbsYNeTwtAPkIAIDO334dMWLbejAVQ4us0jv7
a/cE69LwTpHJ7zxfGE4jbYsD3BvAJWQduBjuP83ePb37BiaYA9ImtJsXwkjfpPpk
TTv3Xrse4gRXueR2x+cOQbx/1BMMmPyeUenBXwFoPA2V3xhAH0N5DUdyC9mb5Hju
fk/2kquPHHuNNM3L9W3UE9BS7yhWed8wP93RG78oaopGm+anojwp6NQ2QZLxtdCc
fSZ9QrFhuKfizvU2emyRznIdUx88fVnwvFt5wBzTlJf3EgRTGt1B2VGTUuVMPmTy
SXJIzkZePAkGUswt35uh51n9IuKJXzPr5NEzNzAMMsbHVb828KbLY01YFiomGfU=
=6WmU
-END PGP SIGNATURE-

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
https://www.avast.com/antivirus


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For 

Re: logging input and output HTTP message payload

[Frederik Nosi]

It helps only with HTTP though, no HTTPS or at least not easily.

While we are at this, are you trying to debug a SOAP / REST connection 
from your application running on Tomcat to another server or a 
connection coming from outside to your Tomcat?



On 06/17/2015 11:16 AM, Mark Thomas wrote:

On 17/06/2015 10:10, Milinda Perera wrote:

Hi,

I need to log HTTP payload content for debugging purposes.

Use Wireshark. That has the added benefit of not having any unwanted
side-effects on your application.

Mark


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




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

Re: logging input and output HTTP message payload

[André Warnier]

Frederik Nosi wrote:

It helps only with HTTP though, no HTTPS or at least not easily.

While we are at this, are you trying to debug a SOAP / REST connection 
from your application running on Tomcat to another server or a 
connection coming from outside to your Tomcat?



On 06/17/2015 11:16 AM, Mark Thomas wrote:

On 17/06/2015 10:10, Milinda Perera wrote:

Hi,

I need to log HTTP payload content for debugging purposes.

Use Wireshark. That has the added benefit of not having any unwanted
side-effects on your application.

Mark



If this is for one debugging session, you could also simply use an add-on to a browser 
(such as Fiddler2 for IE), and record the full exchanges there.
It has the advantage that you see the complete traffic in both directions (headers and 
content), and that you can easily switch between different presentations of the data, and 
save it to file if you need to.  And depending on what you are looking for, it may be a 
lot easier to handle than Wireshark.





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

Re: logging input and output HTTP message payload

[Mark Thomas]

On 17/06/2015 10:10, Milinda Perera wrote:
 Hi,
 
 I need to log HTTP payload content for debugging purposes.

Use Wireshark. That has the added benefit of not having any unwanted
side-effects on your application.

Mark


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

RE: Logging Issue in Tomcat v7.0.0.32

[Bomma, Nithun]

We are using Windows version of tomcat on Windows 2008.

-Original Message-
From: Bomma, Nithun 
Sent: Tuesday, September 09, 2014 10:06 AM
To: users@tomcat.apache.org
Subject: Logging Issue in Tomcat v7.0.0.32

Hello,

I have tried to login into Manger app using default user name (tomcat/s3cret) 
which were defined in tomcat-users.xml under /conf.

But it fails to login. Any idea why? Please let me know.

Thanks.

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

RE: Logging Issue in Tomcat v7.0.0.32

[Lulseged Zerfu]

Hi
 Can you send your tomcat-users.xml.
It has been changed and will not work if you are using the old format.
BRLulseged

 From: nithun.bo...@amtrak.com
 To: users@tomcat.apache.org
 Subject: Logging Issue in Tomcat v7.0.0.32
 Date: Tue, 9 Sep 2014 14:05:39 +
 
 Hello,
 
 I have tried to login into Manger app using default user name (tomcat/s3cret) 
 which were defined in tomcat-users.xml under /conf.
 
 But it fails to login. Any idea why? Please let me know.
 
 Thanks.
  

RE: Logging Issue in Tomcat v7.0.0.32

[Bomma, Nithun]

?xml version='1.0' encoding='utf-8'?
!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the License); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an AS IS BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
--
#tomcat-users
#user name=admin password=Admin123 roles=admin-gui,manager-gui /

tomcat-users
#role rolename=admin-gui/
role rolename=manager-gui/
user username=tomcat password=s3cret roles=manager-gui/

!--
  NOTE:  The sample user and role entries below are wrapped in a comment
  and thus are ignored when reading this file. Do not forget to remove
  !.. .. that surrounds them.
--
!--
  role rolename=tomcat/
  role rolename=role1/
  user username=tomcat password=tomcat roles=tomcat/
  user username=both password=tomcat roles=tomcat,role1/
  user username=role1 password=tomcat roles=role1/
--
/tomcat-users



Thanks,
Nithun Bomma
WebSphere Administrator
Amtrak - Information Technology (Operations)
Desk: 215-349-2065; ATS: 728-2065


-Original Message-
From: Lulseged Zerfu [mailto:zlulse...@hotmail.com] 
Sent: Tuesday, September 09, 2014 10:08 AM
To: Tomcat Users List
Subject: RE: Logging Issue in Tomcat v7.0.0.32

Hi
 Can you send your tomcat-users.xml.
It has been changed and will not work if you are using the old format.
BRLulseged

 From: nithun.bo...@amtrak.com
 To: users@tomcat.apache.org
 Subject: Logging Issue in Tomcat v7.0.0.32
 Date: Tue, 9 Sep 2014 14:05:39 +
 
 Hello,
 
 I have tried to login into Manger app using default user name (tomcat/s3cret) 
 which were defined in tomcat-users.xml under /conf.
 
 But it fails to login. Any idea why? Please let me know.
 
 Thanks.
  

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

Re: Logging Issue in Tomcat v7.0.0.32

[André Warnier]

Hi.

Sorry for top-posting, in this case it's easier to read.

Bomma, Nithun wrote:

The tomcat-users.xml is an XML file (as its name hints at).
This is a valid XML comment :

 !--
   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed with
   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version 2.0
   (the License); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an AS IS BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
 --

This is not a valid XML comment :

 #tomcat-users
 #user name=admin password=Admin123 roles=admin-gui,manager-gui /


Maybe it has something to do with the problem ?

Doesn't any of the Tomcat logfiles mention anything about this, when you start 
Tomcat ?


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

RE: Logging Issue in Tomcat v7.0.0.32

[Bomma, Nithun]

Thanks Andre!

It got fixed. I have deleted them and restarted.

Thanks again.


-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Tuesday, September 09, 2014 11:17 AM
To: Tomcat Users List
Subject: Re: Logging Issue in Tomcat v7.0.0.32

Hi.

Sorry for top-posting, in this case it's easier to read.

Bomma, Nithun wrote:

The tomcat-users.xml is an XML file (as its name hints at).
This is a valid XML comment :

  !--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
  --

This is not a valid XML comment :

  #tomcat-users
  #user name=admin password=Admin123 roles=admin-gui,manager-gui /


Maybe it has something to do with the problem ?

Doesn't any of the Tomcat logfiles mention anything about this, when you start 
Tomcat ?


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


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

Re: Logging makes a grown man cry

[Tomcat Random]

Sorry if resurrecting the dead is frowned upon here but I thought I would
just add my resolve to this. Honestly, after writing a lot of code
otherwise, logging was probably the most frustrating.

Tomcat 7.0.42, RHEL 6

1. SL4FJ with Logback works beautifully.

2. I have custom error pages in web.xml that redirect various exceptions to
servlets. The servlets capture the exceptions and write them out to
different logs using SLF/Logback.

3. The default logging.properties is completely commented out. Note:
deleting it is different than it being empty.

4. Since spymemcached logging is baked in, I added SLF as its logger in my
ContextInitialized listener:

 // set SLF4J as the logger for spymemcached
 Properties systemProperties = System.getProperties();
systemProperties.put(net.spy.log.LoggerImpl,
net.spy.memcached.compat.log.SLF4JLogger);
System.setProperties(systemProperties);

ch.qos.logback.classic.Logger logger =
 (ch.qos.logback.classic.Logger)
LoggerFactory.getLogger(net.spy.memcached);

logger.setLevel(Level.ERROR);


Cheers,
Alec

Re: Logging makes a grown man cry

[Tomcat Random]

That seems like a good solution. Are you able to avoid having a single
giant catalina.out file in $CATALINA_HOME/logs?


On Tue, Dec 3, 2013 at 11:01 PM, Dale Ogilvie dale_ogil...@trimble.comwrote:

 Currently we use tomcat configured as out-of-the-box for logging (no
 log4j) and log4j.jar and config in the app war file.

 We found issues with trying to have log4j in catalina/lib.

 That said, it would be nice to use log4j for tomcat, however we found
 that the two configurations collided in our slf4j setup.

 Dale

 -Original Message-
 From: Tomcat Random [mailto:tomcat.ran...@gmail.com]
 Sent: Wednesday, 4 December 2013 7:12 a.m.
 To: Tomcat Users List
 Subject: Logging makes a grown man cry

 So, all I want is to have:

 1. one log file that rolls daily (a new file each day), with the date
 appended, that catches my own logging code in the app, based on a global
 logging level value that I can change (DEBUG, or INFO, or ERROR etc) as
 needed.

 2. Another log file that rolls daily and consolidates any other output
 of the server and app (or two separate files) and also has a logging
 level value that can be changed globally.

 3. Get rid of the empty localhost. file.

 MTIA,
 Alec

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

Re: Logging makes a grown man cry

[Tomcat Random]

I'd argue that dealing with logging configuration is not newbie stuff. This
is probably some of the most poorly implemented technology in the servlet
container.


On Tue, Dec 3, 2013 at 3:44 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2013/12/3 Tomcat Random tomcat.ran...@gmail.com:
  Environment is RHEL6, Tomcat 7.0.42. There is only one webapp.
 
  I'm trying to implement log4j as per the instructions here (skipping step
  5):
  http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j
 
  Since I'm not using the Manager, I've removed the relevant logging lines
  from CATALINA_HOME/lib/log4j.properties, so it looks like this:
 
  _
  log4j.rootLogger=INFO, CATALINA
  (...)

  1., 2.

 Either filter by category names, or bundle its own
 classloader-specific Log4J configuration with your own web application
 (a WEB-INF/classes/log4j.properties file).


 Seriously, the Log4J documentation and mailing lists are elsewhere,
 http://logging.apache.org/log4j/1.2/mail-lists.html

 I'd be best to ask newbie questions there, even though this mailing
 list has a log of knowledgeable people that may occasionally help you.

 
  3. Get rid of the empty localhost. file.
 

 The configuration snippet that you provided does not have a cluster
 appender. Thus it does not matches your list of log files.

 Best regards,
 Konstantin Kolinko

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

Re: Logging makes a grown man cry

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alec,

On 12/3/13, 1:12 PM, Tomcat Random wrote:
 I'm trying to implement log4j as per the instructions here
 (skipping step 5): 
 http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j
 
 Since I'm not using the Manager, I've removed the relevant logging
 lines from CATALINA_HOME/lib/log4j.properties, so it looks like
 this:
 
 _ log4j.rootLogger=INFO, CATALINA
 
 # Define all the appenders 
 log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender 
 log4j.appender.CATALINA.File=${catalina.base}/logs/catalina.

This appender creates the catalina. file, so you are doing this to
yourself.

 log4j.appender.CATALINA.DatePattern='.'-MM-dd'.log'

This will move catalina. to catalina..-MM-dd.log every time
the date rolls over (actually, when the first log from the following
day is written). So, you are creating catalina..-MM-dd.log yourself.

catalina.out is impossible to avoid, because stdout *must* go
somewhere. If you want, you can set CATALINA_OUT to /dev/null but then
you might miss crucial log messages.

 log4j.appender.LOCALHOST=org.apache.log4j.DailyRollingFileAppender 
 log4j.appender.LOCALHOST.File=${catalina.base}/logs/localhost.

You are creating this file. If you don't send any log messages to it,
that's your fault. If you don't want it, don't configure it.

 _
 
 On restart, my (deleted-beforehand) logs directory looks like
 this:
 
 /logs/catalina. /logs/catalina.2013-12-03.log /logs/catalina.out 
 /logs/cluster.2013-12-03.log /logs/localhost. 
 /logs/localhost_access_log.2013-12-03.txt 
 _

I would have expected your filenames to contain two sequential dots
before the dates because your .File property ends with a dot and
your .DatePattern begins with a dot.

 catalina.out has spymemcached logging info (I haven't changed
 the spymemcached  system property yet to log4j so that might be
 why).

It's also possible that spymemcached is writing directly to System.out
(or System.err). You might want to check on that. Or it may be logging
to ServletContext.log().

 cluster.2013-12-03.log is behaving normally. localhost. is
 empty. And the daily access log is good.

Odd... as you have not configured such a log about. That must be
happening elsewhere.

 So, all I want is to have:
 
 1. one log file that rolls daily (a new file each day), with the
 date appended, that catches my own logging code in the app, based
 on a global logging level value that I can change (DEBUG, or INFO,
 or ERROR etc) as needed.

You cannot avoid catalina.out unless you do something dumb like
sending stdout to /dev/null.

 2. Another log file that rolls daily and consolidates any other
 output of the server and app (or two separate files) and also has a
 logging level value that can be changed globally.

No problem. What you have above should work for that.

 3. Get rid of the empty localhost. file.

Just remove the configuration for the LOCALHOST appender and that will
solve this problem.

As Konstantin suggested, you should read the documentation for log4j.
What is in the Tomcat documentation is just a suggestion to get you
started.

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

iQIcBAEBCAAGBQJSn2inAAoJEBzwKT+lPKRYRq0P/RcofIzrFYmLCL+lm8H93p8J
9Efs0JgeSA0YctejCN/p3bBNFC6NkcG1ZVQ9txoksFbzEIbJU/WrfUS7FUZgPaw+
e2f+5BW90aIxKK7PkCA1opJVKj3jhIxTix9egQJrfoIGlZ+iuqkeHpevtYN8z5Dt
pcuwlq3/+r38Vh+NnaxcCBlniigja/q4u4KW9eH00XHXSRCL6Rf7labldxVf3Klf
V+hlAUimmejQ2IYYYMYuE8thcjiEPwzDPe+IMmWcy4l07jOPzFWdKMYR1HD9THo/
agW9iimx+4sC4UJn03GZ8ndEmPj6ShFS0wHcvyQWinAKqMZ9UyKqRM4YPgpJkHFu
Uhct6JAGhteZ02uSPynw6PZu6cfIcB50QR+Bf0c9/v+lJZJ/WQFhZspcCTawwMDr
hzgu9Mp4ZHYVjneOQ0pFHmV8ZcoNlXlxdjntH0JoPEj4giPzJQnW80LLQ73TftPJ
GP3swzGFZF2sLBV5fG3Faeww4wL4zhz64fKf/6r6C3nGj8/SORA+msSF4/ySr51i
jWOcuiCsjul/PDAC+cTsBOyKXJQsJZ/99p+5qeUb1wkldbI35mWUZwh1lVGQs8Pc
/kkWRESajL35kZJ7h9LXLtFt3rYtKQKzgJ9Tfvgd5zjhvLPLWxfNSTNZPl6Ys93L
xaFsE9WOURRSa/FcmeCp
=JQo2
-END PGP SIGNATURE-

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

Re: Logging makes a grown man cry

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alec,

On 12/4/13, 11:31 AM, Tomcat Random wrote:
 I'd argue that dealing with logging configuration is not newbie
 stuff. This is probably some of the most poorly implemented
 technology in the servlet container.

What about the implementation is poor?

The examples don't meet your needs exactly? Well, I'm sure we're all
terribly sorry about that.

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

iQIcBAEBCAAGBQJSn2jYAAoJEBzwKT+lPKRYsaIQAJfcFaOJU1r4+fFUywSBkVWC
i8zi+HHJjk+eUpWBXZ2EsNnkNMvFkOGUiUZCbtjCCXfUOPhLSxpizj9XSJT6HKlR
Asto5xPhyouCjnfU+/L5fRdqi2yJeRf7D1nTnLoeVbmBX5BzkG5M6Ni+PG1/r50P
M+ZsfHHajmnLmD6IIysgjzc68RsJDb/cPShpgBi7X0cMY9831tE+cx/Dj6KcyBBo
Wm070JNBEn6+y9L4bHr1WOM9m3Cr9QPdDBIG8X/1M7unAEe5lU+8kfBpKlIuMOZH
FhnrhkziuSOTKssm97Bo1wIEw71ddaEBejEj3sc6fimwMl7osT3RYU5xuR0Evq6/
pICSgwSX9Cnv84JAeHb96KJCJ8ahGOrZaCAm0lQ4hhwQjD0097kXwx31BQBIRzAt
bgfPFGNGoeXuzNCwfvKUW1N77g+Y6pjW1rFUu8Z725j8XNttFCsxtDSPErRfG5ti
k9XKbS5zUVC4W/E7eQduUMQZ4XLV03+bpXl/Idou7anZjP0cqgbzil48ifTP3Ckt
me3d5ahUlYdJZ6ZW8JrW9+uomfN9egFItDaZm3Ro284nJjl8MVXulwKaPJs7KT1C
p4ox1UrnEo/03vs0qeWBxFwSsjfY3YW6+RCF2j16wCrHX+Im4MzptOztUrozWNCU
9S5L6y3U2UQ+O/jUBfJn
=f194
-END PGP SIGNATURE-

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

Re: Logging makes a grown man cry

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dale,

On 12/3/13, 11:01 PM, Dale Ogilvie wrote:
 Currently we use tomcat configured as out-of-the-box for logging
 (no log4j) and log4j.jar and config in the app war file.
 
 We found issues with trying to have log4j in catalina/lib.
 
 That said, it would be nice to use log4j for tomcat, however we
 found that the two configurations collided in our slf4j setup.

You can do this if you put log4j.jar into a server-only ClassLoader.
That's not configured by default in Tomcat 6+. We should add
documentation to show how that can be done, because conflicting
loggers are a total pain.

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

iQIcBAEBCAAGBQJSn2oqAAoJEBzwKT+lPKRYHccQAK32B5PG94nKGWv9/Ml4vmRg
UnsHGM1ThTb/CO7r1/Z0sZvuNVP+F+4S/il5dZ+pVftn00mBPmeSIYqjthsSgfg7
yYt2FQOLyk0fJjfcMCeXzPXMzxVSpQqGbaKkYYUXsufxHBWNJQImNQJh8HnB3kf8
koP0Y7WajN+cg5P+asHWsdwMeRHpieZmjytv3QHLdjgfnfbrLXAF3d5JmBA1pi5l
H4VTxHEDCPmejqNCRNdpD1ofdJDBScZXjMB5gvtVszQiYZYynfl/HTeMt5YrcFvo
QV0pdgK4hHlLz8TzZG04bmo+GfA1jSvy2x7yLXDKKV6DllnHGGRMpvY6qSEU62Yu
j24rHuPAUC26y3LYM5yK6IJaWnPtUYV9pHw+JHZRIEo1pIhrGLg3RboVase4SQb0
soqh4V8TcZ/bnzOklYB6fubP1vbTzWZx/kb3OhbOUTVFVPI9IEtmjezfxXurKVLK
4sEkOH8Xe1fVvMcTPx+cMcFn51e5HsxIIO6Vgjbzi8zXp+x51Tg57oZAlWsjacC1
ddqB24Sknb6gd8KeCEH3mI2IwzmzJSN8q0UZnOldfl4JD75s+R3eeu4Pg8jPiaaz
UA/CbcxBf5cXgnaYt6QWiAYuSOTFPuLJ34m9LXL5HfxiU3ZaciPGaT+7qCws0ID7
4v+Wul2gIGHJ1mqyCgcX
=a6/R
-END PGP SIGNATURE-

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

Re: Logging makes a grown man cry

[Tomcat Random]

Chris,

The examples don't meet your needs exactly? Well, I'm sure we're all
terribly sorry about that.

Heh...Sorry, I was responding to Konstantin's comment and mine crossed over
just before your long and helpful reply.

Thanks, as always,
Alec



On Wed, Dec 4, 2013 at 12:39 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Alec,

 On 12/4/13, 11:31 AM, Tomcat Random wrote:
  I'd argue that dealing with logging configuration is not newbie
  stuff. This is probably some of the most poorly implemented
  technology in the servlet container.

 What about the implementation is poor?

 The examples don't meet your needs exactly? Well, I'm sure we're all
 terribly sorry about that.

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

 iQIcBAEBCAAGBQJSn2jYAAoJEBzwKT+lPKRYsaIQAJfcFaOJU1r4+fFUywSBkVWC
 i8zi+HHJjk+eUpWBXZ2EsNnkNMvFkOGUiUZCbtjCCXfUOPhLSxpizj9XSJT6HKlR
 Asto5xPhyouCjnfU+/L5fRdqi2yJeRf7D1nTnLoeVbmBX5BzkG5M6Ni+PG1/r50P
 M+ZsfHHajmnLmD6IIysgjzc68RsJDb/cPShpgBi7X0cMY9831tE+cx/Dj6KcyBBo
 Wm070JNBEn6+y9L4bHr1WOM9m3Cr9QPdDBIG8X/1M7unAEe5lU+8kfBpKlIuMOZH
 FhnrhkziuSOTKssm97Bo1wIEw71ddaEBejEj3sc6fimwMl7osT3RYU5xuR0Evq6/
 pICSgwSX9Cnv84JAeHb96KJCJ8ahGOrZaCAm0lQ4hhwQjD0097kXwx31BQBIRzAt
 bgfPFGNGoeXuzNCwfvKUW1N77g+Y6pjW1rFUu8Z725j8XNttFCsxtDSPErRfG5ti
 k9XKbS5zUVC4W/E7eQduUMQZ4XLV03+bpXl/Idou7anZjP0cqgbzil48ifTP3Ckt
 me3d5ahUlYdJZ6ZW8JrW9+uomfN9egFItDaZm3Ro284nJjl8MVXulwKaPJs7KT1C
 p4ox1UrnEo/03vs0qeWBxFwSsjfY3YW6+RCF2j16wCrHX+Im4MzptOztUrozWNCU
 9S5L6y3U2UQ+O/jUBfJn
 =f194
 -END PGP SIGNATURE-

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

RE: Logging makes a grown man cry

[Dale Ogilvie]

 Dale wrote:
 We found issues with trying to have log4j in catalina/lib.
 
 That said, it would be nice to use log4j for tomcat, however we found 
 that the two configurations collided in our slf4j setup.

You can do this if you put log4j.jar into a server-only ClassLoader.
That's not configured by default in Tomcat 6+. We should add documentation to 
show how that can be done, because conflicting loggers are a total pain.

- -chris

Thanks for that tip.

Dale

RE: Logging makes a grown man cry

[Dale Ogilvie]

Alec: That seems like a good solution. Are you able to avoid having a
single giant catalina.out file in $CATALINA_HOME/logs?

No, we find we can live with that but we try to minimise writes to
stdout etc.  From Chris's note it seems like the ideal solution for us
would be

1. server log4j isolated in server class loader
2. log4j in each webapp as well

But just using standard tomcat logging for the server works adequately
for us too.

Dale


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

Re: Logging Best Practices on RHEL

[Tomcat Random]

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 
ch...@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 
  ch...@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-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Konstantin Kolinko]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging makes a grown man cry

[Konstantin Kolinko]

2013/12/3 Tomcat Random tomcat.ran...@gmail.com:
 Environment is RHEL6, Tomcat 7.0.42. There is only one webapp.

 I'm trying to implement log4j as per the instructions here (skipping step
 5):
 http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j

 Since I'm not using the Manager, I've removed the relevant logging lines
 from CATALINA_HOME/lib/log4j.properties, so it looks like this:

 _
 log4j.rootLogger=INFO, CATALINA
 (...)

 1., 2.

Either filter by category names, or bundle its own
classloader-specific Log4J configuration with your own web application
(a WEB-INF/classes/log4j.properties file).


Seriously, the Log4J documentation and mailing lists are elsewhere,
http://logging.apache.org/log4j/1.2/mail-lists.html

I'd be best to ask newbie questions there, even though this mailing
list has a log of knowledgeable people that may occasionally help you.


 3. Get rid of the empty localhost. file.


The configuration snippet that you provided does not have a cluster
appender. Thus it does not matches your list of log files.

Best regards,
Konstantin Kolinko

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

RE: Logging makes a grown man cry

[Dale Ogilvie]

Currently we use tomcat configured as out-of-the-box for logging (no
log4j) and log4j.jar and config in the app war file.

We found issues with trying to have log4j in catalina/lib.

That said, it would be nice to use log4j for tomcat, however we found
that the two configurations collided in our slf4j setup. 

Dale

-Original Message-
From: Tomcat Random [mailto:tomcat.ran...@gmail.com] 
Sent: Wednesday, 4 December 2013 7:12 a.m.
To: Tomcat Users List
Subject: Logging makes a grown man cry

So, all I want is to have:

1. one log file that rolls daily (a new file each day), with the date
appended, that catches my own logging code in the app, based on a global
logging level value that I can change (DEBUG, or INFO, or ERROR etc) as
needed.

2. Another log file that rolls daily and consolidates any other output
of the server and app (or two separate files) and also has a logging
level value that can be changed globally.

3. Get rid of the empty localhost. file.

MTIA,
Alec

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

Re: Logging Best Practices on RHEL

[Tomcat Random]

Thanks Chris, Are you using log4j 1.x or 2.beta?


On Fri, Nov 29, 2013 at 6:06 PM, Christopher Schultz 
ch...@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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Christopher Schultz]

-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  
 ch...@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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Tomcat Random]

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 
ch...@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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Logging Best Practices on RHEL

[Dale Ogilvie]

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.ran...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging Best Practices on RHEL

[Tomcat Random]

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 dale_ogil...@trimble.comwrote:

 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.ran...@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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging for session-replication debugging

[Mark Eggers]

On 8/26/2013 12:29 PM, Tomcat Random wrote:

What exactly should go in logging.properties to get the most information
about clustering/session replication?

I see two different logging suggestions, one in the docs and one in the
FAQ. Tried both but couldn't get anymore information that what's there
already coming out in the logs: No warnings, lots of INFO that seems like
things are OK.

Tomcat_7_42. My environment is two physical servers, RHEL6, each with an
instance of Tomcat.

Thanks in advance
Alec



It's been a while since I've played with this, so your mileage may vary.

# wrapped for easier reading
# added one additional handler

handlers = 1catalina.org.apache.juli.FileHandler,
   2localhost.org.apache.juli.FileHandler,
   3manager.org.apache.juli.FileHandler,
   4host-manager.or.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,
   5cluster.org.apache.juli.FileHandler

# just the new cluster log handler - all others are stock
# logging.properties
# beware of the wrapping

5cluster.org.apache.juli.FileHandler.level = FINER
5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5cluster.org.apache.juli.FileHandler.prefix = cluster.

# just the clustering logs - all others are stock logging.properties
org.apache.catalina.tribes.MESSAGES.level = FINE
org.apache.catalina.tribes.MESSAGES.handlers =
5cluster.org.apache.juli.FileHandler

org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.handlers =
5cluster.org.apache.juli.FileHandler

org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander

org.apache.catalina.ha.deploy.level = INFO
org.apache.catalina.ha.deploy.handlers =
5cluster.org.apache.juli.FileHandler

Set logging at the desired level.

I think I've posted this to the mailing list before . . .

/mde/

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

Re: Logging for session-replication debugging

[Tomcat Random]

Thank you, works perfectly.


On Mon, Aug 26, 2013 at 4:25 PM, Mark Eggers its_toas...@yahoo.com wrote:

 On 8/26/2013 12:29 PM, Tomcat Random wrote:

 What exactly should go in logging.properties to get the most information
 about clustering/session replication?

 I see two different logging suggestions, one in the docs and one in the
 FAQ. Tried both but couldn't get anymore information that what's there
 already coming out in the logs: No warnings, lots of INFO that seems like
 things are OK.

 Tomcat_7_42. My environment is two physical servers, RHEL6, each with an
 instance of Tomcat.

 Thanks in advance
 Alec


 It's been a while since I've played with this, so your mileage may vary.

 # wrapped for easier reading
 # added one additional handler

 handlers = 1catalina.org.apache.juli.**FileHandler,
2localhost.org.apache.juli.**FileHandler,
3manager.org.apache.juli.**FileHandler,
4host-manager.or.apache.juli.**FileHandler,
 java.util.logging.**ConsoleHandler,
5cluster.org.apache.juli.**FileHandler

 # just the new cluster log handler - all others are stock
 # logging.properties
 # beware of the wrapping

 5cluster.org.apache.juli.**FileHandler.level = FINER
 5cluster.org.apache.juli.**FileHandler.directory = ${catalina.base}/logs
 5cluster.org.apache.juli.**FileHandler.prefix = cluster.

 # just the clustering logs - all others are stock logging.properties
 org.apache.catalina.tribes.**MESSAGES.level = FINE
 org.apache.catalina.tribes.**MESSAGES.handlers =
 5cluster.org.apache.juli.**FileHandler

 org.apache.catalina.tribes.**level = FINE
 org.apache.catalina.tribes.**handlers =
 5cluster.org.apache.juli.**FileHandler

 org.apache.catalina.ha.level = FINE
 org.apache.catalina.ha.**handlers = 5cluster.org.apache.juli.**FileHander

 org.apache.catalina.ha.deploy.**level = INFO
 org.apache.catalina.ha.deploy.**handlers =
 5cluster.org.apache.juli.**FileHandler

 Set logging at the desired level.

 I think I've posted this to the mailing list before . . .

 /mde/

 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging cookies in Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ,

On 11/26/12 1:27 PM, Russ Kepler wrote:
 I'm running Tomcat 7 with juli logging enabled and so I'm seeing
 the standard logfiles.  In my access log I'm seeing the standard
 entries on each line and I'd like to see the cookies being passed
 as well - is there an easy way to do this - a property to set on
 the start up or something similar?

Do you need to be able to see arbitrary cookies, or do you have a
specific list of cookies for which you'd like to see values?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCzuIkACgkQ9CaO5/Lv0PCAegCgsw4KgaWKluqIVgvV0NO/1Azc
L0QAoJj6PmlG2RVhiM8i+6tgYyYJPzgy
=3C3D
-END PGP SIGNATURE-

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

Re: Logging cookies in Tomcat 7

[Russ Kepler]

On Monday, November 26, 2012 01:44:25 PM Christopher Schultz wrote:

 On 11/26/12 1:27 PM, Russ Kepler wrote:
  I'm running Tomcat 7 with juli logging enabled and so I'm seeing
  the standard logfiles.  In my access log I'm seeing the standard
  entries on each line and I'd like to see the cookies being passed
  as well - is there an easy way to do this - a property to set on
  the start up or something similar?
 
 Do you need to be able to see arbitrary cookies, or do you have a
 specific list of cookies for which you'd like to see values?

I'm trying to see if I'm passing the right jsessionid from a Java Web Start 
application.  I've found the AccessLogValve entry in the server.xml and added 
%{jsessionid}c to the log pattern.  I'm not seeing anything added to the log 
output, adding some plaintext to the pattern showed that I was in the right 
neighborhood.  I tried %c and got ???c???, so if there  doesn't seem to be a 
general print the cookies pattern.  I see a %S and that seems to be printing 
the session id but the session id seems to be changing between accesses:

127.0.0.1 - webtyper [26/Nov/2012:11:56:29 -0700] GET /WebTyper/Hello.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 200 470
127.0.0.1 - webtyper [26/Nov/2012:11:56:30 -0700] GET /WebTyper/appload.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 200 814
127.0.0.1 - - [26/Nov/2012:11:56:31 -0700] GET /WebTyper/app/Webtyper.jar 
HTTP/1.1 61592CE719254921F8D1543FBE44A4FF 304 -
127.0.0.1 - - [26/Nov/2012:11:56:43 -0700] POST 
/WebTyper/data/json/typer/post HTTP/1.1 61592CE719254921F8D1543FBE44A4FF 403 
1195

(sorry for the split lines)

So between the Java Web Start accessing the .jnlp and .jar the session id 
changes, and I thought I was setting it properly on the client end.  The 
servlet is being dispatched through  HttpServletDispatcher but I thought the 
session id would be common.  Am I mistaken or just screwed up in my thoughts?


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

Re: Logging cookies in Tomcat 7

[Russ Kepler]

On Monday, November 26, 2012 12:05:45 PM Russ Kepler wrote:
 On Monday, November 26, 2012 01:44:25 PM Christopher Schultz wrote:
  On 11/26/12 1:27 PM, Russ Kepler wrote:
   I'm running Tomcat 7 with juli logging enabled and so I'm seeing
   the standard logfiles.  In my access log I'm seeing the standard
   entries on each line and I'd like to see the cookies being passed
   as well - is there an easy way to do this - a property to set on
   the start up or something similar?
  
  Do you need to be able to see arbitrary cookies, or do you have a
  specific list of cookies for which you'd like to see values?
 
 I'm trying to see if I'm passing the right jsessionid from a Java Web Start
 application.  I've found the AccessLogValve entry in the server.xml and
 added %{jsessionid}c to the log pattern.  I'm not seeing anything added
 to the log output, adding some plaintext to the pattern showed that I was
 in the right neighborhood.  I tried %c and got ???c???, so if there 
 doesn't seem to be a general print the cookies pattern.  I see a %S and
 that seems to be printing the session id but the session id seems to be
 changing between accesses:

Bad form replying to myself, but the cookie name seems to be case sensitive.  
Changing the form to %{JSESSIONID}c seems to be printing the right cookie.  
Here's the log using %{JSESSIONID}c %S

127.0.0.1 - webtyper [26/Nov/2012:12:11:12 -0700] GET /WebTyper/Hello.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 8953D71715F23F7528C0C70B384B3F44 
200 470
127.0.0.1 - webtyper [26/Nov/2012:12:11:13 -0700] GET /WebTyper/appload.jsp 
HTTP/1.1 8953D71715F23F7528C0C70B384B3F44 8953D71715F23F7528C0C70B384B3F44 
200 814
127.0.0.1 - - [26/Nov/2012:12:11:13 -0700] GET /WebTyper/app/Webtyper.jar 
HTTP/1.1 - 9319C7008BC21C4894AF24C985B3F727 304 -
127.0.0.1 - - [26/Nov/2012:12:11:27 -0700] POST 
/WebTyper/data/json/typer/post HTTP/1.1 9319C7008BC21C4894AF24C985B3F727 
9319C7008BC21C4894AF24C985B3F727 403 1195

I still am getting 403 on the last access with what seems to be the right 
session id.  

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

Re: Logging cookies in Tomcat 7

[Konstantin Kolinko]

2012/11/26 Russ Kepler r...@kepler-eng.com:
 On Monday, November 26, 2012 01:44:25 PM Christopher Schultz wrote:

 so if there  doesn't seem to be a general print the cookies pattern.  I see 
 a %S and that seems to be printing

You can print all cookies sent by the client with %{Cookie}i
and new cookies sent by server with %{Set-Cookie}o

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

Re: Logging of user's login attempts

[Christopher Gross]

Hi Mark.

Thanks for the suggestion -- but I'm not getting the realm log file.  That
all looks like it should work, maybe there's just a little something that
I'm missing.

-- Chris


On Thu, Nov 8, 2012 at 4:26 PM, Mark Eggers its_toas...@yahoo.com wrote:

 On 11/8/2012 12:29 PM, Christopher Gross wrote:

 Using Tomcat 6.0.36.

 Realm: Realm className=org.apache.**catalina.realm.LockOutRealm
 failureCount=3 lockOutTime=30 Realm
 className=org.apache.**catalina.realm.**UserDatabaseRealm digest=SHA
 resourceName=UserDatabase / /Realm

 Is there a way that I can set it up to do user login auditing, so
 that I can see when a user logs in, or when they have a failed
 attempt, etc?  Been trying to google an answer, but I haven't been
 finding anything useful or specific.

 Let me know if there are any other config file snippets I can provide
 to figure out what I need to change.

 Thanks!

 -- Chris


 Chris,

 Note, I haven't tried this so I may be completely off-base. The following
 assumes that you're using the default JULI logging setup.

 The realm classes are logged via Tomcat's JULI logging system (unless
 you've converted to log4j). You'll need to add some logging for realms.

 In $CATALINA_BASE/conf, there is a file called logging.properties.
 You'll need to modify that in three places.

 1. Add a new handler by appending it to the list of current handlers

 Call it something like: 5realm.org.apache.juli.**FileHandler

 So your handlers line now looks like:

 handlers = 1catalina.org.apache.juli.**FileHandler,
 2localhost.org.apache.juli.**FileHandler,
 3manager.org.apache.juli.**FileHandler,
 4host-manager.org.apache.juli.**FileHandler,
 java.util.logging.**ConsoleHandler,5realm.org.**apache.juli.FileHandler

 (sorry for the line wrapping)

 2. Add the logging properties for your new handler

 Underneath the host manager entry, add something like the following:

 5realm.org.apache.juli.**FileHandler.level = FINE
 5realm.org.apache.juli.**FileHandler.directory = ${catalina.base}/logs
 5realm.org.apache.juli.**FileHandler.prefix = realm.

 This sets up a realm log file in $CATALINA_BASE/logs.

 3. Now set up the properties for the specific logger

 In the Facilities section, add something like the following after the
 host-manager entry.

 org.apache.catalina.realm.**MESSAGES.level = WARN
 org.apache.catalina.realm.**MESSAGES.handlers =
 5realm.org.apache.juli.**FileHandler

 (again, sorry for the line wrapping)

 The values on the left contain the package you want to log
 (org.apache.catalina.realm in this case), the message level
 (MESSAGES.level), and the handler (MESSAGES.handlers).

 The values on the right contain the actual level (WARN, since from the
 source code all login failures look like they are at the WARN level),
 and the handler you defined above (5realm.org.apache.juli.**FileHandler).

 Restart Tomcat and you should see login failures in realm.[date].log,
 where [date] is the date (rotated daily).

 More information on configuring logging can be found here:

 http://tomcat.apache.org/**tomcat-6.0-doc/logging.htmlhttp://tomcat.apache.org/tomcat-6.0-doc/logging.html

 Again, I've not done this for Realm logging. I've done this for Cluster
 logging and it seems to work well.

 . . . . just my two cents.
 /mde/

 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging of user's login attempts

[Mark Eggers]

On 11/9/2012 6:04 AM, Christopher Gross wrote:

Hi Mark.

Thanks for the suggestion -- but I'm not getting the realm log file.  That
all looks like it should work, maybe there's just a little something that
I'm missing.

-- Chris


On Thu, Nov 8, 2012 at 4:26 PM, Mark Eggers its_toas...@yahoo.com wrote:


On 11/8/2012 12:29 PM, Christopher Gross wrote:


Using Tomcat 6.0.36.

Realm: Realm className=org.apache.**catalina.realm.LockOutRealm
failureCount=3 lockOutTime=30 Realm
className=org.apache.**catalina.realm.**UserDatabaseRealm digest=SHA
resourceName=UserDatabase / /Realm

Is there a way that I can set it up to do user login auditing, so
that I can see when a user logs in, or when they have a failed
attempt, etc?  Been trying to google an answer, but I haven't been
finding anything useful or specific.

Let me know if there are any other config file snippets I can provide
to figure out what I need to change.

Thanks!

-- Chris



Chris,

Note, I haven't tried this so I may be completely off-base. The following
assumes that you're using the default JULI logging setup.

The realm classes are logged via Tomcat's JULI logging system (unless
you've converted to log4j). You'll need to add some logging for realms.

In $CATALINA_BASE/conf, there is a file called logging.properties.
You'll need to modify that in three places.

1. Add a new handler by appending it to the list of current handlers

Call it something like: 5realm.org.apache.juli.**FileHandler

So your handlers line now looks like:

handlers = 1catalina.org.apache.juli.**FileHandler,
2localhost.org.apache.juli.**FileHandler,
3manager.org.apache.juli.**FileHandler,
4host-manager.org.apache.juli.**FileHandler,
java.util.logging.**ConsoleHandler,5realm.org.**apache.juli.FileHandler

(sorry for the line wrapping)

2. Add the logging properties for your new handler

Underneath the host manager entry, add something like the following:

5realm.org.apache.juli.**FileHandler.level = FINE
5realm.org.apache.juli.**FileHandler.directory = ${catalina.base}/logs
5realm.org.apache.juli.**FileHandler.prefix = realm.

This sets up a realm log file in $CATALINA_BASE/logs.

3. Now set up the properties for the specific logger

In the Facilities section, add something like the following after the
host-manager entry.

org.apache.catalina.realm.**MESSAGES.level = WARN
org.apache.catalina.realm.**MESSAGES.handlers =
5realm.org.apache.juli.**FileHandler

(again, sorry for the line wrapping)

The values on the left contain the package you want to log
(org.apache.catalina.realm in this case), the message level
(MESSAGES.level), and the handler (MESSAGES.handlers).

The values on the right contain the actual level (WARN, since from the
source code all login failures look like they are at the WARN level),
and the handler you defined above (5realm.org.apache.juli.**FileHandler).

Restart Tomcat and you should see login failures in realm.[date].log,
where [date] is the date (rotated daily).

More information on configuring logging can be found here:

http://tomcat.apache.org/**tomcat-6.0-doc/logging.htmlhttp://tomcat.apache.org/tomcat-6.0-doc/logging.html

Again, I've not done this for Realm logging. I've done this for Cluster
logging and it seems to work well.

. . . . just my two cents.
/mde/



Hmm,

I had thought that should work. Like I said in my email (above), I've 
not tried this for realms, but have done this for clusters.


Most info looks like it's at the DEBUG level (at least in LockOutRealm).

A quick search through the mailing list has recommended FINEST as the 
log level.


Give FINEST a try rather than INFO and see what appears in your logs.

. . . . just my two cents (without coffee)
/mde/

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

Re: Logging of user's login attempts

[Christopher Gross]

Mark,

I already had it down to FINE, but I switched it to FINEST but I still
didn't get the realm.date.txt file to show up.

Perhaps the control lines (the ones with MESSAGES in them) aren't quite
right for realm, but that's how your clustering setup works.  Perhaps
someone else who has done this can chime in, but I'll keep looking around.
 I think you got me started on the right track.

Thanks for your help, let me know if you get any other ideas.

-- Chris


On Fri, Nov 9, 2012 at 11:33 AM, Mark Eggers its_toas...@yahoo.com wrote:

 On 11/9/2012 6:04 AM, Christopher Gross wrote:

 Hi Mark.

 Thanks for the suggestion -- but I'm not getting the realm log file.  That
 all looks like it should work, maybe there's just a little something that
 I'm missing.

 -- Chris


 On Thu, Nov 8, 2012 at 4:26 PM, Mark Eggers its_toas...@yahoo.com
 wrote:

  On 11/8/2012 12:29 PM, Christopher Gross wrote:

  Using Tomcat 6.0.36.

 Realm: Realm className=org.apache.catalina.realm.LockOutRealm

 failureCount=3 lockOutTime=30 Realm
 className=org.apache.catalina.realm.UserDatabaseRealm
 digest=SHA

 resourceName=UserDatabase / /Realm

 Is there a way that I can set it up to do user login auditing, so
 that I can see when a user logs in, or when they have a failed
 attempt, etc?  Been trying to google an answer, but I haven't been
 finding anything useful or specific.

 Let me know if there are any other config file snippets I can provide
 to figure out what I need to change.

 Thanks!

 -- Chris


  Chris,

 Note, I haven't tried this so I may be completely off-base. The following
 assumes that you're using the default JULI logging setup.

 The realm classes are logged via Tomcat's JULI logging system (unless
 you've converted to log4j). You'll need to add some logging for realms.

 In $CATALINA_BASE/conf, there is a file called logging.properties.
 You'll need to modify that in three places.

 1. Add a new handler by appending it to the list of current handlers

 Call it something like: 5realm.org.apache.juli.FileHandler


 So your handlers line now looks like:

 handlers = 1catalina.org.apache.juli.FileHandler,
 2localhost.org.apache.juli.FileHandler,
 3manager.org.apache.juli.FileHandler,
 4host-manager.org.apache.juli.FileHandler,
 java.util.logging.ConsoleHandler,5realm.org.
 apache.juli.FileHandler


 (sorry for the line wrapping)

 2. Add the logging properties for your new handler

 Underneath the host manager entry, add something like the following:

 5realm.org.apache.juli.FileHandler.level = FINE
 5realm.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
 5realm.org.apache.juli.FileHandler.prefix = realm.


 This sets up a realm log file in $CATALINA_BASE/logs.

 3. Now set up the properties for the specific logger

 In the Facilities section, add something like the following after the
 host-manager entry.

 org.apache.catalina.realm.MESSAGES.level = WARN
 org.apache.catalina.realm.MESSAGES.handlers =
 5realm.org.apache.juli.FileHandler


 (again, sorry for the line wrapping)

 The values on the left contain the package you want to log
 (org.apache.catalina.realm in this case), the message level
 (MESSAGES.level), and the handler (MESSAGES.handlers).

 The values on the right contain the actual level (WARN, since from the
 source code all login failures look like they are at the WARN level),
 and the handler you defined above (5realm.org.apache.juli.
 FileHandler).


 Restart Tomcat and you should see login failures in realm.[date].log,
 where [date] is the date (rotated daily).

 More information on configuring logging can be found here:

 http://tomcat.apache.org/tomcat-6.0-doc/logging.htmlhttp://tomcat.apache.org/**tomcat-6.0-doc/logging.html
 ht**tp://tomcat.apache.org/tomcat-**6.0-doc/logging.htmlhttp://tomcat.apache.org/tomcat-6.0-doc/logging.html
 


 Again, I've not done this for Realm logging. I've done this for Cluster
 logging and it seems to work well.

 . . . . just my two cents.
 /mde/


 Hmm,

 I had thought that should work. Like I said in my email (above), I've not
 tried this for realms, but have done this for clusters.

 Most info looks like it's at the DEBUG level (at least in LockOutRealm).

 A quick search through the mailing list has recommended FINEST as the log
 level.

 Give FINEST a try rather than INFO and see what appears in your logs.

 . . . . just my two cents (without coffee)

 /mde/

 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Logging of user's login attempts

[Jose María Zaragoza]

2012/11/9 Christopher Gross cogr...@gmail.com


  Perhaps
 someone else who has done this can chime in, but I'll keep looking around.
  I think you got me started on the right track.



Well, I'm used to extending  UserDatabaseRealm class and to configure
Tomcat with it, so I can have more control , by example , logging.

Re: Logging of user's login attempts

[Mark Eggers]

On 11/8/2012 12:29 PM, Christopher Gross wrote:

Using Tomcat 6.0.36.

Realm: Realm className=org.apache.catalina.realm.LockOutRealm
failureCount=3 lockOutTime=30 Realm
className=org.apache.catalina.realm.UserDatabaseRealm digest=SHA
resourceName=UserDatabase / /Realm

Is there a way that I can set it up to do user login auditing, so
that I can see when a user logs in, or when they have a failed
attempt, etc?  Been trying to google an answer, but I haven't been
finding anything useful or specific.

Let me know if there are any other config file snippets I can provide
to figure out what I need to change.

Thanks!

-- Chris



Chris,

Note, I haven't tried this so I may be completely off-base. The 
following assumes that you're using the default JULI logging setup.


The realm classes are logged via Tomcat's JULI logging system (unless 
you've converted to log4j). You'll need to add some logging for realms.


In $CATALINA_BASE/conf, there is a file called logging.properties.
You'll need to modify that in three places.

1. Add a new handler by appending it to the list of current handlers

Call it something like: 5realm.org.apache.juli.FileHandler

So your handlers line now looks like:

handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,5realm.org.apache.juli.FileHandler

(sorry for the line wrapping)

2. Add the logging properties for your new handler

Underneath the host manager entry, add something like the following:

5realm.org.apache.juli.FileHandler.level = FINE
5realm.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5realm.org.apache.juli.FileHandler.prefix = realm.

This sets up a realm log file in $CATALINA_BASE/logs.

3. Now set up the properties for the specific logger

In the Facilities section, add something like the following after the
host-manager entry.

org.apache.catalina.realm.MESSAGES.level = WARN
org.apache.catalina.realm.MESSAGES.handlers =
5realm.org.apache.juli.FileHandler

(again, sorry for the line wrapping)

The values on the left contain the package you want to log
(org.apache.catalina.realm in this case), the message level
(MESSAGES.level), and the handler (MESSAGES.handlers).

The values on the right contain the actual level (WARN, since from the
source code all login failures look like they are at the WARN level),
and the handler you defined above (5realm.org.apache.juli.FileHandler).

Restart Tomcat and you should see login failures in realm.[date].log,
where [date] is the date (rotated daily).

More information on configuring logging can be found here:

http://tomcat.apache.org/tomcat-6.0-doc/logging.html

Again, I've not done this for Realm logging. I've done this for Cluster
logging and it seems to work well.

. . . . just my two cents.
/mde/

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

Re: Logging framework for Tomcat -Exceptions

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kiran,

On 7/11/12 11:33 PM, Kiran Badi wrote:
 I know this is not a place to learn Java and thats not my
 intention.Its time for me to implement robust logging framework,so
 thought let me ask here as which is light weight and yet can log
 exceptions preferably both handled and unhandled.

No logging framework is going to catch your exceptions for you and
magically log them: you'll have to catch them yourself and explicitly
log them. You can easily write a Filter that you can plug-into any
servlet container (including Tomcat) that will catch any exception you
want a and log it any way you want.

As for logging frameworks, I don't know of a single one that would
somehow be incompatible with Tomcat.

Good logging frameworks include:
- - Apache log4j
- - java.util.logging
- - logback

Or, you might prefer a meta logging package that can work with any
of those:
- - Apache commons-logging
- - slf4j

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAAIyIACgkQ9CaO5/Lv0PDvpwCgtBCqisSe9kNB0v8Y8mAQPsiU
5rYAnjmZS9Ktn3ZrptUgFto7I2nD+Jz1
=QBHn
-END PGP SIGNATURE-

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

Re: Logging framework for Tomcat -Exceptions

[Tim Watts]

On Thu, 2012-07-12 at 06:35 +0530, Kiran Badi wrote:
 Hi,
 
 I have below code for catching DAO exceptions,

No, it's not.  It's code that defines an interface and a poorly
implemented exception type.  There's no catching.  Anywhere.

 but I feel its not correct 
 way to do this,Can some one point me to some library which will capture 
 all exceptions which my code will throw and works with tomcat. I 
 implementing Model2 mvc pattern and to my surprise I am able to show 
 values to the view but database is not getting inserted.I am lost given 
 that no exception is also being thrown anywhere.All logs looks clean but 
 DB is not updated.
 
 import java.sql.Connection;
 
 public interface DAO {
 
  Connection getConnection() throws DAOException;
 
 }
 
 public class DAOException extends Exception {
  private static final long serialVersionUID = 19192L;
 
  public DAOException() {
  }
  public DAOException(String message) {
  this.message = message;
  }
  @Override
  public String getMessage() {
  return message;
  }
  public void setMessage(String message) {
  this.message = message;
  }
  private String message;
 
  @Override
  public String toString() {
  return message;
  }
 }
 
Other than including Tomcat in the subject, this has nothing to do with
Tomcat.  No offense, but this really isn't a list for teaching Java.
But what the hell, I'll make one exception:

public class DAOException extends Exception {
public DAOException(String msg) {
super();
}

public DAOException(String msg) {
super(msg);
}

public DAOException(String msg, Throwable cause) {
super(msg, cause);
}

public DAOException(Throwable cause) {
super(cause);
}
}

That's all I'll say on this thread.


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



signature.asc
Description: This is a digitally signed message part

Re: Logging framework for Tomcat -Exceptions

[Kiran Badi]

On 7/12/2012 7:20 AM, Tim Watts wrote:

No offense, but this really isn't a list for teaching Java.
But what the hell, I'll make one exception:

public class DAOException extends Exception {
 public DAOException(String msg) {
super();
 }
 
 public DAOException(String msg) {

super(msg);
 }
 
 public DAOException(String msg, Throwable cause) {

super(msg, cause);
 }
 
 public DAOException(Throwable cause) {

super(cause);
 }
}

That's all I'll s say on this thread.
I know Tim something was missing.Just 20 mins back I fixed the class,now 
I get the cool stack trace,damm it file upload stuff is breaking and 
passing null values.I will fix it.


I know this is not a place to learn Java and thats not my intention.Its 
time for me to implement robust logging framework,so thought let me ask 
here as which is light weight and yet can log exceptions preferably both 
handled and unhandled.


and thanks for some headsup.


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

RE: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS

[Caldarale, Charles R]

 From: Alex Hooper [mailto:ahoo...@bmjgroup.com] 
 Subject: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 
 LTS

 With the software noted above

Thanks for providing that.

 I get the following when starting tomcat and no logs 
 other than catalina.are produced.

 Can't load log handler 1catalina.org.apache.juli.FileHandler
 java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler

That looks like your logging.properties file contains invalid settings.  Please 
post it here.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS

[Alex Hooper]

Caldarale, Charles R uttered:
From: Alex Hooper [mailto:ahoo...@bmjgroup.com] 
Subject: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS



With the software noted above


Thanks for providing that.

I get the following when starting tomcat and no logs 
other than catalina.are produced.



Can't load log handler 1catalina.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler


That looks like your logging.properties file contains invalid settings.  Please 
post it here.



Sure. We've not modified it, though, so should be as per dist.

$ cat conf/logging.properties
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

handlers = 1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler


.handlers = 1catalina.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler


# Handler specific properties.
# Describes specific configuration info for Handlers.


1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.

4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter



# Facility specific properties.
# Provides extra control for each logger.


org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 
2localhost.org.apache.juli.FileHandler


org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = 
INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers 
= 3manager.org.apache.juli.FileHandler


org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level 
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers 
= 4host-manager.org.apache.juli.FileHandler


# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE
#org.apache.catalina.core.AprLifecycleListener.level=FINE



 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__



--
Alex Hooper
Operations Team Leader, BMJ Group, BMA House, London WC1H 9JR
Tel: +44 (0) 20 7383 6049
http://group.bmj.com/

___
The BMJ Group is one of the world's most trusted providers of medical 
information for doctors, researchers, health care workers and patients 

RE: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS

[Caldarale, Charles R]

 From: Alex Hooper [mailto:ahoo...@bmjgroup.com] 
 Subject: Re: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 
 10.04.3 LTS

 We've not modified it, though, so should be as per dist.

It appears to be as you say.  Looking at the stack trace a bit more:

 java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler
 ...
 at 
 java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:345)
 ...
 at java.util.logging.Logger.getLogger(Logger.java:287)
 at sun.management.snmp.util.MibLogger.init(MibLogger.java:57)
 at sun.management.snmp.util.MibLogger.init(MibLogger.java:42)
 at 
 sun.management.jmxremote.ConnectorBootstrap.clinit(ConnectorBootstrap.java:760)
 at sun.management.Agent.startAgent(Agent.java:127)
 at sun.management.Agent.startAgent(Agent.java:239)

It appears that the JMX agent is using Tomcat's logging.properties but with the 
unmodified java.util.logging package from the JRE rather than JULI from Tomcat. 
 Can you show us what the eventual command line is that launches Tomcat?  The 
parameter specifying 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager looks like 
it's missing.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: logging failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS

[Alex Hooper]

Caldarale, Charles R uttered:

From: Alex Hooper [mailto:ahoo...@bmjgroup.com] Subject: Re: logging
failure with tomcat 6.0.29, jvm 1.6.0_30-b12, ubuntu 10.04.3 LTS



We've not modified it, though, so should be as per dist.


It appears to be as you say.  Looking at the stack trace a bit more:


java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler ...
 at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:345) 
... at java.util.logging.Logger.getLogger(Logger.java:287) at

sun.management.snmp.util.MibLogger.init(MibLogger.java:57) at
sun.management.snmp.util.MibLogger.init(MibLogger.java:42) at
sun.management.jmxremote.ConnectorBootstrap.clinit(ConnectorBootstrap.java:760)
 at sun.management.Agent.startAgent(Agent.java:127) at
sun.management.Agent.startAgent(Agent.java:239)


It appears that the JMX agent is using Tomcat's logging.properties but with
the unmodified java.util.logging package from the JRE rather than JULI from
Tomcat.  Can you show us what the eventual command line is that launches
Tomcat?  The parameter specifying
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager looks like
it's missing.



Oh. My. Goodness.

Thank $deity for fresh eyes. An edit to catalina.sh had caused that parameter to 
be lost.


It's scary how much time that kind of error can consume.

Thank you so much for taking the time and spotting that.

Cheers,

Alex.




- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.


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


__ This
email has been scanned by the Symantec Email Security.cloud service. For more
information please visit http://www.symanteccloud.com 
__



--
Alex Hooper
Operations Team Leader, BMJ Group, BMA House, London WC1H 9JR
Tel: +44 (0) 20 7383 6049
http://group.bmj.com/

___
The BMJ Group is one of the world's most trusted providers of medical 
information for doctors, researchers, health care workers and patients 
group.bmj.com.  This email and any attachments are confidential.  If you have 
received this email in error, please delete it and kindly notify us.  If the 
email contains personal views then the BMJ Group accepts no responsibility for 
these statements.  The recipient should check this email and attachments for 
viruses because the BMJ Group accepts no liability for any damage caused by 
viruses.  Emails sent or received by the BMJ Group may be monitored for size, 
traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ 
Group.  A private limited company, registered in England and Wales under 
registration number 03102371.  Registered office: BMA House, Tavistock Square, 
London WC1H 9JR, UK.
___

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

Re: [logging processes] Too many or Not too many?

[Pae Choi]

On 02/18/2012 05:17 PM, Mark Thomas wrote:

On 18/02/2012 21:57, Pae Choi wrote:

Tomcat v7.0.25
CentOS 5.7 32bit

Running the tomcat without any webapp deployed, the system shows about
38 processes(i think)
related to logging. Why that many and what are they logging about?

I see some of logging under the $CATALINA_HOME/logs folder and they
seemed to be reasonably
needed. But what others related to that many logging processes?

1. Don't hijack threads.

2. Be patient.

Mark

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



My apologies for not being patient as well as hijacking the thread. It's 
2nd posting since the
1st posting didn't appeared as fast as used be about a little over a 
decade ago. So I just wanted

to test to see if any posting works.

Anyhow, your reply confirmed what I intended for. Thanks.


Pae

Re: [logging processes] Too many or Not too many?

[Mark Thomas]

On 18/02/2012 21:57, Pae Choi wrote:
 Tomcat v7.0.25
 CentOS 5.7 32bit
 
 Running the tomcat without any webapp deployed, the system shows about
 38 processes(i think)
 related to logging. Why that many and what are they logging about?
 
 I see some of logging under the $CATALINA_HOME/logs folder and they
 seemed to be reasonably
 needed. But what others related to that many logging processes?

1. Don't hijack threads.

2. Be patient.

Mark

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

Re: Logging issue in Eclipse/WTP (disable request logging)

[Pid]

On 14/02/2012 21:49, Marcel Stör wrote:
 It seems nowadays you need a PHD just to understand Tomcat
 logging...sigh. In one of my Eclipse/WTP projects Tomcat logs each
 request (before and after):
 
 ...
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: After request
 [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null]
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null]
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: After request [uri=/demo-webmvc-web/images/logo.gif?null]
 ...
 
 How do I get rid of this?

Tomcat doesn't log an INFO level output for that - have you by any
chance got a Servlet Filter in your application?


p



-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: Logging issue in Eclipse/WTP (disable request logging)

[Konstantin Kolinko]

2012/2/15 Pid p...@pidster.com:
 On 14/02/2012 21:49, Marcel Stör wrote:
 It seems nowadays you need a PHD just to understand Tomcat
 logging...sigh. In one of my Eclipse/WTP projects Tomcat logs each
 request (before and after):

 ...
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: After request
 [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null]
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null]
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: After request [uri=/demo-webmvc-web/images/logo.gif?null]
 ...

 How do I get rid of this?

 Tomcat doesn't log an INFO level output for that - have you by any
 chance got a Servlet Filter in your application?


One more.
If  Tomcat logging is indeed used, then any logging.properties file in
the classpath will change logging configuration for the classloader
that it is accessible from.

Here is such problem reported caused by jollyday library that
contained a logging.properties file:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52011

This feature is usually used by web applications when they provide
their own WEB-INF/classes/logging.properties file.

Best regards,
Konstantin Kolinko

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

Re: Logging issue in Eclipse/WTP (disable request logging)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marcel,

On 2/14/12 4:49 PM, Marcel Stör wrote:
 It seems nowadays you need a PHD just to understand Tomcat 
 logging...sigh.

Does that mean that I can get an honorary PhD if I understand it?

 In one of my Eclipse/WTP projects Tomcat logs each request (before
 and after):
 
 ... 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
 log INFO: After request 
 [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null]

 
13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log
 INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null] 
 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
 log INFO: After request
 [uri=/demo-webmvc-web/images/logo.gif?null] ...
 
 How do I get rid of this?

That depends. In what log file does this appear? What version of
Tomcat are you using?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk862LwACgkQ9CaO5/Lv0PC8fQCfYWdMLTXsNM2fqFtKFVwUEc9a
+3UAn2Y1hftX5q4ZvGhKxWJQF98kr9uX
=88sc
-END PGP SIGNATURE-

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

Re: Logging issue in Eclipse/WTP (disable request logging)

[Marcel Stör]

On 14.02.2012 22:57, Christopher Schultz wrote:

In one of my Eclipse/WTP projects Tomcat logs each request (before
  and after):

  ... 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
  log INFO: After request
  [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null]



13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log

  INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null]
  13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
  log INFO: After request
  [uri=/demo-webmvc-web/images/logo.gif?null] ...

  How do I get rid of this?

That depends. In what log file does this appear? What version of
Tomcat are you using?


I see those statements in the Eclipse console (sys error) and I'm using 
Tomcat 7.0.19. Sorry, this was crucial information I forget to provide.


Marcel

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

Re: Logging issue in Eclipse/WTP (disable request logging)

[Konstantin Kolinko]

2012/2/15 Marcel Stör mar...@frightanic.com:
 On 14.02.2012 22:57, Christopher Schultz wrote:

 In one of my Eclipse/WTP projects Tomcat logs each request (before
   and after):
 
   ... 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
   log INFO: After request
   [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null]
 
 

 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log

   INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null]
   13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext
   log INFO: After request
   [uri=/demo-webmvc-web/images/logo.gif?null] ...
 
   How do I get rid of this?

 That depends. In what log file does this appear? What version of
 Tomcat are you using?


 I see those statements in the Eclipse console (sys error) and I'm using
 Tomcat 7.0.19. Sorry, this was crucial information I forget to provide.


You have to look at the JVM arguments that are used to launch Tomcat.

That should be on the Servers view - click the server there so that
it opens some pretty page with its configuration. On that page there
will be a link to launch configuration. Click it and see that it
displays.

You have to look for
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
and
-Djava.util.logging.config.file= some path

If there is no -Djava.util.logging.manager setting then the logging
is done by your JRE, not by Tomcat.

If it is there, then you will see what configuration file it uses.

Best regards,
Konstantin Kolinko

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

Re: Logging per webapp per instance

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Simon,

On 12/21/11 2:55 AM, Simon wrote:
 It is not really a hack in log4j configuration to redirect the logs
 in stdout, as it is exactly what does the ConsoleAppender by
 default...

True, log4j supports log-to-console. It's only a hack because of the
other stuff you have to do to get it to work.

 The idea here is that we (the developpers) can focus on *what* get 
 logged by configuring the log categories and the log pattern in
 the log4.properties file using a simple ConsoleAppender.

I understand the use case for a logging framework.

 Our infrastructure team (responsible for the server configuration
 and resources) can focus on *where* the logs go (a file, a rolling
 file, a JMS queue, syslog, or whatever the need) in the Tomcat
 configuration.
 
 This has the other advantage to have a log4.configuration file and
 a web application that are not too much dependant of the
 environment (Unix file path vs Windows file path for example)...

So, you're saying that you want your intra team to be able to dictate
where the logs go, but you don't want them to be able to configure the
logger properly to do that. I'm not a huge fan of that philosophy.

 I guess this why the stdout / feature is available in Resin...
 At least it would help in this use case !

As I said, you can do this in Tomcat. I just think it's a bad idea.
The swallowOutput flag IMO is a hack to get around applications that
are still using System.out for logging purposes. What you are trying
to do is take a perfectly reasonably use of a logging system and turn
back the clock to 1997. If that's what works for you, go for it. I
just think there are better solutions.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7x+3wACgkQ9CaO5/Lv0PAY5ACdH9CbpvjSVmWANTNZmYhYNu7n
xQUAoK23Aj5Vd52qL2/Tungyp665SXzc
=+cRq
-END PGP SIGNATURE-

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

Re: Logging per webapp per instance

[Simon]

Hi,

I will use the variable substitution solution by changing the
log4j.properties file :

log4j.logFileSuffix=...
log4j.appender.file.File=/var/log/webapp-${logSuffix}.log

The value will be overriden by each instances with
-Dlog4j.logFileSuffix=whatever

Thank you for your help !

Regards,
Simon

2011/12/19 Daniel Mikusa dmik...@vmware.com:
 On Mon, 2011-12-19 at 09:05 -0800, Leon Rosenberg wrote:
 Hello,

 you can specify the logoutput as relative path:
 instead of
 log4j.appender.file.File=/var/log/webapp.log
 to
 log4j.appender.file.File=logs/webapp.log
 and link the local file to the desired destination.


 +1

 or if you don't want to use relative paths, you could use a variable
 substitution.

 Ex:

  log4j.appender.file.File=${catalina.base}/logs/webapp.log


 Property substitution is not limited to catalina.base (it's just easy
 to use since it's defined automatically), Log4J can substitute any
 system property.  So you could define your own.

 Ex:

 In bin/setenv.sh...

  -Dmy.log.prefix=server1

 In log4j.properties...

  log4j.appender.file.File=/var/log/${my.log.prefix}-webapp.log


 For more details on property substitution.

 https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html


 Dan



 regards
 Leon

 On Mon, Dec 19, 2011 at 5:54 PM, Simon spyd...@gmail.com wrote:
  Hi,
 
  Our webapp is packaged with the log4j framework (1.2.16) and a log4j
  configuration that redirect all logs to a file on the server
  filesystem. This log file is rotated when it reaches 50M.
 
  Here is the configuration detail :
 
  log4j.rootLogger=INFO, file
  log4j.appender.file=org.apache.log4j.RollingFileAppender
  log4j.appender.file.File=/var/log/webapp.log
  log4j.appender.file.MaxFileSize=5KB
  log4j.appender.file.MaxBackupIndex=50
  log4j.appender.file.layout=org.apache.log4j.PatternLayout
  log4j.appender.file.layout.ConversionPattern=%d %-5p %c - %m%n
 
  This configuration file is located inside the webapp.war archive at
  /WEB-INF/classes/log4j.properties.
 
  In our production environment, we started with one tomcat instance and
  everything was fine. The tomcat version is 5.5.20 and it is running on
  the Oracle JVM 1.6.0_23-b05.
 
 
  Unfortunately, when the infrastructure team added 2 other Tomcat
  instances on the same server with the same webapp.war inside, some
  logs were lost. The 2 instances are basically a complete copy of the
  file tree of the first instance. Thus, there is 3 identical webapps
  logging into the same log file simultaneously :
  /tomcat/instance-1/webapps/webapp.war = /var/log/webapp.log
  /tomcat/instance-2/webapps/webapp.war = /var/log/webapp.log
  /tomcat/instance-3/webapps/webapp.war = /var/log/webapp.log
 
  My hypothesis is that as every webapp log to the same log file from a
  different JVM (the tomcat instances), there could be some concurrency
  issues when the rolling from log4j occurs !!!
 
 
  I would like that each webapp logs to a particular file without having
  a different log4j configuration packaged in the webapp.war archive. My
  first idea was to modify the log4j configuration so the webapp will
  log to the console (stdout) and then find a way to redirect the stdout
  inside a Tomcat instance to a particular file :
  /tomcat/instance-1/webapps/webapp.war = stdout = /var/log/webapp-1.log
  /tomcat/instance-2/webapps/webapp.war = stdout = /var/log/webapp-2.log
  /tomcat/instance-3/webapps/webapp.war = stdout = /var/log/webapp-3.log
 
  I know i could achieve that with the Resin application server through
  the use of the stdout / configuration element
  (http://caucho.com/resin-4.0/reference.xtp#stdoutlog,
  http://caucho.com/resin-4.0/admin/logging.xtp).
 
  Is there a way to mimic this behaviour in Tomcat ?
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 

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


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

Re: Logging per webapp per instance

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Simon,

On 12/19/11 11:54 AM, Simon wrote:
 log4j.appender.file.File=/var/log/webapp.log
 
 Thus, there is 3 identical webapps logging into the same log file 
 simultaneously :

It's more likely that the last one wins: the first 2 logs was probably
lost entirely.

 My hypothesis is that as every webapp log to the same log file from
 a different JVM (the tomcat instances), there could be some
 concurrency issues when the rolling from log4j occurs !!!

Some issues definitely. You need to change this.

 I would like that each webapp logs to a particular file without
 having a different log4j configuration packaged in the webapp.war
 archive. My first idea was to modify the log4j configuration so the
 webapp will log to the console (stdout) and then find a way to
 redirect the stdout inside a Tomcat instance to a particular file

That sounds awful: a hack (in log4j config) to go to stdout and then
another hack (in Tomcat config) to redirect to a file. Yuck.

 Is there a way to mimic this behaviour in Tomcat ?

*Sigh* if you have to, you can use the swallowOutput attribute on
your Context definition. Then you have to configure Tomcat's logging
system to put the logs where you want them.

IMO a better idea would be to configure log4j properly. I think you
have several options:

1. Modify the log4j.properties file in each WAR file to specify
   the proper filename. You said you didn't want to do this.

2. Use a log4j.properties file that is outside your WAR file.
   You'll have to figure out how to get your webapp to detect
   the right file so that your 3 separate copies don't end up
   reading the same file and reproducing the same issue described
   above.

3. In your log4j startup code, set a property based upon some
   configuration or environment (context path?) that can be used
   by log4j during configuration and setup of the logging system.
   I personally favor this approach. If you are running in separate
   JVMs, I think you can use system properties and have those
   replaced by log4j when parsing the configuration file(s).
   Read the documentation to be sure.

4. Configure log4j to log to syslog, and have syslog take care of
   the file situation. Of course, you'll have to identify each
   separate instance of your webapp if you want to be able to
   sort-out which log came from which source. So, you still
   have to somehow identify these webapps uniquely.

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7w0ZIACgkQ9CaO5/Lv0PAnlgCgmSXshaoYgwz1XRd+bl9JJZ2a
dF0An15eYuAzMy5w8A2AwZN4FEF229/A
=WE6F
-END PGP SIGNATURE-

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

Re: Logging per webapp per instance

[Konstantin Kolinko]

2011/12/20 Christopher Schultz ch...@christopherschultz.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Simon,

 On 12/19/11 11:54 AM, Simon wrote:
 log4j.appender.file.File=/var/log/webapp.log

 Thus, there is 3 identical webapps logging into the same log file
 simultaneously :

 It's more likely that the last one wins: the first 2 logs was probably
 lost entirely.

FileAppender docs say that Append=true by default. Though I wonder
what will happen during log rotation.

Anyway entries from three servers in the same log file where they
cannot be distinguished from each other are of little help.


 My hypothesis is that as every webapp log to the same log file from
 a different JVM (the tomcat instances), there could be some
 concurrency issues when the rolling from log4j occurs !!!

 Some issues definitely. You need to change this.

 I would like that each webapp logs to a particular file without
 having a different log4j configuration packaged in the webapp.war
 archive. My first idea was to modify the log4j configuration so the
 webapp will log to the console (stdout) and then find a way to
 redirect the stdout inside a Tomcat instance to a particular file

 That sounds awful: a hack (in log4j config) to go to stdout and then
 another hack (in Tomcat config) to redirect to a file. Yuck.

 Is there a way to mimic this behaviour in Tomcat ?

 *Sigh* if you have to, you can use the swallowOutput attribute on
 your Context definition. Then you have to configure Tomcat's logging
 system to put the logs where you want them.

That is fragile. It depends on who catches the value of System.out
first, Tomcat or a logging framework.


 IMO a better idea would be to configure log4j properly. I think you
 have several options:

 1. Modify the log4j.properties file in each WAR file to specify
   the proper filename. You said you didn't want to do this.

 2. Use a log4j.properties file that is outside your WAR file.
   You'll have to figure out how to get your webapp to detect
   the right file so that your 3 separate copies don't end up
   reading the same file and reproducing the same issue described
   above.

 3. In your log4j startup code, set a property based upon some
   configuration or environment (context path?) that can be used
   by log4j during configuration and setup of the logging system.
   I personally favor this approach. If you are running in separate
   JVMs, I think you can use system properties and have those
   replaced by log4j when parsing the configuration file(s).
   Read the documentation to be sure.

 4. Configure log4j to log to syslog, and have syslog take care of
   the file situation. Of course, you'll have to identify each
   separate instance of your webapp if you want to be able to
   sort-out which log came from which source. So, you still
   have to somehow identify these webapps uniquely.


5. Configure it to write ${catalina.base}/logs.

(That is if all webapps are on different Tomcat instances, as opposed
to having several different-named webapps on the same Tomcat)

If you want that to be written to /var/logs, you can replace
${catalina.base}/logs with a symlink to /var/logs/instance-N/.

Best regards,
Konstantin Kolinko

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

Re: Logging per webapp per instance

[Simon]

2011/12/21 Konstantin Kolinko knst.koli...@gmail.com:
 2011/12/20 Christopher Schultz ch...@christopherschultz.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Simon,

 On 12/19/11 11:54 AM, Simon wrote:
 log4j.appender.file.File=/var/log/webapp.log

 Thus, there is 3 identical webapps logging into the same log file
 simultaneously :

 It's more likely that the last one wins: the first 2 logs was probably
 lost entirely.

 FileAppender docs say that Append=true by default. Though I wonder
 what will happen during log rotation.

 Anyway entries from three servers in the same log file where they
 cannot be distinguished from each other are of little help.


 My hypothesis is that as every webapp log to the same log file from
 a different JVM (the tomcat instances), there could be some
 concurrency issues when the rolling from log4j occurs !!!

 Some issues definitely. You need to change this.

 I would like that each webapp logs to a particular file without
 having a different log4j configuration packaged in the webapp.war
 archive. My first idea was to modify the log4j configuration so the
 webapp will log to the console (stdout) and then find a way to
 redirect the stdout inside a Tomcat instance to a particular file

 That sounds awful: a hack (in log4j config) to go to stdout and then
 another hack (in Tomcat config) to redirect to a file. Yuck.


It is not really a hack in log4j configuration to redirect the logs in
stdout, as it is exactly what does the ConsoleAppender by default...

The idea here is that we (the developpers) can focus on *what* get
logged by configuring the log categories and the log pattern in the
log4.properties file using a simple ConsoleAppender.

Our infrastructure team (responsible for the server configuration and
resources) can focus on *where* the logs go (a file, a rolling file, a
JMS queue, syslog, or whatever the need) in the Tomcat configuration.

This has the other advantage to have a log4.configuration file and a
web application that are not too much dependant of the environment
(Unix file path vs Windows file path for example)...

I guess this why the stdout / feature is available in Resin... At
least it would help in this use case !


 Is there a way to mimic this behaviour in Tomcat ?

 *Sigh* if you have to, you can use the swallowOutput attribute on
 your Context definition. Then you have to configure Tomcat's logging
 system to put the logs where you want them.

 That is fragile. It depends on who catches the value of System.out
 first, Tomcat or a logging framework.


 IMO a better idea would be to configure log4j properly. I think you
 have several options:

 1. Modify the log4j.properties file in each WAR file to specify
   the proper filename. You said you didn't want to do this.

 2. Use a log4j.properties file that is outside your WAR file.
   You'll have to figure out how to get your webapp to detect
   the right file so that your 3 separate copies don't end up
   reading the same file and reproducing the same issue described
   above.

 3. In your log4j startup code, set a property based upon some
   configuration or environment (context path?) that can be used
   by log4j during configuration and setup of the logging system.
   I personally favor this approach. If you are running in separate
   JVMs, I think you can use system properties and have those
   replaced by log4j when parsing the configuration file(s).
   Read the documentation to be sure.

 4. Configure log4j to log to syslog, and have syslog take care of
   the file situation. Of course, you'll have to identify each
   separate instance of your webapp if you want to be able to
   sort-out which log came from which source. So, you still
   have to somehow identify these webapps uniquely.


 5. Configure it to write ${catalina.base}/logs.

 (That is if all webapps are on different Tomcat instances, as opposed
 to having several different-named webapps on the same Tomcat)

 If you want that to be written to /var/logs, you can replace
 ${catalina.base}/logs with a symlink to /var/logs/instance-N/.

 Best regards,
 Konstantin Kolinko

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


Thank you for your ideas and advices, it will definitely help me a lot !

Regards,

Simon

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

Re: Logging per webapp per instance

[Leon Rosenberg]

Hello,

you can specify the logoutput as relative path:
instead of
log4j.appender.file.File=/var/log/webapp.log
to
log4j.appender.file.File=logs/webapp.log
and link the local file to the desired destination.

regards
Leon

On Mon, Dec 19, 2011 at 5:54 PM, Simon spyd...@gmail.com wrote:
 Hi,

 Our webapp is packaged with the log4j framework (1.2.16) and a log4j
 configuration that redirect all logs to a file on the server
 filesystem. This log file is rotated when it reaches 50M.

 Here is the configuration detail :

 log4j.rootLogger=INFO, file
 log4j.appender.file=org.apache.log4j.RollingFileAppender
 log4j.appender.file.File=/var/log/webapp.log
 log4j.appender.file.MaxFileSize=5KB
 log4j.appender.file.MaxBackupIndex=50
 log4j.appender.file.layout=org.apache.log4j.PatternLayout
 log4j.appender.file.layout.ConversionPattern=%d %-5p %c - %m%n

 This configuration file is located inside the webapp.war archive at
 /WEB-INF/classes/log4j.properties.

 In our production environment, we started with one tomcat instance and
 everything was fine. The tomcat version is 5.5.20 and it is running on
 the Oracle JVM 1.6.0_23-b05.


 Unfortunately, when the infrastructure team added 2 other Tomcat
 instances on the same server with the same webapp.war inside, some
 logs were lost. The 2 instances are basically a complete copy of the
 file tree of the first instance. Thus, there is 3 identical webapps
 logging into the same log file simultaneously :
 /tomcat/instance-1/webapps/webapp.war = /var/log/webapp.log
 /tomcat/instance-2/webapps/webapp.war = /var/log/webapp.log
 /tomcat/instance-3/webapps/webapp.war = /var/log/webapp.log

 My hypothesis is that as every webapp log to the same log file from a
 different JVM (the tomcat instances), there could be some concurrency
 issues when the rolling from log4j occurs !!!


 I would like that each webapp logs to a particular file without having
 a different log4j configuration packaged in the webapp.war archive. My
 first idea was to modify the log4j configuration so the webapp will
 log to the console (stdout) and then find a way to redirect the stdout
 inside a Tomcat instance to a particular file :
 /tomcat/instance-1/webapps/webapp.war = stdout = /var/log/webapp-1.log
 /tomcat/instance-2/webapps/webapp.war = stdout = /var/log/webapp-2.log
 /tomcat/instance-3/webapps/webapp.war = stdout = /var/log/webapp-3.log

 I know i could achieve that with the Resin application server through
 the use of the stdout / configuration element
 (http://caucho.com/resin-4.0/reference.xtp#stdoutlog,
 http://caucho.com/resin-4.0/admin/logging.xtp).

 Is there a way to mimic this behaviour in Tomcat ?

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


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