tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "emerson cargnin" <>
Subject Re: Logging for Dummies in Tomcat 5.5/6.0
Date Wed, 13 Aug 2008 14:34:01 GMT
If I redirect log4j logs as described int he page below, is it not
adivisable to remove the console redirection to catalina.out?


On 20/06/2008, Mark Thomas <> wrote:
> 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
> > 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
> 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:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message