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.
