André Warnier wrote:
To attempt a summary of the discussions so far, it sems that there are
two distinct groups : Tomcat developers, and Tomcat users,
There might be two lists but I don't think it is quite that simple. The
standard ASF definitions can be found here
http://www.apache.org/foundation/how-it-works.html#roles
The developers seem to be happy with the logging and its documentation
as it is, and consider it clear, or at least accessible. The users, as
far as I can tell from the correspondence I receive, generally have a
different opinion.
This is less a user/developer(actually committer in ASF terms) issue and
more one how complex your environment is. For the simple environments, the
Tomcat 4 appeared to be fine although often there were some nasty memory
leaks hiding in the background. For the complex ones there was a world of
pain trying to get logging configured. There were often instances of the
logs for webapp A being logged to webapp B. The root causes of this were
many. Take a look at the dev archive and/or Bugzilla if you want more info.
I believe that the difference of opinions rests basically on the
following : at some point in time, the developers of Tomcat - who it
should be remembered do this for free - decided that maintaining
Tomcat's own logging mechanism wasn't really worth their time and
efforts, considering that there existed already a couple of external
libraries (packages?) which did the job better anyway.
This is not correct. I encourage you to read the code, or at least the
build.properties.default file, before making such assertions. TC4 to TC6
all use commons logging.
They thus split
that part off, allowing them to concentrate on more interesting and
rewarding parts of the code.
Also not true. The TC4 logging simply wasn't up to the job. See above.
And they have no intention of moving back.
Absolutely. You are not goign to find any committer prepared to replace a
working logging system with a broken one.
Them being the developers of a product offered free of charge, nobody
can or should discuss their decision or blame them for it.
Anyone is free to join the developers list and discuss ways of improving
the code. It helps a lot if you are prepared to roll up your sleeves and
contribution bug reports, test cases or patches (to code or documentation).
What I personally believe they forgot at that point, is that there are
many users of Tomcat who are not pure Java or Tomcat developers; that
these users, having acquired over time a reasonable understanding of how
to use Tomcat - if not necessarily how it works inside - now suddenly
are faced with the need to get acquainted with a whole bunch of things
of which they do not have a clue (commons-logging, juli, log4j), which
per se do not really interest them (because they are not mainly Java
developers) and which by themselves require quite an investment in time
in order to start understanding how they work.
In this case bits needed to be replaced so it actually worked. Along the
way the configuration process was changed. Given the choice between the old
and the new, I'd take the implementation that actually works every time.
<snip/>
I don't think I need to continue. Mere Tomcat users will understand
what I mean, and Tomcat developers can imagine what the average bloke
using Tomcat occasionally, thinks when he stumbles upon this.
(And yes, it is from a particular packaging of Tomcat, but that's not
the point here; the official one is not simpler).
Different people will have different views on the simplicity of the
logging. If all you want to do is make a small change I don't think there
is much difference. If you want to understand it, TC4 looks simpler but the
class-loading complexities which are not at all obvious at first glance (or
after several hours pouring over the code) will come back to bite you when
you think you understand what is going on.
Now above I am playing somewhat dumb, because since this thread started,
I have already started to understand some aspects of the above.
But even with this increased understanding, my basic feeling about it
remains that it looks like a gigantic overkill and waste of time
compared to the needs - and time available for this - of most Tomcat users.
To look at it another way, by making this change, and for most simple
cases, one has replaced 3 lines inserted in server.xml or context.xml,
by hundreds of lines "all over the place" (I am counting the docs,
because they are needed now, and they were not before).
I can imagine on the other hand that for developers this might be an
immense improvement, but again that's not the point here.
You need to get it out of your head the this was done for the benefit of
anyone but the users. The changes were made for the benefit of users so
that we had a logging system that worked.
I will continue to study it of course, because I have no choice if I
want to twiddle ever so slightly with the logfiles and not bring down my
production servers. And I will end up understanding it, because I don't
give up easily, as you may have noticed.
Great. Patches to improve the existing documentation are always welcome.
I would however like to ask a final question, or maybe make a suggestion :
Is it not possible for the Tomcat developers to take into account the
needs of people like me, who have only a minimal understanding of the
underlying beauties and refinements, but who nevertheless appreciate
Tomcat very much as a tool, and to take a step back in our direction and
make us really impressed and happy ?
Enhancement requests should be added to Bugzilla. Requests with patches
tend to go looked at much faster than requests without.
It should be a technical piece of cake for programmers of your capacity,
to continue to use commons-logging, juli, log4j or whatever you prefer
as the underlying mechanism, and to make it directly available for
people who want to get down to the gritty details, while providing the
average user with an interface that hides away this complexity under a
simple connecting element. Like for example this :
<Logger className="org.apache.juli.FileHandler"
directory="logs" prefix="localhost." suffix=".log"
timestamp="yyyy-mm" rotate="true" level="FINE"/>
You can then tuck away the real underlying properties files wherever the
system packagers won't find them, or even embed them in the code itself
to make sure.
I wouldn't link the <Logger /> elements to properties files, I'd just add
the requested loggers. But that is an implementation detail. The idea looks
possible at first reading but bear in mind I haven't looked at the code to
determine if it really is possible.
If you or any one else wants to start looking at coding this, I'll happily
point them in right direction. Yes there will be a learning curve, but it
shouldn't be that bad.
Understand me well : I am not harking back to the old times when life
was simple, and I understand that Tomcat has gotten more complex and
requires a correspondingly more powerful logging mechanism.
But I believe that the ultimate beauty of a complex piece of machinery,
is when it can be presented as something so simple and neat that a child
could use it. I think of that each time I see my son play with his
iPod, or my mother with her GPS car navigator.
To re-iterate what has been said on this and other lists many times before.
This is a community. We may have different roles but there isn't the them
and us you see in a commercial supplier/customer relationship. The lines
are far more blurred than that. If you want to see change then you have all
the power you need to make it happen and the most effective way to make
that change happen is to roll up your sleeves and start contributing. There
will always be room for improvement and people are free to scratch whatever
their particular itch is. Yours appears to be logging so I look forward to
seeing proposed changes to the docs and/or the code.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
