The log service is mandated to minimize the race condition with buffering ...
Using (not rewriting) the Log service was the original intention. It allows
many different
logs to work in parallel without burdening the users of the log. It is strongly
recommended to follow this approach.
The only regret I have is that we did not use the whiteboard for the log
readers ...
Kind regards,
Peter Kriens
On 8 jun 2011, at 08:28, Christopher BROWN wrote:
> Interesting idea... In that case, the default Felix Log Service should
> work for me (it's just a memory store IIRC). The only issue I can
> forsee is a theoretical brief period between retrieving the log reader
> service and querying entries/registering the listener where a race
> condition might occur (overlap/missed entries)
>
> Maybe also issues with asychronous logging (out of sequence) compared
> with other usages.
>
> Still, like the approach.
>
> --
> Christopher
>
>
>
> On Wednesday, 8 June 2011, Lucas Galfaso <[email protected]> wrote:
>> Just a note, even when the approach you are following to have a Log
>> Service implementation that uses SLF4J would work, the overall
>> strategy would be wrong. It is a cleaner implementation to keep the
>> existing Log Service and create a bundle that registers a LogListener
>> that sends the LogEntry to SLF4J.
>>
>> Regards,
>> Lucas
>>
>>
>>
>>
>> On Tue, Jun 7, 2011 at 5:07 PM, Richard S. Hall <[email protected]> wrote:
>>> On 6/7/11 15:52, Christopher BROWN wrote:
>>>>
>>>> Thanks Richard. I'd tried looking at the OSGi alliance, just saw docs
>>>> and specs... Anyway followed your advice, seems fine, so I'm assuming
>>>> all that remains to be done is to extract the org.osgi.service.log
>>>> classes from the JAR and rebuild the MANIFEST.MF to reflect the API
>>>> export and build my implementation.
>>>
>>> Just to be clear, the JAR file includes the source files too, so you can
>>> just copy them into your project if you want, not merely the classes.
>>>
>>> -> richard
>>>
>>>> Will get on with that now :-)
>>>>
>>>> --
>>>> Christopher
>>>>
>>>>
>>>>
>>>> On 7 June 2011 21:20, Richard S. Hall<[email protected]> wrote:
>>>>>
>>>>> On 6/7/11 15:09, Christopher BROWN wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I chose Felix to add embedded OSGi capabilities to an existing host
>>>>>> application, and am happy with that choice. The host application
>>>>>> already uses a logging framework (SLF4J with Logback Classic as the
>>>>>> bound implementation), so I exported the SLF4J API -- not the Logback
>>>>>> implementation -- using "system packages extra" and that's fine too.
>>>>>>
>>>>>> However, I'd like to provide an implementation of the standard OSGi
>>>>>> logging service APIs that delegates logging to SLF4J so that I can
>>>>>> hide that implementation choice a bit more. The felix logging
>>>>>> implementation bundle includes both the API and the Felix
>>>>>> implementation.
>>>>>>
>>>>>> My question is: where can I get the logging API without the Felix
>>>>>> implementation? I'd like to get it from the same source as Felix,
>>>>>> without having to hack at the Felix bundle to strip out the
>>>>>> implementation that isn't necessary in my situation.
>>>>>
>>>>> Just download the org.osgi.compendium JAR file from the Maven repo, it
>>>>> contains the source code as well as the class files.
>>>>>
>>>>> You can also get it directly from the OSGi Alliance.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> Thanks,
>>>>>> Christopher
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
