conditional processing

[bryanhunt]

Hi there,

This is a feature that I don't think ( after reading the documentation )
spring currently supports but I think it would be a cool feature so here
it is.


I am using the spring PreferencesPlaceholderConfigurer bean and
storing my preferences in the registry. This works absolutely great.

I can ship my web application and the user can run a simple
command line config tool which can configure their database etc
without them having to mess arround with tomcat config files etc.

This I think is super cool !

However I think there is something else really usefull that you could
do with this.

If it were possible to

a) Include or exclude a section of the spring configuration file based on
a property it would make setup and testing a snip.

Here is what I mean

<conditional property="{jestate.testing}" value="true">
<bean id="authenticationBean" class="ie.jestate.testing.AuthenticationBean"/>
</conditional>

<conditional property="{jestate.testing}" value="false">
<bean id="authenticationBean" class="ie.jestate.AuthenticationBean"/>
</conditional>

and or

b) Include files within the tree.


<conditional property="{jestate.testing}" value="true">
<loadbeandef="classpath:com/mycompany/mypackage/test-datasource.xml"/>
</conditional>

<conditional property="{jestate.testing}" value="false">
<loadbeandef="classpath:com/mycompany/mypackage/datasource.xml"/>
</conditional>

Maybee this stuff is too complicated to implement, I don't know as
I amn't a real xml expert. But it strikes me that this would be a
really cool feature.

It is very popular allready with ANT

--b

[bryanhunt]

This would mean that you could have one set of spring configuration files
for your entire application.

Just setting the testing property would enable your testing or live
configuration.

You would no longer have to maintain seperate config files for web and
multiple testing files for different configurations.

--b

[bryanhunt]

Perhaps

org.springframework.context.support.ClassPathXmlAp plicationContext

Could be subclassed somehow to do this ?

Config would then be like so

<beans>

<bean id="examples.spring" class="org.springframework.context.support.Configu rableClassPathXmlApplicationContext">
<constructor-arg>
<map>
<entry key="jestate.testing=true">
<value>examples/spring/spring.xml</value>
</entry>
<entry key="jestate.testing=false">
<value>examples/spring/authentication.xml</value>
</entry>
<entry key="jestate.testing=false">
<value>examples/spring/spring-database.xml</value>
</entry>
</map>
</constructor-arg>
<constructor-arg>
<map>
<entry key="jestate.testing">
<value>${jestate.testing}</value>
</entry>

</map>
</constructor-arg>
</bean>
</beans>

Is this a good idea ? If you are interested I can create this and submit my
code to the project.

--b

[mperham]

But spring already supports this in a much cleaner method (IMO) without conditionals by just specifying the context files you want to use:

        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
                new String[] {"applicationContext-domain.xml", 
                                    "applicationContext-domain-test.xml" });

Where domain is my live configuration and test overrides certain values in it to use a Hypersonic VM db instead. The override capability is why you don't need conditionals.

This would mean that you could have one set of spring configuration files
for your entire application.

Just setting the testing property would enable your testing or live
configuration.

You would no longer have to maintain seperate config files for web and
multiple testing files for different configurations.

[bryanhunt]

Yes but I may want to run the web application in testing mode.

ie without enabling authentication or enabling default auth so that
any username/password combination will work.

I could do it the way that you suggest but it would mean that I
would have to access the preferences api in my unit tests and
in my struts actions.

It would be cooler if all the preferences based config was in
the spring configuration.

For example here is a snippet from my current config.


<bean id="placeholderConfig"
class="org.springframework.beans.factory.config.Pr eferencesPlaceholderConfigurer">
<property name="userTreePath"><value>ie/jestate</value></property>
</bean></programlisting>



Here is the configuration of the data source further on in the applicationContext file ...


<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>${jestate.driver.class.name}</value>
</property>
<property name="url">
<value>${jestate.database.url}</value>
</property>
<property name="username">
<value>${jestate.username}</value>
</property>
<property name="password">
<value>${jestate.password}</value>
</property>
</bean>

Now I am going to have a lot of things in my spring config.

I'm running it with ageci so I'm going to have AOP method
interception going on.

I'm planning on shipping a httpinvoker SWT webstarted
application as well.

I can see a situation where I start to get a lot of spring
configuration files.

If I could process differently based on a simple couple of
preferences based variables it would make my project
a lot neater and simpler for people to use and get started
as developers with it.

[karsten]

or you take ant to do this.
ant builds your application-context.xml into the build folder from a xml file looking similar to the one you mentioned. Ant is checking the value based on what you specify in a build.properties or similar, and after that either excludes the bean or inserts it into the builded xml file.
Hth.

[bryanhunt]

or you take ant to do this.
ant builds your application-context.xml into the build folder from a xml file looking similar to the one you mentioned. Ant is checking the value based on what you specify in a build.properties or similar, and after that either excludes the bean or inserts it into the builded xml file.
Hth.

I am looking to be able to do the following.

Provide my application http://jestate.dev.java.net as a war file.

Provide a simple command line application ( already made )
which can be used to configure it.

The user

a) Runs the config program ( which is perhaps run as part of the
installer )

b) Makes sure a suitable database exists on their system and
they have access rights to it.

c) Drops the war file into their tomcat directory.

d) Scoffs at the next person who says open source is hard to
configure and set up.

I don't want the average user to have to install ANT/download different
versions etc

The easier i make this to deploy the more people who are going to be
able to easily run this.

[memelet]

I have approached this a little differently.

When running our integration/system tests, there are just a few components that need to be replaced with simulators. These components are defined in the production appcontext, and "overridden" in an integration-test appcontext, eg:

Production

    <bean id="com.its.marketdata.realtimeCurrentPriceService"
        class="com.its.marketdata.service.currentprice.RealTimeCurrentPriceServiceFactoryBean" lazy-init="true">
    </bean>

    <bean id="com.its.marketdata.delayedCurrentPriceService"
        class="com.its.marketdata.service.currentprice.DelayedCurrentPriceServiceFactoryBean" lazy-init="true">
    </bean>

Integration Test

    <bean id="com.its.marketdata.simulatedCurrentPriceService"
        class="test.ftest.trading.SimulatedCurrentPriceServiceFactoryBean">
    </bean>

    <bean id="ftest.beanOverrides"
        class="test.ftest.trading.OverrideForTestBeanFactoryPostProcessor">
        <property name="overrides">
            <map>
                <entry key="com.its.marketdata.realtimeCurrentPriceService">
                    <value>com.its.marketdata.simulatedCurrentPriceService</value>
                </entry>
                <entry key="com.its.marketdata.delayedCurrentPriceService">
                    <value>com.its.marketdata.simulatedCurrentPriceService</value>
                </entry>
            </map>
        </property>
    </bean>

The class OverrideForTestBeanFactoryPostProcessor handles swapping out the production AbstractBeanDefinition for the test version:

public class OverrideForTestBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

    private Map overrides = new HashMap();

    public void setOverrides(Map overrides) {
        this.overrides = overrides;
    }

    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        for (Iterator beanNameIterator = overrides.keySet().iterator(); beanNameIterator.hasNext();) {
            String beanName = (String)beanNameIterator.next();
            String overrideBeanName = (String)overrides.get(beanName);

            AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition)beanFactory.getBeanDefinition(beanName);
            AbstractBeanDefinition overrideBeanDefinition = (AbstractBeanDefinition)beanFactory.getBeanDefinition(overrideBeanName);
            
            beanDefinition.overrideFrom(overrideBeanDefinition);
        }
    }
}

[mperham]

Barry, why wouldn't your integration context just look like this? Seems like you are making it harder than it needs to be?

<bean id="com.its.marketdata.realtimeCurrentPriceService"
        class="test.ftest.trading.SimulatedCurrentPriceServiceFactoryBean" lazy-init="true">
    </bean>

    <bean id="com.its.marketdata.delayedCurrentPriceService"
        class="test.ftest.trading.SimulatedCurrentPriceServiceFactoryBean" lazy-init="true">
    </bean>

[memelet]

Barry, why wouldn't your integration context just look like this?

No, because I am including the entire production-context.xml into the appcontext along with the integration-context.xml and doing what you showed would be defining two beans of the same id. (Or is allowed to override an existing bean id?)

If there were some form of conditional processing (as the orignal post suggested) then what I did would not be necessary. But I'm not sure I would want #ifs in my production context.xml.