Hello Peter, My remark about race conditioning is based on the remarks in Neil Bartlett's OSGi book where he discusses getting a service reference then adding a listener (or doing it the other way round) and how it gets messy handling that, and that a service tracker's therefore much better. I can see therefore a possibility, even with buffering, even with a service tracker for getting the log reader, in between querying the reader for past log entries and registering the event handler for future log entries, where I'd have to deal with overlaps or gaps in the event history. And because in practice, things tend to crash a bit more at startup, it'd be a shame to miss a critical log event at startup if it occurred during such a gap (and I don't want to hack away and force start up order because it's not the OSGi way...).
A whiteboard or event admin would be nice. Felix's EventAdmin uses the log service IIRC (haven't tested that yet) so there'd be a feedback loop to watch out for. By the way Peter, as a relative newcomer to OSGi, just a quick thankyou for writing "bnd" :-) -- Christopher On 8 June 2011 14:46, Peter Kriens <[email protected]> wrote: > 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] > >
