OpenPatrician Blog

Spring context injection

To be able to implement the save/load functionality without too many headaches some preconditions have to be met.

Motivation

The application builds upon the SpringFramework which initiates a context that manages singleton beans. The Spring context is started upon application startup. When a game is started many more beans are created to populate the model architecture representing a game. Some of these beans are singltons that are lazy initiated but the most part are prototype beans. Prototype beans are only instantiated by the context but no reference is held on them within the context object. There are prototype beans that are unbound, meaning during the progress of the application any number of them can be created, but there are also certain prototype beans that only exist in small number and generally do not change after initialization. Then there are prototype beans which are basically singletons but cannot be defined as such as they require constructor arguments.

To be able to save and load a game it is required that the state of the game can be stored and restored.

Aim of the Proof of Concept

Late spring context initialization

While it is possible to define a spring bean as lazy meaning it is instantiated only when it is first needed (autowired) this wires the creation of a bean to the creation of another bean. With many of the beans being singletons this requires at least one manual creation. It would be desirable to be able to define an event upon which the bean is created. As the event system is already in place the optimal solution would be to define an annotation which defines the event objects type as the trigger. The framework would then instantiate that bean upon an event of that type.

See the corresponding ticket #143.

Context managed prototype beans

Extend the spring context so it can hold references to the selected beans of the classical prototype stereotype. Mainly these will be the singleton beans that don’t have a default constructor and therefore must be defined as type prototype. Another case are beans that created a certain number of times (e.g. cities, players,…).

The hard part here is not the possibility of storing them in an extended spring context, but in tweaking the autowireing system so that it works. Naturally for beans that exist in the context multiple times autowireing should not be possible or would require some kind of qualifier that would allow selecting the correct instance.

See the corresponding ticket #141.

Context bean injection

Beans can categorized into three different type:

1. Service beans that are created at startup and are not related to the game state. These are mainly the utilities that make up the system like resource loaders, factories, …
2. The beans that are created at startup and hold some game state. The most prominent example is the Date object.
3. The beans that are created upon game start and hold game state.

When saving a game the latter two must be serialized. When loading a game the beans of the second category are already present in the spring context and must be replaced with the counterparts from the unserialized game. Also the beans of the third kind must be injected into the context. This happens in a different way than when creating a new game.

The hard part here is that replacing an object in the context must also update all the reference on the object. To make this as simple as possible the beans of the second type should be avoided and the beans of the third kind should all have one single root object.

See the corresponding ticket #132.