Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
post-construction configuration behavior Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • post-construction configuration behavior

    Post construction configuration does not retain original configurations. I am not sure if this is the expected behavior. I am using M4.

    Here is my test:

    JavaConfigApplicationContext initialContext = new JavaConfigApplicationContext(ThreadConfig.class);

    JavaConfigApplicationContext finalContext = new JavaConfigApplicationContext();
    finalContext.setParent(initialContext);
    finalContext.addConfigClass(AppConfig.class);
    finalContext.addConfigClass(DataConfig.class);
    finalContext.refresh();

    But, when I debug, I do not see the ThreadConfig in the finalContext configClasses. So when I refresh finalContext, my initial context configClasses are not retained? Also, I tried setAllowBeanDefinitionOverriding to true, but that didn't help either.

    On a similar note, probably section, 3.1.1.3. "Post-construction configuration" needs to update the code sample to use the addConfigClass API, right?.

    I don't think setConfigClasses is a valid API in JavaConfigApplicationContext anymore since M4.

    Appreciate your help.

    Best regards
    Arul

  • #2
    Hi Arul,

    Working against the latest M5 snapshot, the following works fine for me
    Code:
    package org.springframework.config.java.context;
    
    import static org.hamcrest.CoreMatchers.equalTo;
    import static org.junit.Assert.assertThat;
    
    import org.junit.Test;
    import org.springframework.config.java.annotation.Bean;
    import org.springframework.config.java.annotation.Configuration;
    
    public class TempTests {
        @Test
        public void test() {
            JavaConfigApplicationContext initialContext = new JavaConfigApplicationContext(ThreadConfig.class); 
            
            JavaConfigApplicationContext finalContext = new JavaConfigApplicationContext();
            finalContext.setParent(initialContext);
            finalContext.addConfigClass(AppConfig.class);
            finalContext.addConfigClass(DataConfig.class);
            finalContext.refresh();
            
            finalContext.getBean(ThreadConfig.class);
            finalContext.getBean(AppConfig.class);
            finalContext.getBean(DataConfig.class);
            
            assertThat(finalContext.getBean(String.class), equalTo("foostring"));
        }
        
    }
    
    @Configuration class ThreadConfig {
        public @Bean String foo() { return "foostring"; }
    }
    @Configuration class AppConfig { }
    @Configuration class DataConfig { }
    Thanks also for the correction on the documentation. It has been updated to reflect using addConfigClass() and addBasePackage() vs the older-style methods that have now been removed.

    Comment


    • #3
      Thanks Chris for the update.

      I will try with M5.

      -Arul

      Comment

      Working...
      X