Announcement Announcement Module
No announcement yet.
How to make runtime configurable apps with Spring? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to make runtime configurable apps with Spring?


    What is the current best practice for writing applications using Spring IoC that are configurable at runtime?

    For example imagine a CMS application (lol - the mythical Spring based free CMS) that has a Configuration page.

    When the admin user goes to this page they would be given the option to choose what authentication mechanism is used:

    (*) Jdbc datasource - data source name [jdbc:// ]
    ( ) Tomcat container managed
    ( ) CAS
    ( ) Simple text file

    From my currently limited understanding of Spring and Acegi, I can't see how this kind of runtime configuration change can be made easily.

    The best solution I can see is having the application's main context XML use:

    <import resource="configuration_choices/authtype-beans.xml"/>

    ...and then in the configuration_choices directory we have authtype-beans.xml which is over-written by the configuration UI when the user changes the options, and contains only:

    <import resource="authentication/jdbc-auth-beans.xml"/>

    ...if for example the user had chosen JDBC authentication.

    This allows us to pre-ship bean configs for different config scenarios, without having to copy files / write out XML except for a trivial template-based XML file (shown above) that just has a single filename change in it.

    This of course does not cater for:

    1. Changing values within the pre-shipped bean config files
    2. Reloading

    I understand that reloading is slated for 1.3 - is there any clean solution for it now?

    Using Spring in a shared hosting environment - a requirement for getting, for something like a free java CMS to get any kind of mass usage - means that we can't restart the container when we want to reload. Also we can't guarantee that we can force a reload our app either.

  • #2
    OK not many takers here... I'll kick it off

    One thought I had is to have create a proxy BeanFactory inside your normal bean context which has behind it, say, an XmlBeanFactory.

    Then you can "reload" existing config by telling the proxy to discard its XmlBeanFactory and create a new one.

    How does this sound? ...and are there classes in Spring aleady to do this (aggregate another BeanFactory)?


    • #3
      This discussion is very interesting because I was about to ask nearly the same question. Actually I'm currently working on sort of a Spring-based CMS (why mythical ?) and my problem right now is to allow for hot-pluggable modules as it is possible in PHP CMS's.
      The way I see it, a module is made up of :
      - Spring service classes
      - Hibernate entity classes
      - SQL database initialization scripts
      - Miscellaneous XML configuration files (namely for Spring and Hibernate)
      - possibly other files like the ones for the presentation layer.
      And my big issue is with the first two types of files : is it possible with Spring (and by extension with Hibernate) to dynamically load java classes ? that is to say I want to be able to load a Spring bean factory description file at runtime.

      That with the security configuration issue I hadn't even thought of, and possibly other configuration issues makes me wonder about the dynamic capabilities of Java in general, and Spring in particular. Am I right to worry about that ?


      • #4
        There has been lots of discussion around this. My impression (and I for one think a good idea) is that the Spring folks have been trying to avoid making Spring a heavyweight container (e.g. doing its own classloading and full life cycle management stuff). Although in one of the threads, IIRC, Rod Johnson did indicate that if a lot of users should ask for it, they'd consider it in future releases.


        • #5
          Well I miss a bit of experience to undestand all the issues but... isn't there a conceptual intermediate between the current lightweight architecture and a heavyweight one like the one of EJB's for example ? Because I love the lightweight aspect in Spring too and I didn't realize that what I need right now would require such a huge change in direction.
          Do you suggest that the kind of things I'm talking about are possible with heavy weight containers like JBoss for example ?


          • #6
            I might be a bit dense today(or always) and still steaming from a couple of lost poker hands. I thought your "hot-pluggable modules" sounded pretty much like -- EARs. For Spring to be able to handle things like that, it sure gonna need its own classloader(s).


            • #7
              I have been looking for the same thing, change configuration at runtime AND then have the changes persisted for next run.

              Someone mentioned telling the XMLBeanFactory to effectively reload its configuration.

              Wouldn't that imply that all objects created by the factory will have to be destroyed and new ones instantiated? That would be crazy.


              • #8
                Originally posted by alwyn
                I have been looking for the same thing, change configuration at runtime AND then have the changes persisted for next run.
                That's exactly what I'm looking for. Is there a best practice solution to implement it?

                What about using the PropertyPlaceholderConfigurer described here?



                • #9
                  So i take it that a) this has not been implemented in Spring and that b) no one has found a clean solution?

                  Well, i'm also in the market for something like this. I would like to be able to modify a property (which i can off a pojo) and then persist it to the application context xml configuration, at runtime. This way, if the container (servlet) needs to be restarted, the persisted changes are picked up again.

                  Anyhow, i'm interested in finding out if anyone has something clean, meanwhile, i'll be working on a solution myself (as i'm sure all of you will). I'll post my results or at least what i did when i'm happy with a solution.



                  • #10
                    One of the solutions I have found for runtime configuration information is to use a proxy and a custom TargetSource. So for each invocation of whatever services need that runtime configurable information, it will always fetch the latest choice.

                    You would load the application with your custom TargetSource which would be configured with all of your choices. In fact your TargetSource could enumerate the names of them for display.


                    • #11
                      Hey Bill,

                      Thanks for the suggestion. I haven't really gone into the AOP side of spring, however, now sounds like a good time to catch up on it. From reading some of spring's javadocs, it appears that I might be able to leverage the "HotSwappableTargetSource" (dunno, just shooting in the dark right now).

                      But thank you, i'll post back what i find out and hopefully, someone (as well as i) will benefit from all this