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
The Status of Java-config Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Status of Java-config

    Hi, Chris!

    I'd like to understand the current status of Java-config / Java-based container configuration.

    In my humble understanding the work on standalone Java-config project is stale since 1.0.0M4 in favor of integration with Spring3, so generally, there is not reason to sick to it.

    On the other hand, the current implementation in Spring3 RC2 is only a subset of the standalone Java-config capabilities. A lot of features, existing in 1.0.0M4 simply do not exist in Spring3 RC2. E.g. - @AspectJAutoProxy, @AnnotationDrivenTx, etc.

    Generally, Release Candidate implies that feature-freeze. Does it mean final version of Spring3 Java config won't have those critical features?

    When considering using Java-config for new project, which path should I take?

    Thanks,
    Baruch.

  • #2
    Hi Baruch!

    If you're starting out with a new project, Spring 3 is the way to go. As you've noticed, most but not all of the JavaConfig features have made their way into Spring 3. And the features that are not there will be added incrementally based on user demand and thinking about the best way to implement them going forward.

    For example, @AspectJAutoProxy works nicely, but this is not an approach that we want to commit to in Spring core. It suggests that every namespace and element should have an annotation-based equivalent, and that duplication of efforts is not ideal.

    There are several ideas on the table for how to leverage the power of Spring's namespaces without leaving Java, but in the meantime, we've provided a simple mechanism to import Spring XML files from within a @Configuration class. In JavaConfig this was called @ImportXml, today in Spring 3.0 it is called @ImportResource.

    You'll find that JIRA issues have been created for most JavaConfig features missing from Spring 3. If you have others, or any additional requests, please don't hesitate to file an issue.

    Comment


    • #3
      OK, so generally, there is some regression in functionallity, and we need to fallback to XML for everything that we miss. OK, fair enough, as long as those gaps are going to be closed.

      Thanks!

      Comment


      • #4
        Exactly, thanks for understanding. Always better to add functionality later than need to remove something added hastily now

        Comment


        • #5
          so where can we see...

          @ComponentScan is pretty important to me, as are some of the other missing features from spring java config. Is there a way that we can track this?

          Also ImportResource is nowhere near as friendly as ImportXML is/was...

          Comment


          • #6
            I've filed SPR-7194 for including @ComponentScan in Spring Core. Please vote for the issue if you'd like.

            http://jira.springframework.org/browse/SPR-7194

            Comment


            • #7
              liamcoughlin & sirianni, I have a question for you, guys.
              Why @ComponentScan is so important?
              AFAIK when you construct you ApplicationContext using AnnotationConfigApplicationContext and provide base package as argument, you achieve component scan starting this package without XML.

              Comment


              • #8
                Originally posted by jbaruch View Post
                liamcoughlin & sirianni, I have a question for you, guys.
                Why @ComponentScan is so important?
                AFAIK when you construct you ApplicationContext using AnnotationConfigApplicationContext and provide base package as argument, you achieve component scan starting this package without XML.
                I think the main reason for me is abstraction. For example, the main class that is instantiating the AnnotationConfigApplicationContext may only know of a single top-level @Configuration class to register with the context. That @Configuration class may then @Import other @Configuration classes which may themselves wish to do subpackage level component-scans. Your suggestion of simply having the main class that is instantiating the context perform these subpackage-level component-scans breaks the encapsulation that I am trying to get by composing @Configuration classes.

                There are also situations (e.g. when using @ContextConfiguration for JUnit testing) where you don't control the instantiation of the ApplicationContext, so you don't have a hook to explicitly call the scan() method. In this case it would also be useful to have the @Configuration class itself be able to declaratively specify the need for the component scan to happen.

                Comment


                • #9
                  This is an important issue. You may want to put a watch on SPR-7420, which covers Spring 3.1 programmatic support for configuration switches like component scanning, annotation-driven tx, etc.

                  Comment


                  • #10
                    sirianni, I see your point. You are right, SPR-7420 should give us more power.

                    Comment

                    Working...
                    X