MCR-3483 object lock for REST API

[Mewel]

Link to jira.

[rsteph-de]

MCRRestAPIObjects is getting longer ...

Is there a possibility to separate the Lock-API calls into another class?
This can be done in a follow-up PR which cleans up the REST-API code.

Otherwise O.K.

[Mewel]

MCRRestAPIObjects is getting longer ...

Is there a possibility to separate the Lock-API calls into another class? This can be done in a follow-up PR which cleans up the REST-API code.

Otherwise O.K.

I'm doing some changes right now anyway. I could also move it separate if you like.

Edit: question is where too?

[rsteph-de]

I'm doing some changes right now anyway. I could also move it separate if you like.

This could show as "proof-of-concept" - that it is possible to have multiple RESTController classes with the same path-prefix.

[rsteph-de]

This is the introduction of the Jersey Dependency Injection mechanismn in MyCoRe (first use).
In my opinion this is a architectural decision that adds "complexity" to the code and should be discussed first in an online meeting..
I tend to stay with "our" MCRConfiguration2.getInstance().

[Mewel]

I can see your point. And im ok with changing it.

But in general I prefer the default way and for me that would be using the @Inject method, cause its out of the box available without any boilerplate code (and tbh our property injection stuff comes with a lot of it...). The binding happens in MCRRestV2App. I could see using our property configuration there.

We also use the @singleton annotation from the same package. So we kind of mix the stuff already.

[yagee-de]

Good work, but a minor issue between interface, implementation and configuration. Maybe the interface is not necessary?

[yagee-de]

It's either hard coded (no interface) or configurable.

[Mewel]

I can make it configurable.
But an interface is in both cases good. For example if somebody decides to write tests for the MCRRestObjects class. Then you can easily mock the ObjectLockService interface.