Runtime reconfiguration

[pjungwir]

Hello,

I am wondering if it's possible to alter an ApplicationContext at runtime. I see that some ApplicationContexts are "reloadable," and that they can have a "properties configurer." Does that mean I can at any point swap in a new "properties configurer" or change its properties, and then reload the ApplicationContext? That would be very cool.

My goal here is to allow an admin to tweak a running application by swapping in different implementations at various points. So on reload, I give the "userManager" id a different class. Or perhaps this or that bean's "userManager" property now has a ref to id "anotherUserManager."

Thanks!

Paul

[Alef Arendsen]

At the moment the option you have to change an application context are very limited. Refreshing of an application context (using the refresh() method, which I the one I suppose you meant) causes the persistent context to be reloaded (in many cases XML). So you'd have to modify the XML and then reload the context (which isn't really feasible I guess).

Either 1.2 or 1.3 will feature better support for dynamic reloading of a context and swapping out/in of beans.

regards,
Alef Arendsen

[pjungwir]

If I write it, can it go in 1.2? :-)

Seriously, compared to what I need, I imagine you'll want to do something much cleaner, writing an appropriate interface and then retrofitting classes to implement it, something like setBeanDefinition(String id, BeanDefinition def). But I am thinking that I'll copy/paste some existing ApplicationContexts so I can propgrammitcally plug in a properties configurer and then call refresh. The XML file would not change, but the values for the ${blah} properties would be different. Imagine I have this:

<beans>
<bean id="userManager" class="${userManagerImpl}"/>
<bean id="myService" class="com.company.MyService">
<property> <ref bean="userManager"/> </property>
</bean>
</beans>

In that case, I need only tweak the PropertyPlaceholderConfigurer and hit refresh. Does that sound like a reasonable approach?

Btw, thanks for the quick reply.

Paul

[Alef Arendsen]

I'd do it programmatically. The PropertyPlaceholderConfigurer has a method (postProcessBeanFactory) you can use to do this. The thing is however that the factory will already have initialized itself after you call refresh() and when eagerly loading singletons the values you'll be providing won't have any effect. You can specify the default lazy initialization parameter at the <beans> level (default-lazy-init). It's probably work if you set this to true.

PropertiesPlaceholderConfigurer config;
ConfigurableApplicationContext ctx;
config.postProcessBeanFactory(config);

I'm not sure if all works like you want. Could you provide some feedback if it does (or doesn't)?

Hope this helps.

regards,
Alef Arendsen

[pjungwir]

Okay, it works great!

I ended up extending PropertyPlaceholderConfigurer to override resolvePlaceholder. My class keeps its own static Properties and checks there first. If it doesn't find what it wants, then it calls super.resolvePlaceholder. This lets me set properties that will stick around even after refreshing the BeanFactory. You would get similar behavior if you looked for the properties in a database instead of a static variable. Here is the class:

package com.company;

import org.springframework.beans.PropertyValue;
import org.springframework.beans.MutablePropertyValues;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;

import org.apache.log4j.Logger;

import java.util.*;

public class StaticPlaceholderConfigurer extends PropertyPlaceholderConfigurer {

    private static final Logger log = Logger.getLogger(StaticPlaceholderConfigurer.class);
    private static final Map    overrides = new HashMap();

    private String  _beanName;
    private BeanFactory _factory;

    public StaticPlaceholderConfigurer() {
        log.debug("overrides at new instance: " + overrides);
    }

    protected String resolvePlaceholder(String placeholder, Properties fallback) {
        Properties props;
        String  ret;

        synchronized (overrides) {
            props = (Properties)overrides.get(getKey());
            log.debug("props for " + placeholder + ": " + props);
            if (props == null) {
                return super.resolvePlaceholder(placeholder, fallback);
            } else {
                ret = props.getProperty(placeholder);
                if (ret != null) return ret;
                else return super.resolvePlaceholder(placeholder, fallback);
            }
        }
    }

    public String setOverride(String name, String value) {
        synchronized (overrides) {
            Properties  props;
            OverrideKey key;

            key = getKey();
            props = (Properties)overrides.get(key);
            if (props == null) {
                props = new Properties();
                overrides.put(key, props);
            }
            return (String)props.setProperty(name, value);
        }
    }

    public void setOverrides(Properties props) {
        synchronized (overrides) {
            overrides.put(getKey(), new Properties(props));
        }
    }

    public void clearOverrides() {
        synchronized (overrides) {
            overrides.remove(getKey());
        } 
    }

    private OverrideKey getKey() {
        return new OverrideKey(_factory, _beanName);
    }

    public void setBeanName(String name) {
        super.setBeanName(name);
        _beanName = name;
    }
    public void setBeanFactory(BeanFactory f) {
        super.setBeanFactory(f);
        _factory = f;
    }

}

class OverrideKey {

    private final BeanFactory _f;
    private final String _beanName;

    public OverrideKey(BeanFactory f, String beanName) {
        _f = f;
        _beanName = beanName;
    }

    public int hashCode() {
        // return _f.hashCode() + _beanName.hashCode();
        // The factory is a different instance after refresh.
        return _beanName.hashCode();
    }

    public boolean equals(Object o) {
        if (o instanceof OverrideKey) {
            OverrideKey k = (OverrideKey)o;

            // return _f.equals(k._f) && _beanName.equals(k._beanName);
            // The factory is a different instance after refresh.
            return _beanName.equals(k._beanName);
        } else {
            return false;
        }
    }
}

I then use an applicationContext.xml file like this one:

<beans>
    <bean id="myService" class="com.company.MyService">
        <property name="emailManager"> <ref bean="$&#123;emailManager&#125;"/> </property>
    </bean>
    <bean id="override" class="com.company.StaticPlaceholderConfigurer">
        <property name="systemPropertiesModeName"><value>SYSTEM_PROPERTIES_MODE_NEVER</value></property>
        <property name="properties">
            <props>
                <prop key="emailManager">emailManager</prop>
            </props>
        </property>
    </bean>
    <bean id="emailManager" class="com.company.EmailManager"/>
    <bean id="mockEmailManager" class="com.company.MockEmailManager"/>
</beans>

When we begin, MyService has an EmailManager. But if I want to change to a MockEmailManager, I just get the override bean, call setOverride, and then refresh the ApplicationContext. Future clients of MyService will use a MockEmailManager. This is great for test code. I plan to use the same patten for all sorts of hot-swappable interfaces.

Thanks for your help,

Paul

[Rod Johnson]

Paul

Thanks for posting this. I'll look at this properly for the 1.3 timeframe.

The scope of 1.2 is now fairly fixed--Hibernate 3, transaction annotations, JMX and (hopefully) an official release of TopLink support--but such "dynamic" features will hopefully go into 1.3. We're currently interested in support for configuration in JSR-170 content repositories, which should be dynamic and allow versioning.

Rgds
Rod

[DeKi]

"dynamic" features will hopefully go into 1.3

I'm looking for dynamic reconfiguration features. How is the current planning?

Regards
Dennis