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

[Libor Jelinek]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20121025/9d2a8981/attachment.html>