I have an interesting problem dealing with context startup order.
In my spring powered bundle I have multiple context files and one of them needs to startup before any of the others (a kind of bootstrap context). The context defines a factory bean (which provides properties to other beans), this singleton may or may not be accessed statically (not spring managed) by beans in other context files. The context loader for a bundle reads contexts in alphabetical order by default and a new context could be added in the future that accidentally starts before just because of its name - thus causing the application to crash with a null pointer.
- I tried to create a separate thread, but the calls to the singleton are sometimes made in a class' field.
- I can't have the singleton spring managed because it would be too much work to refactor.
- I haven't tried "import", but it seems erroneous to require that every context import a startup context.
- Creating a service doesn't work because the singleton is statically accessed.
- I haven't tried overriding the ApplicationContextCreator because I don't want to have to maintain this hook.
The only easy solution I've found is doing this below, which will load the bootstrap context and then any other context file. The only bad things are: we have to remember to add it and the manifest must become Spring aware.
Is there a better solution?
Should Spring-DM provide a special location to load any bootstrap context files? Like, if Spring finds a context in "META-INF/spring/bootstrap/" then it loads those first.