Log Service Implementation

[Dale Peakall <da...@peakall.com>]

I have a log service implementation that I'd like to donate.  How should 
I go about this?

Thanks.

Dale Peakall.

Re: Log Service Implementation

[Alex Karasulu <ao...@bellsouth.net>]

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.
Create a JIRA new feature issue and attach your code to the JIRA using 
the attachments feature.

Alex

Re: Log Service Implementation

[Dale Peakall <d....@oclcpica.org>]

Richard S. Hall wrote:
> Dale,
>
> I am planning on calling a vote on your log service contribution 
> tomorrow. 
Sorry, I've been away on holiday.
> Before I do, I wanted to ask you if there are any licensing/IP issues 
> we should be aware of and you are free to contribute the work?
No, the implementation was written by me and has no external dependencies.
>
> Looking at the source, it looks completely self-contained, but I want 
> to make sure before going forward.
>
> Have you submitted any paperwork to Apache (e.g., ICLA, CCLA, or 
> Software Grant)? Not a problem, since we can do this after the vote...
>
I've not submitted any paperwork yet.
> Thanks.
>
> -> richard
>
>
> 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.
>>
>> Dale Peakall.
>>
>>


-- 
Dale Peakall.
Senior Developer · OCLC PICA Ltd
Brincliffe House · 861 Ecclesall Road · Sheffield S11 7AE · United Kingdom
t +44-(0)114-281 64 68 · f +44-(0)114-281 60 41 
e d.peakall@oclcpica.org · w www.oclcpica.org

Re: Log Service Implementation

["Richard S. Hall" <he...@ungoverned.org>]

Dale,

I am planning on calling a vote on your log service contribution 
tomorrow. Before I do, I wanted to ask you if there are any licensing/IP 
issues we should be aware of and you are free to contribute the work?

Looking at the source, it looks completely self-contained, but I want to 
make sure before going forward.

Have you submitted any paperwork to Apache (e.g., ICLA, CCLA, or 
Software Grant)? Not a problem, since we can do this after the vote...

Thanks.

-> richard


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.
>
> Dale Peakall.
>
>

Re: Log Service Implementation

["Richard S. Hall" <he...@ungoverned.org>]

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.
>
>

Re: Log Service Implementation

[Dale Peakall <da...@peakall.com>]

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.

Re: Log Service Implementation

[Ceki Gülcü <ce...@qos.ch>]

Hello Alex,

Ooops. Sorry for not replying earlier.

Adding OSGi support is on my todo list. However, my current knowledge of 
OSGi is only theoretical, so I'd need to experiment with an OSGi container 
to test any logging service implementation SLF4J might offer.

I know that is quite non-committal, but does it sound acceptable to you? 
How urgent/important is OSGi logging service to you?

At 07:23 PM 5/1/2006, Alex Karasulu 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?
>
>Hey let's also talk to Ceki about SLF4J based logging service 
>implementations.  He's been a great help to us over at Directory.
>Alex

-- 
Ceki Gülcü
http://ceki.blogspot.com/

Re: Log Service Implementation

[Timothy Bennett <ti...@gmail.com>]

On 5/9/06, Timothy Bennett <ti...@gmail.com> wrote:

>
>  Niclas and his crew over at www.ops4j.org have been doing some
> development of a comprehensive OSGi logging implementation with their
> pax-logging project.
>

More specifically...

http://lists.ops4j.org/pipermail/general/2006q2/000640.html

Re: Log Service Implementation

[Rob Walker <ro...@ascert.com>]

>
>
> FYI...
>
> Niclas and his crew over at www.ops4j.org have been doing some 
> development
> of a comprehensive OSGi logging implementation with their pax-logging
> project.

Interesting - thanks, I'll check it out when I get a chance

-- Rob

Re: Log Service Implementation

[Timothy Bennett <ti...@gmail.com>]

On 5/9/06, Rob Walker <ro...@ascert.com> wrote:
>
>
> The problem we had here was that the OSGi service is so minimal as to be
> almost useless in a real application context - except perhaps just as a
> bootstrapping layer for really basic startup/framework related logging.
> Haven't looked at SLF4J - we're still just a basic LOG4J user on what is
> probably quite an old version by now. Even with very very basic wiring,
> that turned out way better than the standard LogService though - all we
> really created was create:
>
> - a way for bundles to register their own log hierarchies, which they
> could even then configure or have a default set of application-wide
> config settings applied
> - provide a Listener registration approach to allow local bundles to
> register to receive LOG4J events (using pretty standard approach as I
> recall, although it's a long time ago)
> - provide an XMLRPC method for clients to register and pull back
> "categories" of message they are interested in (categories being used in
> the standard LOG4J sense)


FYI...

Niclas and his crew over at www.ops4j.org have been doing some development
of a comprehensive OSGi logging implementation with their pax-logging
project.

Re: Log Service Implementation

[Rob Walker <ro...@ascert.com>]

> Adding OSGi support is on my todo list. However, my current knowledge 
> of OSGi is only theoretical, so I'd need to experiment with an OSGi 
> container to test any logging service implementation SLF4J might offer.
>
> I know that is quite non-committal, but does it sound acceptable to 
> you? How urgent/important is OSGi logging service to you?
>
A long time back we did a quick and dirty LogService impl which I think 
is probably still in OBR.

The problem we had here was that the OSGi service is so minimal as to be 
almost useless in a real application context - except perhaps just as a 
bootstrapping layer for really basic startup/framework related logging. 
Haven't looked at SLF4J - we're still just a basic LOG4J user on what is 
probably quite an old version by now. Even with very very basic wiring, 
that turned out way better than the standard LogService though - all we 
really created was create:

- a way for bundles to register their own log hierarchies, which they 
could even then configure or have a default set of application-wide 
config settings applied
- provide a Listener registration approach to allow local bundles to 
register to receive LOG4J events (using pretty standard approach as I 
recall, although it's a long time ago)
- provide an XMLRPC method for clients to register and pull back 
"categories" of message they are interested in (categories being used in 
the standard LOG4J sense)

The point I'm sort of driving to here is that without some extra 
thougt/plumbing - I don't think you can really build a real app's loging 
on top of just the OSGi standard service alone. It doesn't offer enough 
features like config granularity of what gets logged, partitioning of 
bundles to either use common or separated logging configs/hierarchies, 
facilties for local and remote logging clients to pull log events (or 
have them pushed)

-- Rob

Re: Log Service Implementation

[Alex Karasulu <ao...@bellsouth.net>]

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?

Hey let's also talk to Ceki about SLF4J based logging service 
implementations.  He's been a great help to us over at Directory. 

Alex

Re: Log Service Implementation

["Richard S. Hall" <he...@ungoverned.org>]

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.

-> richard

Re: Log Service Implementation

[Dale Peakall <da...@peakall.com>]

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.

Dale Peakall.

Re: Log Service Implementation

["Richard S. Hall" <he...@ungoverned.org>]

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.

-> richard