felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Log Service Implementation
Date Mon, 01 May 2006 16:15:10 GMT
Excellent description...thanks a lot. We should let this gestate for a 
while and then we will take action on it.

Thanks again and keep contributing! :-)

-> richard

Dale Peakall wrote:
> Richard S. Hall wrote:
>> Dale Peakall wrote:
>>> Richard S. Hall wrote:
>>>> Dale Peakall wrote:
>>>>> I have a log service implementation that I'd like to donate.  How 
>>>>> should I go about this?
>>>> Thanks for the interest.
>>>> I guess first of all, give us a link so that people can take a look 
>>>> at it. Then after that we can call a vote on accepting it or not. 
>>>> Then we would have to deal with the software grant paperwork, etc.
>>> I've uploaded the source files to http://www.peakall.com/osgi/
>>> I've included the raw source files, a zip that's ready to be 
>>> unpacked into a felix source tree (the top-level POM will need to be 
>>> updated to include the sub-project), and a pre-built bundle.
>> Well, that is an excellent start! :-)
>> Is there any general docs or information about your implementation? 
>> Is it a quick and dirty type of implementation or does it leverage 
>> another logging system? Perhaps you could say a few words about it?
>> Thanks a lot.
> The service provides a simple, in-memory log that is not persisted 
> over framework restarts.  Most of the interesting work is performed by 
> the Log.java class - which:
> a) Maintains a linked list of log entry objects;
> b) Is responsible for calling any registered log listeners.
> As recommended in the compendium, the raw exceptions that are logged 
> are not stored directly, but as instances of an implementation 
> specific class (the LogException.java class).  The only exception to 
> this that I've chosen to implement is for exception classes from the 
> "java" package that don't contain embedded exceptions as these should 
> not prevent memory being reclaimed when the bundle that originally 
> created the exception is unloaded.
> Two properties are used to configure the service:
> * org.apache.felix.log.maxSize - specifies the maximum number of log 
> entries to store in the historic log.
> * org.apache.felix.log.storeDebug - specifies whether or not to store 
> entries logged at debug level.
> As I understand it, the design of the API (see section 101 of the 
> service compendium) is such that interfacing to other logging systems 
> (for outputting log messages to disk etc) should be performed by log 
> listener implementations.
> Dale Peakall.

View raw message