Skip to Content.
Sympa Menu

shibboleth-dev - Re: Configuring logging in java components

Subject: Shibboleth Developers

List archive

Re: Configuring logging in java components


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: Configuring logging in java components
  • Date: Wed, 7 Feb 2007 10:01:31 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WoTE6+VNWzljDd3lHf2beznSzPHIshIljh7Z6r5asn3dZzVe3blWVqg8Fi8Rqz7jlN/Eq04qU8V7WJdfcq31Mo6U+FWfUWBTltMAMVfrp9exiNAy6LLmLWJ6MJyub96qVvN9fNyLRHOg/rGJGtHpvwTyfVePsUFTfvxYnADBqWg=

On 2/6/07, Chad La Joie
<>
wrote:

1. Using the ErrorLog/TransactionLog elements which configures log4j in
a programmatic manner. This does not allow for logging information from
third-party code (extensions) or changing things like the conversion
pattern (the string that tells Log4J how to form it's logging messages).

Extension logging would be good, yes.

2. Using a Log4J configuration file which some people find to be
confusing and difficult to configure.

Log4j config files are most confusing, I agree.

Currently I am trying to decide how best to approach configuring logging
in 2.0. I am currently leaning towards dropping IdP config file based
configuration in favor of deployers working with their container, in
whatever manner is appropriate for that container.

How would this address the logging needs of command-line tools? It
would be good if API calls to the Shib code base were logged, I think.
In fact, the project we're working on right now doesn't require a
container at all.

Thanks,
Tom



Archive powered by MHonArc 2.6.16.

Top of Page