Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44859A71.4090302@ascert.com>
Date: Tue, 06 Jun 2006 16:08:33 +0100
From: Rob Walker <robw@ascert.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: Resource Bundles and logs
References: <0DB05D80FA028644A1E960E015FCD71C39A1B9@Mail3SM.ueic.com>
	 <200606011418.59295.niclas@hedhman.org> <1149177253.3686.24.camel@trout>
 <448539B5.6040604@ungoverned.org>
In-Reply-To: <448539B5.6040604@ungoverned.org>
Content-Type: multipart/alternative;
 boundary="------------080809070606060809080604"

--------------080809070606060809080604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> So, until then there is no way to "hide" these errors. Perhaps there 
> is another approach too. One thing that we could do (in addition to 
> eventually using the log service) is to have a property that allows us 
> to disable diagnostic messages...otherwise, I don't know.
In our app. this was our reasoning behind basing our logging on LOG4J - 
so we had very flexible "soft switches" to control and configured what 
got logged at runtime. I haven't looked at SLF4J yet - but I think it 
extends this concept further with a generic 'commons' style API that can 
also sit on top of other logging frameworks.

We did a not very good "hack" to enable us to wire LOG4J in as an Osgi 
service - so I can't really recommend the actual approach we took for 
general usage - but the outcome has been pretty good, and it's given us 
a degree of flexibility around the level of diagnostic and application 
message noise which gets logged.

In my mind, the model I envisaged that could be workable was:

    * a "logger" bundle that whilst supporting the standard OSGi
      LogService API for the very basic case, also offered a fairly rich
      LOG4J (maybe SLF4J now) set of API functionality

Needless to say, time prevented me from creating this generalised "split 
brain" logging module, but I think it's feasible and has merit.

And of course beyond this, there then opens up the possibility of remote 
log message or / logging access through things like JMX or simpler APIs  
(ours is actually a very simple XMLRPC based one that let's us pull back 
captured log messages for viewing on a client)

Just some thoughts ....

-- Rob

--------------080809070606060809080604--