Community
Participate
Working Groups
The class Logger is used multiple times in the platform code and lists lots of friends. org.eclipse.e4.core.services.log; x-friends:="org.eclipse.e4.ui.bindings, org.eclipse.e4.ui.services, org.eclipse.e4.ui.workbench, org.eclipse.e4.ui.workbench.renderers.swt, org.eclipse.e4.ui.workbench.swt, org.eclipse.ui.workbench", I suggest we release it as API.
Alexander, you are our logging expert. WDYT?
Yes, I have logging expertize since this is typical for my region :) As for org.eclipse.e4.core.services.log.Logger I have an impression that it implies the existance of E4 Workbench and that narrows its usage. And, as we already have a zoo of logging interfaces, promoting another one may not improve the situation. It also does not support lazy message calculation and forces client to check the log settings before logging. Instead of that I would expect base logging interface method like in the log4j 2.x: ``` void log(Supplier<String> message, Throwable t) ``` So, the idea to create a facade for OSGi FrameworkLog and DebugTrace facilities is good but the implementation needs more work. And most probably it should be done on Equinox side.
(In reply to Alexander Fedorov from comment #2) > So, the idea to create a facade for OSGi FrameworkLog and DebugTrace > facilities is good but the implementation needs more work. And most probably > it should be done on Equinox side. I would not be in favor of yet another set of logging API in Equinox. The latest OSGi Logger interface is advanced enough for the usecase IMO https://docs.osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/log/Logger.html
(In reply to Thomas Watson from comment #3) > (In reply to Alexander Fedorov from comment #2) > > So, the idea to create a facade for OSGi FrameworkLog and DebugTrace > > facilities is good but the implementation needs more work. And most probably > > it should be done on Equinox side. > > I would not be in favor of yet another set of logging API in Equinox. The > latest OSGi Logger interface is advanced enough for the usecase IMO > > https://docs.osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/log/Logger. > html I agree, it already has a lot of methods. But I'm afraid it still misses the good way to avoid message calculation before the actual logging. The only "lazy" argument I can see is LoggerConsumer<Exception> and I doubt it can make the developer's life simpler. May be I missed something.
(In reply to Alexander Fedorov from comment #4) > (In reply to Thomas Watson from comment #3) > > (In reply to Alexander Fedorov from comment #2) > > > So, the idea to create a facade for OSGi FrameworkLog and DebugTrace > > > facilities is good but the implementation needs more work. And most probably > > > it should be done on Equinox side. > > > > I would not be in favor of yet another set of logging API in Equinox. The > > latest OSGi Logger interface is advanced enough for the usecase IMO > > > > https://docs.osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/log/Logger. > > html > > I agree, it already has a lot of methods. > But I'm afraid it still misses the good way to avoid message calculation > before the actual logging. The only "lazy" argument I can see is > LoggerConsumer<Exception> and I doubt it can make the developer's life > simpler. Which set of developers are we talking about? The developer writing log messages or the developer reading log messages? > May be I missed something. The various methods (trace, debug, info, warn, error, audit) all have vararg variations which can be used to compute the message according to the type of Logger one obtains from the LoggerFactory (you can request a Logger or FormatterLogger) For example the Logger javadoc says: Messages can be formatted by the Logger once the Logger determines the log level is enabled. Use a left curly bracket ('{' \u007B) followed by a right curly bracket ('}' \u007D) as a place holder for an argument: "{}". If you need to use the literal "{}" in the formatted message, precede the place holder with a reverse solidus ('\' \u005C): "\{}". If you need to place a backslash before the place holder, precede the reverse solidus with a reverse solidus: "\\{}". The key is that the Logger implementation determines if the Logger is enabled for the log level being logged then it computes the message based on the inputs to the log method. The consumers of the log entries will not ever be called if the log level is not enabled for the specific logger through the configuration of LoggerAdmin.
