With 4152216bd8 these two interfaces got
deprecated with the reasoning that we only need the base PSR interface.
However, there are cases where in Nextcloud you still want to have a
specific container (the one for the app vs the one for the server) when
you either have a container injected or query one from a container.
With a single interface that would not be possible. So it's probably
better if we leave the two interfaces, but only have them extend the PSR
interface. IContainer – with the custom methods – shall still be phased
out, but the two other sub interfaces can stay for tagging purposes.
Tagging means that no methods shall be added.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The logger service was always intended to follow the PSR-3 interface.
It's time to embrace this and switch over to the "official" API,
hence this custom interface can be slowly phased out.
With Nextcloud 20 the logger also got support for
* App id filled out automatically
* Exceptions handling (as replacement for logException)
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Service locators are an anti pattern. These getters just make it more
appealing to do the wrong thing. If you want to locate a service the bad
way, just use the `get` method on a container – it will do the same in
also one line of code.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This will allow to do lazy registration here which should allow for
loading less (or at least only when needed!).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The old sharing mechanism isn't working anymore, because it was replaced by Share 2.0. Also it was nowhere used so this removes the code paths and reduces complexity.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
This is like what we have to DI and classes, but for callables.
The motivating factor is to get rid of *service locators* in the `boot`
method of apps as a new pattern is about to emerge where we have lots of
`query` calls on the app or server container in order to fetch some
services.
With this little helper it's possible to call another (public) method
and magically have everything injected.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
while some code paths do wrap the "raw" locking exception into one with a proper path, not all of them do
by adding the proper path to the original exception we ensure that we always have the usefull information in out logs
Signed-off-by: Robin Appelman <robin@icewind.nl>
In general it is good to set them to Lax. But also to give devs more
control over them is not a bad thing.
Helps with #21474
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Julius Härtl
Roeland Jago Douma
Morris Jobke
Christoph Wurst
Joas Schilling
Joas Schilling
Roeland Jago Douma
Daniel Kesselberg
Robin Appelman
blizzz