Add a helper function that makes it easier to log from anywhere

[ChristophWurst]

Our DI is able to inject a logger implementation to any server and app
class if they want one. However, sometimes DI isn't applicable or hard
to add. In those cases we typically fell back to the service locator
pattern where we acquired a logger from the server via a global
variable.

There were some issues with that

• \OC is a private class, apps are not supposed to use it
• \OC::$server is a global variable, a well known anti-pattern
• \OC::$server->get(...) uses the service locator anti-pattern
• \OC::$server->get(...) may throw
• \OC::$server->get(LoggerInterface::class) is not scoped to an app

With this patch I'm proposing a new helper function \OCP\Log\logger
that can be used to acquire a logger more easily. This function is meant
to be public API and therefore apps may use it and there is an optional
parameter to specifiy the app ID.
The function hides all the ugly details about the global variable and
the potentially thrown exceptions from the user. Therefore it's
guaranteed that you always get a logger instance. In the worst case you
get a noop, though those occasions should be rare.

The intended usage is either

use function OCP\Log\Logger;

logger('mail')->warning('user did something bad');

or quick and dirty (e.g. for some debugging)

\OCP\Log\logger('mail')->warning('the user did something bad');

This idea is based on a recent discussion with @nickvergessen and @rullzer. Let me know what you think.

[rullzer]

Seems like a step in the right direction!

[rullzer]

But CI says no

[kesselb]

Fix the path in composer.json. I don't know why composer dump-autoload produces a different result.

composer -V
Composer version 1.10.21 2021-04-01 09:16:34

[nickvergessen]

Use composer 2

[kesselb]

Use composer 2

Good point. I think we need composer 1 for some horde repositories. Will install it as composer2 and run dump-autoload again.

[ChristophWurst]

I gave this another thought over the last few days based on some input by @miaulalala. I would still say a free function is preferable over a static method on a class. Putting some bad memories from the old static APIs aside, I think the class approach will make it too tempting to introduce state via static variables, and therefore pull in all the trouble of impure "functions". The current free function is pure-ish, the result does depend on some side effects but at least the function is guaranteed to not change any state. IMO this should be the preferred way.

[skjnldsv]

Please rebase :)

[skjnldsv]

/rebase

[nickvergessen]

Any changes resulting from \OCP\Server::get() being created? Should we keep the method approach here or maybe create Server::log()?

[ChristophWurst]

#26582 (comment) I stand by that.

[ChristophWurst]

@juliushaertl @PVince81 @icewind1991 any preference on your side?

[juliusknorr]

I'd be all in favour for the current approach of that PR to have it somehow independent API wise from the server container.