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> 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 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 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 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 > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Matt Sicker <boa...@gmail.com>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
