-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
David Fisher wrote:
| All
| my contexts logs are hijacked by Roller, and that is a roller question
| that I can't ask due to my weird configuration. But if I understood
| better how logging and tomcat interact I could understand.
All of the logs are hijacked by roller, or only the one in which Roller
is actually deployed? If you moved Roller libraries (or the whole thing)
into Tomcat's lib directory, then you are probably making a mistake
(your other memory issues notwithstanding).
Tell me how you want your logs to act, and I'll try to give you a
configuration you can start with, and hopefully improve upon.
| My host context on Tomcat 4.1.31 looks like:
|
| <Host name="my.url.com" appBase="webapps-url" >
| <Valve className="org.apache.catalina.valves.AccessLogValve"
| directory="logs" prefix="my_url_access." suffix=".log"
| pattern="common"/>
| <Logger className="org.apache.catalina.logger.FileLogger"
| directory="logs" prefix="my_url_logger." suffix=".log"
| timestamp="true"/>
| </Host>
|
| In Tomcat 5.5.26:
|
| <Host name="my.url.com" appBase="webapps-unity" >
| <Valve
| className="org.apache.catalina.valves.FastCommonAccessLogValve"
| directory="logs" prefix="my_url_access."
| suffix=".log" pattern="common"/>
| </Host>
I don't believe that these two configurations do the same thing. Are you
asserting that they do, or that this was the best you could do? The
4.1.31 configuration does both access logging (like Apache httpd common
log formatting) plus a general logger for interesting things that happen
within the <Host> itself. Your 5.5 config only logs accesses.
| How do I translate my 4.1.31 Logger to log4j in Tomcat 5.5.25? How do I
| do the same for JULI logging? How do I combine the two?
I'm no expert in JULI, but I can tell you that my experience was log4j
was a bit confusing. I've been using log4j forever in my own
applications, so I figured that configuring commons-logging within
Tomcat to use log4j would be a breeze. It wasn't, unfortunately. I was
also trying to introduce commons-logging in my own applications for
whatever reason ;)
My first problem was that the commons-logging documentation seems to
indicate that the "best" logging system available would be chosen, and
gives a load order in which log4j is detected before using the juli
fallback. That appears to be true in the general sense, except that
commons-logging is set up /before/ any contexts are loaded. That means
that log4j needs to be in the server/shared/common lib directory in
order for it to be detected. I'm not a big fan of that, since I like to
use a clean Tomcat install so that upgrading isn't such a PITA.
So, the first thing I learned was that I needed the following:
1. log4j.jar in my webapp's WEB-INF/lib directory (duh)
2. log4j.properties (or XML or however you indend to init log4j) needs
~ to be in my webapp's WEB-INF/classes directory (duh)
3. commons-logging.jar
4. commons-logging.properties in my webapp's WEB-INF/classes directory
~ Mine looks like this:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
5. Use a ServletContextListener to shutdown commons-logging cleanly when
~ the context gets cleaned-up (details elsewhere for brevity).
This last point seems counter-intuitive given that a) commons-logging
says that it will look for log4j before falling-back on juli and b)
commons-logging has already been initialized, so why does it
automagically re-configure itself to work within the webapp? See below.
At this point, commons-logging should start emitting log messages to
your configured log4j log files. As indicated in another post, I'm using
DailyRollingFilAppender which will roll depending on the pattern you use
for the date in the filename, rather than strictly "daily", as the name
of the class might suggest.
| How does the classloader come into play? I know it has some affect
| because there is mention in the docs of tomcat/common/ vs. tomcat/shared/?
Yup. ClassLoaders are important because of the way they (duh) load
classes. Most ClassLoaders are implemented like this:
public Class loadClass(String className)
{
~ Class clazz = parentClassLoader.loadClass(className);
~ if(null == clazz)
~ clazz = this.actuallyLoadTheClass(className);
~ return clazz;
}
That is, the parent class loader is consulted first when loading
classes. The WebappClassLoader, in contrast (and specified in the
servlet spec) does this:
public Class loadClass(String className)
{
~ Class clazz = this.actuallyLoadTheClass(className);
~ if(null =-= clazz)
~ parentClassLoader.loadClass(className);
~ return clazz;
}
Note that it's behavior is exactly the opposite: libraries found in both
your webapp AND the Tomcat shared or common lib directories (which are
unified in TC 6, btw) will be loaded FROM YORU WEBAPP, not from the
parent classloader. This is actually to your advantage, since it allows
you to trump libraries loaded (directly) by Tomcat in your own webapp,
thus having much more control over your own application.
Now, back to logging. Since commons-logging.jar is in your own webapp, a
re-configuration occurs when your webapp is initialized (actually, it's
not re-configuration... the TC commons-logging instance has already been
configured.... it's just that your webapp's instance of commons-logging
is now being loaded and configured for the first time).
When you configure commons-logging for your own application (for me,
through log4j.properties), you can selectively log various classes and
log levels to different files. Here's my configuration for log4j in
development:
# hash marks indicate comments
log4j.rootCategory=INFO,A1
# A1 is the "appender", which is something that actually writes log
# statements to a file/whatever
log4j.appender.A1=org.apache.log4j.FileAppender
log4j.appender.A1.file = @app-log-dir@/log4j.log
log4j.appender.A1.layout = org.apache.log4j.PatternLayout
log4j.appender.A1.layout.conversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.A1.append = true
# Turn-up the logging level on our code.
log4j.category.[our base package name] = ALL
This configures a single appender (A1) that writes to a file. No rolling
or anything like that. Our code (identified by package on that last
line) emits 100% of the logging statements to our file. All other
classes (Tomcat, commons-digester, other libraries) are limited to INFO
and higher statements.
| Do the answers differ for Tomcat 6?
TC 5.5 and TC 6 are very similar, so I'm guessing that logging
configuration is very similar.
| Now do you see why we simple users who must spend time programming their
| apps, are confused? Especially when you go from having a VERY SIMPLE
| interface to options you don't care about but are forced to make. Like
| which health care plan?
What about following the directions in
http://tomcat.apache.org/tomcat-6.0-doc/logging.html? I haven't followed
them myself, but they are quite straightforward.
|
| This is critical to me, I ought to go to Tomcat 6 and Java 6 as I go to
| Apache / Tomcat (for load balancing, SSL front end and splitting parts
| of webapps between differently configured tomcats, I certainly don't
| want to waste time with logging configuration,
|
| Regards,
| Dave
|
|
|
|
|
| ---------------------------------------------------------------------
| To start a new topic, e-mail: users@tomcat.apache.org
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhWw8QACgkQ9CaO5/Lv0PB9bQCgnx4Fp1jSOHATDsTWi4/c5emr
AJgAoIWEWyp69wzXBg+IK8Pnfu5eQWve
=Lr7G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
