Announcement Announcement Module
Collapse
No announcement yet.
Programmatically creating/configuring Spring components Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Programmatically creating/configuring Spring components

    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.

  • #2
    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:
    Code:
    <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:

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

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by Stefan Arentz View Post
        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

        Comment

        Working...
        X