Christofer, Mark and others,
I have read, collected, and will re-read, the answers I got this time.
I appreciate them, because they are informative, and you took the time
and pain to answer this in a way I can (at least in part) understand.
Other people, in various ways, made the point better than I did, that
there is a difference between a place where there are enough sysadmins
that one or two can dedicate themselves to Java logging, and enough Java
programmers to fall back to in case of problems, and where all web
applications are written in heaven according to strict rules, and a
place like the one I work at, which is anything but.
A bit like the old joke with the demo hell and the real one.
From the mail I am seeing, on and off-list, I gather that this is an
exercise worth doing, not only for myself.
I understand (now) the point made about the difference between
Tomcat logging and the application's logging. The Apache/PHP comparison
of Christopher was very informative.
In my opinion, this point is not made clearly enough in the Tomcat
logging documentation.
There are also some items in that respect that are confusing in the
documentation and in the properties file, because they seem to indicate
the opposite. That is, to me and now, and maybe a bit more information
will clear up the confusion.
In my naiveté, I thought that Commons Logging meant : provide a single
interface to applications for logging (a bit like system.out), and
decide outside of the application what underlying system this uses and
where it goes. (Maybe it is that, but that point then I haven't gotten
clearly yet). I also thought or hoped, this being in the realm of
Java's object-oriented and inheritance nature, that it worked like class
inheritance. Don't find the method here? go one level up, that kind of
thing.
But, unless I am mistaken again, it looks like my hope of channeling all
webapps, no matter where they came from, into writing their logs into
"my" logfile, using "my" "main" logging.properties file that I
understand, is forlorn. Or is it not, or not entirely ?
Now, I would like to quote in extenso the last post from Christopher,
and make some comments about what I think is clear or not.
Not that this would be misinterpreted, I am just using some levity below
not in a sarcastic way, but to express what I think a Tomcat and webapp
mere installer like me can be expected to know or not.
Start quote
I'd like to point out that when you are configuring logging for Tomcat,
you're configuring /logging for Tomcat/, not for your applications. Yes,
Tomcat does perform some logging on behalf of the application (things
like auto-redeployment notices, webapp startup info, libraries loading,
etc.) but Tomcat does not dictate any of the application-specific logs
that you create.
++
Very clear now, and wasn't so clear before.
Not nitpicking, but I'd like to point out that I don't create the logs,
its the applications that done it. I just see the logfiles popping up,
I don't know what is in the applications to make these logfiles pop up
and I mostly cannot look inside.
++
I'll give you an analogy with Apache httpd and maybe you can see what I
mean.
Let's say you have a PHP-based application running on Apache httpd. In
httpd.conf, you have something like
AccessLog /var/log/apache/access.log common
This will log all HTTP accesses to the access.log file. Simple.
On the other hand, your application may maintain its own log file in
/var/log/myphpapp/errors.log. In that case, there is no way at all for
an administrator to configure logging for your application using httpd.conf.
++
True, very clear, and understand the parallel with Tomcat apps, now.
But this is not clear at all when reading the Tomcat on-line docs, and I
think that alone creates a lot of confusion.
++
The same is true for configuring application versus server logging in
TC: logging.properties (and friends) configure the logging for the
application server, and the application is free to do whatever it wants
for application-specific logging.
++
From an administrator's point of view, that's a pity, in my opinion.
But I don't know how to summarise correctly why I believe it's a pity,
so I'll leave that for later.
++
I think this logging issue is really big for folks moving from servers
like httpd where logging is typically very simple (log errors or
accesses, etc.).
++
True, and that is what we sysadmins are longing for. But we do not
receive Tomcat that way, so we have to figure out if it is possible to
make it be that way.
++
For those of us who have used Java-based logging
systems in the past, this is a piece of cake.
++
I believe you. But for those of us who have not spent years using Java
logging, it isn't a piece of cake, hence my plea.
Have you ever seen the Rosetta Stone ? That's the tablet that allowed
Champollion to start deciphering Egyptians hieroglyphs. Of course, that
was only because he already knew egyptian demotic and classical greek,
and could derive from these two what the other squiggles meant.
When I look at logging.properties, it looks to me like the Rosetta Stone
does : I'm sure there is a profound meaning, but not quite sure what it
is, because I lack the underlying knowledge that you have as an
experienced Java programmer. However, I still have to organise this
logging business on that server.
++
For instance, I have used log4j for years and years.
++
There is the difference...
++
log4j requires a
log4j.properties file (or you can do it programmatically, but that
sucks) for configuration. It's pretty simple: you define an appender
(basically a message log target), give it a file name and a log level
and then, in your code, you simply write to it. That's it.
++
Ok. Now, I don't have the code, and I'm not writing any. I would not
know an appender if my nose was on it. I understand file name and log
level though.
Also, I thought we were talking about logging.properties, not
log4j.properties.
++
The complexity comes in when you want multiple appenders at different
levels and you want different parts of your code (say, all org.apache.*
stuff goes to one logger and com.mycompany.* goes to another). It's not
really any harder to understand... it's just more of the same kind of
configuration. And, the plus side is that your code doesn't get any more
complex.
++
I believe all what you say there. It's just that I'm not really writing
Java code, so much of the beauty of it at that level undoubtedly escapes
me. But you realise that you are writing from the point of view of a
Java programmer, yes ?
++
Since each application can be configured differently (from inside the
application, that is), you have to ignore them when you're talking about
server logging.
++
I wish I could, but to me there is just a bunch of logfiles appearing
out of nowehere, and I would like to clean it up. And at this stage, I
don't know yet if some common Tomcat file has something to do with all
of them, or if each one has its own set of parameters.
++
TC simply isn't going to say "hey, webappX, your log
file is /here/". The application itself makes that decision.
++
Again, a pity. Who's the boss here, for Chuck's sake ?
But also, in part that does not seem to be entirely true.
In "my" logging.properties file, there definitely seem to be lines that
"tell" some applications where to log. But maybe you are still talking
about log4j here. More below.
++
Configuring Tomcat logging is usually easy: if you accept the default
configuration, you get catalina.out (stdout), plus some daily-rolled
files that are all defined in logging.properties.
++
Ok so far. We're back to logging.properties.
But I am confused again : if they are all defined in logging.properties,
then it means that I, as a sysadmin, can tell them to go log somewhere
else, independently of what the webapp says, no ? Oh, but it's not sure
that they all read logging.properties maybe ?
++
The logging.properties
file contains configuration and documentation that are helpful if you're
willing to read through it and connect point A (the named logger like
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/webappname])
to the configured logger that includes a filename.
The stock logging.properties contains configuration for, say, the
'manager' application. Want to create a new logger for your new
application? Simply copy that configuration and modify the appropriate
parts (one of them being the name of the logger itself, which is
3manager.org.apache.juli.FileHandler for me, and could probably have
been given a more pronounceable name, but captures exactly what that
logger is for).
++
Ok, good to know. But do I *have* to copy that section and create a new
one for each webapp, or can I re-use an existing one and send the output
of the new webapp there also ? And what happens if I just remove the
"manager" lines ? will it then start logging in the same file as
catalina, or will it not log at all anymore ? or will that prevent the
Manager (or Tomcat) from starting up ?
Somewhere in the middle there, you've lost me, and my eyes have turned
all glassy.
I have found this logging.properties file, because something somewhere
told me it was important. Why it was where it is, or if the one I found
is really the one Tomcat uses, and if the Manager uses it also, I have
no real clue yet, and that is one of the things I am hoping to learn.
Mine seems to be in /usr/share/tomcat5.5/conf/
(Yes, a Debian package, tsss)
++
I hope that helps a bit more.
++
Yes, it did, up to the point indicated above.
But as soon as you started mixing up aspects of Java programming with
aspects of configuration, there it was less helpful, because I do not
have the same background so there are things I cannot follow nor appreciate.
end quote
The on-line logging documentation as it stands now, is a bit the same
way. I guess inevitably so, since it is written by experienced Java
programmers, who unwittingly pre-suppose on the part of the user quite a
Java logging background.
That helps a section of the Tomcat users, and it avoids boring them with
repetitions or low-level explanations.
But it leaves holes for people like me, because after every 2 sentences
easy to read and understand, there is suddenly something for which we do
not have the right background, or there is a reference to a more obscure
document somewhere else (the Commons Logging pages, not to name them.
Those are really for Java programmers).
I'll make a small disgression here to explain again what I mean.
The 5th word of the first line of the Tomcat 5.5 Logging on-line
documentation page is a link to Commons Logging.
I followed this link and read the first paragraph of the first page of
Commons Logging.
That left me totally confused as to whether Tomcat uses or not Commons
Logging, as to whether it is the webapps or the libraries they use or
both that choose the underlying logging mechanism (log4j or Juli e.g.),
and whether or not this choice is determined in the code of the webapp
or library, or by some external configuration file like the Tomcat main
logging.properties file. This paragraph seems to say all of these
apparently contradictory things in one same breath.
It is also possible that for an experienced Java programmer this really
makes sense; or it is possible that for an experienced Java programmer
this does not make sense either, but being experienced, he knows what to
take and what to leave.
End of disgression.
Anyway, that documentation is done by someone else, and in principle not
for the same public. So if we can just clear up the Tomcat side, we
dummies might not even need it.
Assuming that my basic purpose was to simplify the logging I inherited,
I would like to know if I can "make" a few applications write less
detailed logs, and write them all to the same file, or just a couple.
For that I guess that the first step is to know for sure which logging
mechanism "my" Tomcat is using, and how to be sure that the
logging.properties file I am looking at, is really the one used by
Tomcat (5.5).
So where do I start looking for that ?
The on-line documentation here
http://tomcat.apache.org/tomcat-5.5-doc/logging.html
states that the default is java.util.logging. But how do I know if "my"
Tomcat follows the default or not ?
I'll quote the last part of the first paragraph of the same on-line
documentation :
[...]
Instead, the default Tomcat configuration will use java.util.logging. If
the developer wishes to collect detailed internal Tomcat logging (i.e
what is happening within the Tomcat engine), then they should configure
a logging system such as java.util.logging or log4j as detailed next.
This is followed by a log4j section, itself followed by a
java.util.logging section.
Would this not be less confusing :
[...]
Instead, the default Tomcat configuration will use java.util.logging,
explained in the next section.
If the developer wishes to collect more detailed internal Tomcat logging
(i.e what is happening within the Tomcat engine), then they should adapt
the configuration of the default java.util.logging, or use and configure
another logging system such as log4j, as detailed further on.
Followed by the java.util.logging section (since it is the default), and
then the log4j section (since it is not the default).
So now let's say that we start with the java.util.logging section.
The first line says that it is indeed what is used, but calls it JDK
logging.
The second line says that it is too limited to be useful, and that
Tomcat replaces it by something else called JULI.
Then it goes on to say that JULI is enabled by default.
Now this seems to contradict the beginning of this page, that says that
java.util.logging is the default.
(Now I'm probably playing a bit stupid here, but that is what it seems
to say, unless one is to understand that it is only a small part of
java.util.logging that Tomcat replaces by JULI, and that is why the
configuration is similar, but not quite).
I would propose a replacement for this paragraph, but I do not feel
qualified enough to write this correctly. I do not know for example if
JULI is a slightly modified copy which replaces java.util.logging
completely, or if just one class is added or replaced, or how to phrase
this in terms that are both Java-correct and understandable by a
beginner who needs this documentation.
(The not-beginners don't need it, since for them it's a piece of cake)
And should we then also go back to the first paragraph, and replace all
the mentions of java.util.logging by JULI ? Something like :
The default logging implementation in Tomcat 5.5 is JULI. JULI is a
slightly modified version of java.util.logging, as explained in more
details below. Etc..
I'll stop here for now, and ask someone more qualified to comment.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
