Rename the ILogger interface to Logger

[kittaakos]

Rename the ILogger interface to Logger, so that it is aligned with our Coding Guidelines. Nothing more.

[lmcbout]

According to issue #624, should it be LoggerImpl ?

[kittaakos]

You mean, the implementation; yes. LoggerImpl is good. We do not see that too much often anyway.

[lmcbout]

I agree

[vince-fugnitto]

I'm not sure if renaming ILogger to Logger would be appropriate at the moment since it will most likely break a lot of external extensions still referring to the original name. Perhaps in the future when we have our first main release (ex: 1.0.0), we can take time to clean up the code, and any extensions would have to align with our new codebase.

[akosyakov]

as public API using console.log is preferable

At the beginning, we thought that Logger was a good idea, but after realizing that 3rd party libraries could not use it, decided to allow console.log and hook it with Theia.

[tsmaeder]

@akosyakov that leaves the question how to filter log output, though. What's the story there when using console.trace, etc?
In development, we often want to turn on debug and trace info. Adding console.log statements each time does not scale.

[akosyakov]

In development, we often want to turn on debug and trace info. Adding console.log statements each time does not scale.

You can call console.trace and console.debug, they are delegated respectively to Logger.trace and Logger.debug. Logging level can be configured by passing --log-level cli option to theia start.

[tsmaeder]

So console.log is redirected to rootLogger.log, which again goes to the console? Anyway...still not reason not to use ILogger, it allows to turn on/off logging per named log, not globally.
We have the same situation in Java, where different components will use different logging mechanisms, but that's not a reason to use printf directly.

[akosyakov]

So console.log is redirected to rootLogger.log, which again goes to the console?

If someone logs in the browser content, the root logger ensures that all logs end up on the backend, not only in the browser console. By default, yes, they are forwarded to the backend console. End products can overwrite it and integrate with own logging infrastructure. For example, Gitpod wraps logs in JSON structures and forward them to Google Stackdriver for analysis.

Anyway...still not reason not to use ILogger, it allows to turn on/off logging per named log, not globally.

One can do it when necessary. Theia coding guidelines are not something to copy for end products. Also within Theia for child logging using Logger is fine. I will update the coding guidelines to prefer console only for the root logging.

We have the same situation in Java, where different components will use different logging mechanisms, but that's not a reason to use printf directly.

It is not the same. In Java printf using stdout not the logging framework. In Theia, when someone calls console our Logger is used, not the native console. If someone likes boilerplate they can inject the root logger each time to call log on it. Although console.log does exactly the same in any contexts.