Announcement Announcement Module
No announcement yet.
How to deal with Runtime configuration with IoC? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to deal with Runtime configuration with IoC?

    My understanding is that IoC is going to replace the lookup function, such as those provided by a factory. However, if the decision as what subclasses/impl classes to use is not known until run time, how can IoC solve it? I believe the information has to be avaliable by compile time in order to put the dependency in an XML file. I still think a factory is more powerful than an IoC container since decision can be made at run time depending on some parameters. Please advise. Thanks,

  • #2
    You still can use Spring API to configure and wire the beans at runtime. This is very helpfull if you do not know, by compile time, what combination of bean must be used to meet a specific need.


    • #3
      I'm using both factories and spring.

      In one of my Service Facade objects created by spring I inject a factory, mostly to keep the Service from being ApplicationContextAware. The Service itself is injected into some of my Controllers.

      I can exchange the factory at any time without having to change the Service - the factory itself implements an interface.

      In this case the factory itself is ApplicationContextAware, it knows how to get prototypes from the ApplicationContext. Some of the objects it "manufactures" for its client are chosen based on Class literal arguments (getBeansOfType()), I find this especially useful for class hierarchies that are kept in polymorphic collections via Hibernate.


      • #4
        Can you shed some lights as what Spring API can be used to wire objects at runtime? I am fairly new to Spring. Many thanks,


        • #5
          This is an excerpt from some code I used in a JUnit Test:
              /*create a MockUserManager and populate it with sample data
               * same as:
               * <bean id="userManager" class="org.taha.service.MockUserManager">
               *   <property name="users">
               *     <list>
               *       <bean class="org.taha.domain.User">
               *         <constructor-arg><value>1</value></constructor-arg>
               *         <constructor-arg><value>Taha</value></constructor-arg>
               *       </bean>
               *       <bean class="org.taha.domain.User">
               *         <constructor-arg><value>2</value></constructor-arg>
               *         <constructor-arg><value>Maryam</value></constructor-arg>
               *       </bean>
               *     </list>
               *    </property>
               * </bean>
              ApplicationContext wac = new StaticWebApplicationContext&#40;&#41;;
              List users = new ArrayList&#40;&#41;;
              users.add&#40;new User&#40;1, "Taha"&#41;&#41;;
              users.add&#40;new User&#40;2, "Maryam"&#41;&#41;;
              //register userManager within Spring WebApplicationContext
              MutablePropertyValues pvs = new MutablePropertyValues&#40;&#41;;
              pvs.addPropertyValue&#40;"users", users&#41;;
              wac.registerSingleton&#40;"userManager", MockUserManager.class, pvs&#41;;


          • #6
            Also take a look at the FactoryBean interface. A factory bean is really just a bean, configured in the application context like any other bean, that is a factory of other beans. Using a factory bean you can combine factory code to determine what object to create with wiring in the application context.



            • #7
              I still think a factory is more powerful than an IoC container since decision can be made at run time depending on some parameters.
              Hence Spring has the FactoryBean support, and also enables the use of factory methods: static or on any bean in the factory.

              Nevertheless, usually you do know when you write the config (not necessarily when you compile the classes, so the DI approach is simpler and more appropriate than a traditional factory.

              You can use AOP to introduce a level of indirection that can be useful for dynamic wiring also. E.g. you have a TargetSource that's effectively choosing what it should delegate to.


              • #8
                Perhaps this is related to this topic.

                Is there a way to provide a bean 'placeholder'?

                Scenario, an xml bean definition defines a bean "knownBean". This bean has a reference to another bean "notYet". During runtime the application later injects the now known implementation object or class into the "notYet" placeholder in the context, thereby satisfying a dependency for the "knownBean".

                I guess there is a way to do this using lazy-init and aop, by just using a new kind of anonymous bean definition, or this is where scripting approaches really shine. Or its too early in the morning and I have not had my coffee fix.