Rework XStream initialization

[xeruf]

Due to the tests now running in parallel, we sometimes had ConcurrentModificationExceptions since the global XStream instance was initialized in parallel from different threads.

Now all initialization points are locked.

[anarchuser]

If the problem is concurrent invocation of registerXStream, wouldn't it be more sensible to make GamePlugin a singleton?

[xeruf]

That function is already static. That doesn't solve the concurrency problem, unfortunately.

[xeruf]

I have run all tests repeatedly locally with no failure. The one failing test has been unreliable for a while, I'll see whether I have to Disable it or find a fix.

[anarchuser]

As far as I can tell, that function is only called on initialisation of GamePlugin, right?

[xeruf]

you're right, the concurrency issues occur only in the tests. Hmm...

[SKoschnicke]

Tests are succeeding on my machine with the current state 👍

[anarchuser]

I think the actual issue is still why that function is being called several types at all

[xeruf]

As said, parallelized tests

[anarchuser]

yes, but this should be setup stage for tests. This shouldn't be something several tests initialise for themselves anyways.

[xeruf]

yeah, the question is whether there is a way to have global setup for independent tests.

[xeruf]

hello it's me, giant commit 😄 yes I just changed a lot of code. I will also add some documentation for that in the GUIDELINES soon. But unlike last time, where I made the XStream instance global (brevity at the expense of creating global state, which is the opposite of clean code ^^), this really does make the code a whole lot cleaner (which we can partly see through the application of the design patterns Factory + Template Method)!

[SKoschnicke]

Awesome!