The problem with Prism is that individual modules may have own spring configurations and should be able to be loaded at run time.
More than that, the majority of the Prism services expect ServiceLocator to be able to access all the object definitions from the loaded modules.
The problem that I've noticed, that Spring has no ApplicationContext, supporting reconfiguring on the fly.
The XmlApplicationContext expects all the locations to be given in the constructor and it is not possible to add some ObjectDefinitions programmatically (or they will be forgotten on Refresh).
The GenericApplicationContext doesn't support multiple calls of Refresh(). And without it you aren't even able to define "simple" circular dependency in the modules (cause you have to use lazy-init, which isn't finished till Refresh()).
Using Hierarchical Contexts doesn't help much, cause you are not able to express the fact, that some module can be dependent on more then one another...
So, as for me, the only way to solve the problem is to implement some kind of ReconfigurableApplicationContext, where the internal ObjectFactory will not be destroyed on the Refresh() and on registering ObjectDefinitions they will be added to a list of objects to consider on refreshing. On the end of Refresh() the list should be cleared...
That's the way I gonna try it.
I would be glad to know you opinions.
(I've already made a Quickstart/Modularity/ModularityWithSpring for Prism, which works, but my SpringExtentions are not ready to be used in the real-world applications)