If you read the proposed spec, they won't tie to SLF4J. OSGi will have
an own set of classes (as already they have) with methods and factories
*based* on the style existent in SLF4J and will not use slf4j-api.
The https://github.com/osgi/slf4j-osgi
<https://github.com/osgi/slf4j-osgi> is aimed to be just a binding
implementation for those projects that uses slf4j's static binding, but
it will redirect all log entries to new osgi services... you can build
you own too :)
I'm one of those that would use DS-managed Loggers for new projects when
creating service classes... but I'll still use the static logger for
non-service classes.
On 19/04/2017 21:23, Matt Sicker wrote:
I'm not a fan of tying the logging service to SLF4J. See our FAQ entry
for comparison with Log4j 2.x:
<https://logging.apache.org/log4j/2.x/faq.html#api-tradeoffs>. Really,
I don't think OSGi should be defining a logging API, but instead
should be providing a vendor-neutral service to activate whatever
backend is desired by the user. I can't imagine that many users will
switch to DS-managed Loggers instead of obtaining them the same exact
way they've always gotten them: LoggerFactory or LogManager.
On 19 April 2017 at 14:59, Cristiano Gavião <cvgav...@gmail.com
<mailto:cvgav...@gmail.com>> wrote:
Hello BJ, finally I had a time to look into this.
On 06/04/2017 15:58, BJ Hargrave wrote:
Also see https://github.com/osgi/slf4j-osgi
<https://github.com/osgi/slf4j-osgi> which holds an slf4j binding
to the new Log Service.
I looked into this code, butI just read here
https://www.slf4j.org/codes.html#loggerNameMismatch
<https://www.slf4j.org/codes.html#loggerNameMismatch> that static
binding is deprecated.
From the next version of SLF4J (1.8.x) forward they are going to
use poor java's ServiceLoader
<https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html>
mechanism. :(
It is indeed a service. The spec writing for these changes are
not in the draft spec so you can see
https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
<https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf>
for some more detail/background on the change.
I liked it a lot !
One question about Logger Admin and Logger Context.
I'm wondering... How would be they behaviour when used with scoped
Subsystems(composite/application)?
how would be the best approach in order to create an exclusive
root context for each isolated hierarchy ? one instance of Logger
Admin for each scoped subsystem?
best,
Cristiano
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
--
Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
