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
JavaConfig 1.0 Release Date? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JavaConfig 1.0 Release Date?

    Hi, when can the 1.0 release of Spring JavaConfig be expected? I checked the Spring JavaConfig site and didn't see a release timeframe.

    I'm considering using JavaConfig in one of my projects and would feel better if JavaConfig was nearing a 1.0 release.

  • #2
    Hello! I'm glad to see you're interested in JavaConfig. While the exact date for 1.0 is not yet set, there's good news! The bulk of JavaConfig functionality will be available in the core Spring Framework in the 3.0 release, which is due in this June.

    So if you like, you can stay tuned to the 3.0 milestone releases. In the upcoming 3.0M3 release you'll see the first support for @Configuration and @Bean.

    You can start using JavaConfig today in your project and while there will be some migration (mainly package names) to do once Spring 3.0 is released, you can rest assured that the functionality will be supported right in the core, and that's a good thing.

    One note - if your project cannot be released while depending on a JavaConfig milestone (currently M4), and it also cannot tolerate changing APIs, you may not want to use JavaConfig right now. If you need total stability, it may be best to wait for Spring 3.0 GA.

    Regards,

    - Chris

    Comment


    • #3
      That is excellent news. I was hoping the Spring JavaConfig would make it into the core. I always thought it belonged there. But so far, it has served me well and it only required one extra jar file.

      I really like less XML and more Java code. I still have a sliver of XML:
      Code:
      <?xml version="1.0" encoding="UTF-8"?>
      <beans xmlns="http://www.springframework.org/schema/beans"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xmlns:context="http://www.springframework.org/schema/context"
      	xsi:schemaLocation="
      	http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
      	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
      
      	<bean class="myapp.AppConfig"/>
      	
      	<bean class="org.springframework.config.java.process.ConfigurationPostProcessor"/>
      	
      	<bean id="securityAspect" class="myapp.aop.SecurityAspect" factory-method="aspectOf">
      		<property name="securityInterceptor"><ref bean="securityInterceptor"/></property>
      	</bean>
      
      	<context:load-time-weaver/>
      	
      </beans>
      Any chance that these parts will be able to be replaced in the future with Spring JavaConfig? What is holding me back is the need to load-time weaving for AspectJ available, and also the aspectOf factory method provided with @AspectJ.

      Comment


      • #4
        Many thanks for the reply Chris. That is great news. Keep up the good work!

        Comment


        • #5
          Greg,

          For the initial cut of @Configuration support in Spring 3.0, there will still be some XML required. You'll be glad to know, however, that you won't need to declare ConfigurationPostProcessor. @Configuration class detection and processing will be on by default when you use <context:annotation-config/> or <context:component-scan/> (remember that @Configuration is a @Component, so @Configuration classes may be component-scanned).

          We'll gauge user reactions and usage patterns after the M3 release and see what's next.

          - C

          Comment


          • #6
            Originally posted by Chris Beams View Post
            For the initial cut of @Configuration support in Spring 3.0, there will still be some XML required. You'll be glad to know, however, that you won't need to declare ConfigurationPostProcessor. @Configuration class detection and processing will be on by default when you use <context:annotation-config/> or <context:component-scan/> (remember that @Configuration is a @Component, so @Configuration classes may be component-scanned).
            Okay, so I can replace
            Code:
            <bean class="myapp.AppConfig"/>
            with <context:annotation-config/> or <context:component-scan/>, and then it will get picked up automatically. And other annotated stuff would be also getting picked up under that umbrella.

            That is one less piece of XML. It certainly makes sense to get a stable release out, then get it integrated with the latest stable release of Spring Framework. I have no doubt that load time weaving will eventually work its way into being supported.

            You guys have done great at seamlessly integrating with current XML, so people can easily migrate over to this. That is what I REALLY value about SpringSource...making it easy to transition parts of the baseline with no impact to my development schedule.

            --Greg

            Comment


            • #7
              One correction to the above:

              You'll be able to replace
              Code:
              <bean class="myapp.AppConfig"/>
              With
              Code:
              <context:component-scan base-package="myapp"/>
              But, if you're using just annotation-config, your configuration would still need to look like the following:
              Code:
              <context:annotation-config/>
              <bean class="myapp.AppConfig"/>
              In either case, @Configuration class processing is on by default, but in one case you're scanning for those classes, and in the other you're explicitly declaring them. The main point is that you don't have to manually register the low-level ConfigurationPostProcessor anymore.

              Comment

              Working...
              X