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@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@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@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev