Programmatically creating/configuring Spring components

[Stefan Arentz]

I sometimes am in the situation where I really just want to expose a high level object to the Spring configuration and take care of certain details in the code.

For example, I have a DistributedImageProcessor that programmatically creates a DefaultMessageListenerContainer. This is because the settings of this DefaultMessageListenerContainer depend on the configuration of the DistributedImageProcessor and cannot be determined during processing of the Spring xml config files.

So I really just new a DefaultMessageListenerContainer, configure it and then call afterPropertiesSet() myself.

Is this considered to be really bad? It is probably a corner case, but still a real world scenario.

Is there a nicer way to do this?

S.

[wpoitras]

Spring is a pretty well defined API. I don't see why calling it programatically is a bad thing. Specifying configuration is preferable, but sometimes you need to get creative.

Spring itself still doesn't handle run-time configuration as well as some people need. Mostly because static configuration handles most cases.

See if you can do something like this:

<bean id="distributedImageProcessor" class="DistributedImageProcessor">
  <properties go here/>
</bean>

<bean id="customMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer" scope="prototype"
  <property name="someProperty">
    <bean class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
        <property name="targetObject" ref="distributedImageProcessor"/>
        <property name="propertyPath" value="imageProperty"/>
    </bean>
  </property>
</bean>

Basically what this would do is allow you to create a new DefaultMessageListenerContainer based on the current properties of your DistributedImageProcessor. That of course assumes your DistributedImageProcessor is a singleton bean in your application context.

If its a regular singleton with a factory method like getInstance you can get a reference to the object in your application context like this:

<bean id="distributedImageProcessor" class="DistributedImageProcessor" 
factory-method="getInstance"/>

[Stefan Arentz]

Hmm interesting. I think I could do something along those lines and then hide the 'ugly' :-) spring config in a Spring XML extensions like <pr:imageProcessor .../> or so.

Hmmmmm. Needs to be in my brain a little longer.

Thanks!

S.

[Jörg Heinicke]

Is this considered to be really bad?

I agree with wpoitras that it is not bad by itself. You sometimes need it or it is simpler to have the setup of the components in the code.

I use the programmatic setup of components for example in tests. While the database access normally happens in a JTA environment I use simpler setups in some tests. Moving the setup to Spring config files just complicates things, actually I want to test the functionality, not the correct setup. Hence, I use the programmatic setup just for simplifying things.

Jörg