Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of jak-tomcat-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: users@tomcat.apache.org
From: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: per-webapp logging problem with Tomcat 5.5
Date: Mon, 27 Feb 2006 13:13:58 +0100
Lines: 55
Message-ID: <dtuqe5$3ml$1@sea.gmane.org>
References: <dtuc0r$n2l$1@sea.gmane.org> <13115.1141037201@www028.gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
In-Reply-To: <13115.1141037201@www028.gmx.net>
Sender: news <news@sea.gmane.org>

Boris Unckel wrote:

> You want to have a _one_ central place for your log configuration _and_ the
> correct logging just for that application - currently impossible.

I would not necessarely say that logging has to be configured in one 
central place/file, but I think putting logging config _into_ the 
applications is a bad idea.

Let me elaborate why:

The idea of a webapp is that you can deploy it on any spec-conforming 
server without changes (to the webapp). Thus, good webapps need to stay 
independant of specific implementations.

As "Juli" is very Tomcat-specific, placing logging.properties into the 
webapp would create a dependancy to Tomcat 5.5 (for example ruling out 
Tomcat 5.0 as a possible container for the same Servlet 2.4 app).

Furthermore, webapps should not (must not?) refer to files outside of 
their webapp directory, so refering to ${catalina.base}/logs is really 
bad practise (actually I'm surprised that it works). How can a webapp 
know that their container has got that environment variable, and I can 
it know that it points to a directory which contains a directory called 
"logs"?

logging.properties also contains the log levels, something that is 
usually container instance specific. For example, production 
environments have different logging requirements than integration or 
development environments, even if they use the same container 
implementation. Would logging.properties be inside the application, 
you'd have to customize log levels for each deployment. I don't know if 
the widely used Eclipse/Web Tools Project combinations even allows for 
automatic customizations during deployment. Surely you could write 
complicated Ant scripts for deployment, but that's cumbersome and 
old-school.

Thanks for your explanation about why real per-webapp logging is 
currently not possible with Tomcat 5.5 and Juli/java.util.logging. Is it 
the same with Log4J?

Personally I feel this is a big regression from Tomcat 5.0/4.1: With the 
swallowOutput option, it was possible to do per-webapp logging _and_ 
"logging configuration outside of webapp" quite easily. I know 
swallowOutput was just a hack for lazy System.out.println() coders, but 
it had the nice side-effect of solving the problem very elegant and 
efficiently. And there was nothing wrong with the option, just with the 
habit of the lazy coders.

As far as I know, swallowOutput is not there any more. Could it be 
re-activated? Is there anything else planned to support per-webapp logging?

Regards,

Andreas


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