Recently I have come across a problem, which does not have an elegant solution. Imagine you have a setup like this:
- Nice little (or not so little) application based on the Spring-Framework
- Lots of utilities and services that are waiting to be injected into something
- Services/Components which represent singletons and do have state, all managed through Spring
- Application State uses these services
- Application State is replicated: for example loaded from a file before injected with the Spring Beans
- Application State is ‚updated‘: the state is changed from the outside after it is created (think repeated loading replacing the old state)
If it were not for the last point the preferred solution would be to implement you own BeanFactory, create a new Spring context into which the newly created beans are pushed into and make it a child context of the already existing context. The BeanFactory would use the existing context to do the wiring on the newly created beans.
However when this replicating happens repeatedly you would end up with a huge context hierarchy, over which you have no control. What you want instead is some Hot soaping of the state in the existing context, but we all know how well these things work.
In my concrete use case the application consists of multiple parts, which do not run necessarily in the same VM, however share the same state. Another approach would be to have the state not managed by Spring. This however would complicate the application code considerably as the whole state would have to be passed around everywhere and each part would have to navigate through the model hierarchy to retrieve their required components.
So here is what I have come up with: