[slf4j-dev] discussion about LogService ranking in osgi-over-slf4j

[Christian Trutz]

Hi Libor,

I find that implementing the SLF4J LogService as OSGi ManagedService is
better than

- configuring service ranking via system property or
- bridging Equinox Log Service implementation to SLF4J

because:

1) as ManagedService you can change the configuration at runtime and switch
between multiple log services. An use case could be: a OSGi application
logs regurally with a "default" LogService (not SLF4J LogService) but you
want to switsch the log temporally because you want to see the log messages
in Beagle for example. With SLF4J as ManagedService you do not have to
shutdown and restart you application.

2) bridging Equinox Log Service can be also very confusing for users/admin
who don't know that osgi-over-slf4j has this feature ...

Anyway, I forked slf4j and I'm going to play around with LogService as
ManagedService ...

Christian


2012/10/25 Libor Jelinek <ljelinek at virtage.com>

> Hello Christian, Hi Matthew,
> yes we have very very long discussion exactly about it a month or two ago.
> Matthew is strictly against to these tweak with service ranking. I
> suggested to introduce a system property that will control this "dominante
> or not" behaviour which will default to not being dominate (not specifying
> service ranking) thus keeping backward compatibility with current
> osgi-over-slf4j.
>
> See my comments https://github.com/qos-ch/slf4j/pull/24 if you are
> interested.
>
> Becoming service manageable via ConfigAdmin is another option. IMHO maybe
> too much overkill for >>Simple<< Logging Facade 4 Java....
>
> About Eclipse-specific use: Also a month or two ago I suggested this patch
> https://github.com/bircow/slf4j/compare/acfb07...a20787. Actually Eclipse
> doesn't use any specific OSGi Log Service than adding 3-4 methods. So I
> implemented Equinox ExtendedLogService by inheriting from origin
> osgi-over-slf4j adding these specific methods.
>
> To cite my previous comments on this topic:
> *To idea to fork OOS and maintain autonomous Eclipse bridge: I'm rather
> against because *there is no actual difference*. Eclipse Platform log is
> logging to OSGi Log Service (to be specific to Equinox child of LogService
> named ExtendedLogService) under the covers. I've reimplemented
> ExtendedLogService that inherit from current OOS LogService impl, but
> adding a few of additional methods specific to ExtendedLogService only. You
> may review all my proposals at
> https://github.com/bircow/slf4j/compare/acfb07...a20787.
> ExtendedLogService
> impl draft is commit a20787. (Ignore commit specific to ease my OSGi
> development in Eclipse PDE tooling.)
>
> In summary, bridging Eclipse Platform log is are two new files that doesn't
> have impact to non-Equinox OSGi environments (depedency on Equinox is
> marked optional).*
>
> Unfortunatelly due to this difference of opinions among us, these
> enhancements toward more confortable Eclipse usage still waits. However I'm
> personally already using it in our own quite large Eclipse-based
> application with satisfaction. It do what it should do -- real
> single-target logging, i.e. every log message no matther whether produced
> by OSGi Log Service or Eclipse Platform Logger is bridged to SLF4J.
>
> --
> Hezky den / Have a nice day
> Libor JELÍNEK
>
> VIRTAGE SOFTWARE // software - design - web
> Lucni 542 // 285 04 Uhlirske Janovice // Czech Republic
> support: +420 315 555 488 // cell: +420 777 205 142
> email/jabber: ljelinek at virtage.com // web: www.virtage.com
>
> Visit our developer adventures at http://devblog.virtage.com!
>
>
>
> On Tue, Oct 23, 2012 at 8:05 PM, Christian Trutz <
> christian.trutz at belaso.de> wrote:
> > Hi osgi-over-slf4j developers,
> >
> > I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the
> SLF4J
> > LogService because
> > Equinox register also a LogService with default ranking 0. SLF4J gets
> also
> > ranking 0 (default ranking)
> > because no service ranking is explicitly set. Is it OK for you if I
> > introduce ranking = 10 for SLF4J LogService?
> > If want to commit following change:
> >
> >         Properties props = new Properties();
> >         props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService
> > implementation.");
> >         props.put(Constants.SERVICE_RANKING, 10);
> >         ServiceFactory factory = new LogServiceFactory();
> >         bundleContext.registerService(LogService.class.getName(),
> factory,
> > props);
> >
> > to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should
> > made log service ranking configurable ... (via system property for
> example).
> > With the above change, I can also see OSGi log messages in Beagle ;-)
> Thats
> > COOL ...
> >
> > Christian
> >
> > _______________________________________________
> > slf4j-dev mailing list
> > slf4j-dev at qos.ch
> > http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20121026/5de88db9/attachment.html>