Announcement Announcement Module
No announcement yet.
Persisting StaticApplicationContext Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Persisting StaticApplicationContext

    I'm considering the idea of using the application context as a semi-dynamic application configuration context, e.g. an administrator creates ctx entries (which automatically became available across the whole application), removes them from the ctx etc. using some GUI. Of course, those entries should survive eventual application crashes/restarts so I have to persist them. Two options come to mind: persist objects and use StaticApplicationContext with some kind of loop to fill in the appctx, or persist that StaticApplicationContext to some XML file and load it just as any other application context. I like the second idea better.

    Are there any means to easily persist (changed) application contexts in the way that saved ctx is suitable for loading by standard application context loaders, such as the classpath+xml-aware one?

    Any other ideas on how to persist an application context? I have to mention that all appctx entries (beans) will be singletons and won't change their state too often (if ever).


  • #2
    This is a very interesting idea.
    we already envisaged it for a large application with xml configuration files.
    However, there's not a single way to create an xml file representing. Once beans are created in memory, you can retrieve them when your appContext implements ListableBeanFactory. Still, it is not a bijection as when creating beans you can have BeanFactoryPostProcessor or BeanPostProcessor acting on beans, notably the PropertyResourceConfigurer, ... You also have our friends the AOP aware beans which inject behaviour on beans in a way which is hard to find the xml configuration leading to the in memory instance.
    So, there's not a canonical way to do this and it is understandable that spring doesn't provide a universal solution to this. However, in your case (and mine we have a restricted use of the bean factory and could imagine using the ListableBeanFactory api to create a quick xml configuration. Don't forget the BeanWrapper which allows to inspect beans to find their properties and of course, the current value.