SpringSource releases Spring 2.5, enhancing annotations

Home

News: SpringSource releases Spring 2.5, enhancing annotations

  1. SpringSource, formerly known as Interface21, has announced the release of version 2.5 of the Spring Framework. With a focus on delivering enhanced annotation options, this latest release completes Spring 2.0's mission of providing the most flexible, most comprehensive configuration model for both Java 1.4 and Java 5. Spring 2.5 extends the framework's core themes of flexibility and power by providing an extensive set of configuration approaches, with an emphasis on comprehensive support for configuration annotations. Building on Spring’s current support for XML schema namespaces and various configuration annotations, this latest version introduces support for JSR 250's @PostConstruct, @PreDestroy and @Resource, Java EE 5's @WebServiceRef and @EJB, and Spring’s own @Autowired. Spring 2.5 allows developers to employ configuration annotations at varying levels, from configuration hints in component classes to self-sufficient components which express their entire configuration through annotations. At the same time, the framework maintains its support for the classic Spring configuration approach. Additional key features and enhancements of Spring 2.5 include:
    • Comprehensive support for Java 6 and Java EE 5 APIs – Includes support for JDBC 4.0, JAX-WS 2.0, JTA 1.1, JSF 1.2. Spring 2.5 takes full advantage of Java 6 and Java EE 5 when deployed onto those platforms.
    • Enhanced support for web controllers – Allows for writing annotated web MVC controllers without implementing specific interfaces or deriving from specific base classes. Also facilitates configuration of Spring MVC and places Spring MVC on a convergence path with Spring Web Flow 2.0.
    • Improved testing capabilities – Introduces the new annotation-based TestContext framework for integration tests, supporting Junit 4, TestNG, and Spring 2.5's core configuration annotations for test classes and providing flexible test context configuration through annotations.
    • Autodetection of components in the class path – Enables autodetection of components in the class path, including the use of stereotype annotations such as @Repository, @Service, @Controller or the generic @Component. Also allows developers to avoid explicit XML bean definitions completely, with annotated components in the specified packages registered implicitly.
    • Extended AspectJ integration – Introducing the new bean name pointcut designator as well as built-in support for AspectJ load-time weaving.
    • Enhanced messaging support – Integrates with JCA message endpoint management, and provides the new "jms" configuration namespace for simplified message listener configuration.
    Spring 2.5 is currently available. For more information and to download the software, visit http://www.springframework.org/download. SpringSource offers commercial development and production support for the Spring portfolio of products as well as updated training and professional services for the Spring Framework 2.5. For more information about these products, visit http://www.springsource.com. Like previous versions of the Spring Framework, Spring 2.5 runs on all web containers and application servers, as well as in standalone environments. It continues to run on Java 1.4 and above as well as J2EE 1.3 and above, allowing customers to protect their investments in existing technologies while being able to take advantage of the latest features that are available only in Java 6 and Java EE 5. Like previous Spring Framework releases, Spring 2.5 is fully backward compatible, offering a natural upgrade path.

    Threaded Messages (25)

  2. Why not just Spring?[ Go to top ]

    Why not just name your company Spring Inc.? Is that already trademarked/taken or something? -- Bill Burke http://bill.burkecentral.com
  3. Re: Why not just Spring?[ Go to top ]

    Why not just name your company Spring Inc.? Is that already trademarked/taken or something?
    Anticipating the future, why not a straight-out www.oracle.com?
  4. Re: Why not just Spring?[ Go to top ]

    No please Oracle NO. Just "Spring Source" that's great and keep independant and opensource.
  5. Re: Why not just Spring?[ Go to top ]

    Why not just name your company Spring Inc.? Is that already trademarked/taken or something?

    --
    Bill Burke
    http://bill.burkecentral.com
    Why not just house your blog at http://bill.assholecentral.com
  6. For a detailed introduction to Spring 2.5, including examples of the new features, see my recently revised Introduction to Spring article. Rod Johnson - SpringSource
  7. Congratulations for the new enhancements! IMHO Spring is the state-of-art of j2ee IoC frameworks.
  8. Thank Rod for giving us such an awesome framework.I am glad I was not alone to think how badly EJB was designed years ago when then EJB experts was touting it's virtue. http://www.theserverside.com/discussions/thread.tss?thread_id=771#26211 Regards, RJ
  9. personally, i hate to see annotations used this way and prefer to keep configuration out of my domain objects. thats not to say i don't like using java for configuration, in fact i completely agree with bob lee's arguement about using type-safe configuration rather than un-typed XML. I like to see SpringSource pushing their JavaConfig much harder (http://www.springframework.org/javaconfig), I moved a project from XML -> JavaConfig and didn't have to make any domain changes, and have type-safe configuration that can be refactored using my standard IDE.
  10. Spring Java configuration[ Go to top ]

    I like to see SpringSource pushing their JavaConfig much harderhttp://www.springframework.org/javaconfig), I moved a project from XML -> JavaConfig and didn't have to make any domain changes, and have type-safe configuration that can be refactored using my standard IDE.
    We're now pushing forward vigorously with Spring Java Config and are aiming to get it into a final release. I recently blogged about our plans for the project. I'm glad you had a good experience with Spring Java Configuration. I believe it is a compelling approach and we are fully committed to it. I recently spoke at QCon San Francisco about the different options for configuring the Spring container, including Spring Java config. My slides are available as PDF, and should help convey how we feel the different approaches fit together. Rgds Rod
  11. personally, i hate to see annotations used this way and prefer to keep configuration out of my domain objects.
    Btw, the new classpath scanning functionality isn't purely annotation specific. As usual with Spring, it's flexible and pluggable. For example, it's possible to use the new TypeFilter interface to pick up classes based on any criteria you please. This can work even with existing code. With Spring 2.5, whether or not you want to use annotations or not is your business. Either way, Spring will give you the best available support for configuration, as well as a host of other, fully integrated, services.
  12. Congrats to Rod and his team for this new release. I am not a Spring fan, I rather stick to EJB3, but it is great to see an alternative to EJB3. The truth is, the EJB3 spec has a lot to thank to Spring :) Regards, Paul Casal Sr Developer - jbilling.com The Enterprise Open Source Billing System
  13. IntelliJ IDEA Spring support[ Go to top ]

    I moved a project from XML -> JavaConfig and didn't have to make any domain changes, and have type-safe configuration that can be refactored using my standard IDE.
    I've just upgraded to IntelliJ IDEA 7, which supports refactoring across Java and Spring XML config files. It also provides code completion (class names, property names, bean refs, etc) and error highlighting within the XML files. Very nice. (I have no affiliation with JetBrains / IntelliJ :) Al.
  14. Re: IntelliJ IDEA Spring support[ Go to top ]

    Alastair Yes, IDEA 6 introduced Spring support and it's further improved in 7. Kudos to the JetBrains guys. For Eclipse users, Spring IDE is a great option. It can visualize and help to manage configuration from multiple sources--XML, Java Configuration etc. Expect support for the full range of Spring 2.5 configuration capabilities before long. SpringSource is also investing heavily in a tooling initiative--the Spring Tool Suite--that will combine the Eclipse Mylyn project with Spring IDE, AJDT (the AspectJ plugin) and other enterprise plugins to provide a great environment for enterprise development with Spring. This will be available to our subscription customers (although the many enhancements to the open source components will go back into those projects, and be available independently). Stay tuned for an update at The Spring Experience in December. We really believe that Mylyn is a game-changer in terms of Eclipse experience, and are delighted to be working with the Mylyn team, who share our commitment to innovation and productivity enhancement. Rgds Rod
  15. First I would like to say congratulations to SpringSource on the new name. Second, I have a few questions and comments I would like to share. It's good to see the Spring framework moving towards adoption of Java annotations as the basis for bean configuration. After using XML-based Spring configuration for years now, and Seam's annotation based configuration for about 6 months, I definitely prefer annotations. It's a bit confusing to get the lowdown on Spring's annotation injection. I've tried a few times now but I still don't get it. It took me almost no time at all to learn Seam's @In annotation. For example, a Google search on Spring annotations points to the Java.net project (Spring annotations) while this article points to another implementation called Spring JavaConfig. Which is the authoritative source? Are these two efforts identical, compatible, competitive? I know Spring Modules was created in the last couple of years to support extending the Spring framework. Is there overlap between the core framework and the modules? How is development coordinated to avoid duplication of effort, ensure consistency, etc.? In the Spring microcosm, are there standards for the framework itself (i.e. when a module and the core framework overlap) in the way J2EE servers have to conform to a specification? Rod I appreciate your contributions to the Java community and that you continue to post articles to this site about the Spring framework. I enjoy reading your books (actually I teach a J2EE course and "J2EE Design and Development" is one of our texts). I did not learn anything new in your October 2007 article that I didn't learn a few years ago when I was introduced to the Spring framework. It would be nice to highlight the new features of the framework such as annotation-based dependency injection, JPA support, etc. We already know "Why Spring", architectural benefits, Hollywood principle, etc. This information is widely available. Now, on to something new - Spring's JavaConfig. After a first pass over the documentation, I gather that the XML bean configuration schema has been ported to annotations. So you can have @Configuration at the class level to define the application context, and @Bean at the method level to define beans. Is there a reason why the examples of @Bean usage in the documentation do not use getter methods? Also, is field-level injection supported? I would have expected something similar to Seam's @Name("beanName") and @In annotations. What could be simpler: @Name("myBean") @Scope(ScopeType.SESSION) public class MyBean { } @Name("anotherBean") @Scope(ScopeType.SESSION) public class AnotherBean { @In(create=true) private MyBean myBean; } In this example, Seam uses reflection to inject the bean named "myBean" into the field named "myBean". How do I do this in Spring? A simple example would be good. Are we supposed to use JSR-250's @Resource to achieve similar results? Also, how do @Service, @AutoWired, @Component, etc. relate to the JSR-250 annotations and to JavaConfig annotations? I noticed a blog post giving an overview and there is some discussion in your support forum, but where is the formal documentation? And where are the examples? It would be nice to see the annotation-based approach given the same validity (and coverage in the documentation) as the XML approach. I use Spring in my Seam/JSF/EJB3 applications as part of my service layer, but I find the XML configuration approach is much slower to work with and harder to maintain than annotation-based configuration. Hopefully this situation will improve via Spring's JavaConfig. It would be nice to see some serious effort given to this area of the framework after two years. Ian Hlavats JSFToolbox for Dreamweaver: JSF UI Design and Development
  16. This might help What's New in Spring 2.5: Part 1
  17. This might help What's New in Spring 2.5: Part 1
    Thanks. So the example I gave above could be written as follows in Spring: @Component @Scope("session") public class MyBean { } @Component @Scope("session") public class AnotherBean { @Autowired private MyBean myBean; } Good to know! (Don't forget the context:annotation-config and context:component-scan declarations in applicationContext.xml.) I found the relevant info in the new Spring 2.5 documentation for anyone else looking for the same: http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config PS: Kudos to the Spring team on the performance improvements in 2.5. Startup time for one of my apps (450+ beans) is significantly faster. It would be interesting to know: Which is faster? XML or annotation-driven configuration?
  18. So the example I gave above could be written as follows in Spring:

    @Component
    @Scope("session")
    public class MyBean {
    }

    @Component
    @Scope("session")
    public class AnotherBean {

    @Autowired
    private MyBean myBean;

    }



    This looks quite similar to WebBeans style. Here's a snippet from Gavin's WebBeans presentation. public @SessionScoped @Component class Login { private User user; public void login() { user = ...; } public User getUser() { return user; } }
  19. If you annotate fields using @Autowired and then remove any setters, is it still possible to unit test with mocks? Normally I would create a JMock2 DAO and stick it on using the setter. Are you not a bit tied to the container if you do this?
  20. Answering my own question there is now ReflectionTestUtils.setField in spring-test. See chapter 8 of the docs.
  21. Unit testing Field Injection[ Go to top ]

    Martin Indeed, unit testing classes with injected fields is harder. In most cases, I wouldn't regard Field Injection as a best practice. It does mean that you're writing code that you wouldn't write without a container, and that partly defeats the purpose of DI. There are four reasons we added this feature:
    • As we were supporting the Java EE 5 @Resource annotation we needed to allow it to work in all the places that the specification allows, which includes fields. Thus, logically, our own more powerful @Autowired annotation should support the same range of targets.
    • As we want Spring to be the ultimate component model, people shouldn't need to turn to other solutions for a particular requirement, regardless of whether we like it. We've always taken a non-ideological approach.
    • It was easy to add to the container so it didn't bloat it or impair maintainability
    • (The most important factor) There are some legitimate use cases for Field Injection, where it's useful because it's concise.
    Two examples of the last point (I'm sure there are more):
    1. DAO implementation classes. You can't unit test these meaningfully anyway (they use JPQL, SQL etc.), so you may as well use the economy of Field Injection. Injecting an EntityManager, for example.
    2. Java Configuration @Configuration classes.
    I would not recommend using Field Injection in normal business objects that you want to unit test. And even with that reflection utility method, setting fields in tests still seems a bit clunky to me, and lacks type safety. Rgds Rod
  22. Re: Unit testing Field Injection[ Go to top ]

    Cheer Rod. Most of the examples I had seen used field annotation, as well as highlighting the reduced "clutter" of the setters and enforcing immutability. I had written a few services and unit tests, and it quickly became apparent that using reflection utils can become messy. As you say you end up typing a lot of field names as strings. Thanks for clarifying what you consider a best practice. I'd also just like to commend the Spring team on the new testing framework. Everything is much slicker now and it's good to see TestNG support.
  23. Ian, That article should definitely be helpful for the specific questions you raised. Also, you may want to check out the 'Annotation-based configuration' section of the Spring 2.5 documentation: http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config Hope that helps, Mark
  24. Ian Thanks for the thoughtful post.
    For example, a Google search on Spring annotations points to the Java.net project (Spring annotations) while this article points to another implementation called Spring JavaConfig. Which is the authoritative source? Are these two efforts identical, compatible, competitive?
    The Spring Annotations project is not part of the Spring Portfolio and not endorsed by the core Spring team. The annotation support in the Spring Framework 2.5 replaces any need for this add-on project. Spring Java Config is part of the Spring Portfolio, and therefore an official Spring sub-project. It is a complementary alternative to the annotation configuration in 2.5. The recent presentation I mentioned above describes my thoughts on how they fit together. The gist: the annotation support in the Spring core introduced in 2.5 is based around annotations on business object classes, methods and fields. The Spring Java Config project takes a quite different approach, using annotations in configuration classes themselves to create a kind of configuration DSL. Those approaches are not mutually exclusive. We see the Spring container being configured by different contributions. XML and other non-annotation configuration can be mixed with either.
    I know Spring Modules was created in the last couple of years to support extending the Spring framework. Is there overlap between the core framework and the modules? How is development coordinated to avoid duplication of effort, ensure consistency, etc.?
    Spring Modules is partly an incubator, partly to support code that is not of interest to enough users to go in the core Spring Framework or a top-level subproject. The Spring Portfolio is carefully managed by SpringSource to avoid duplication--of course, with the input of the community. We operate an integrated project plan. The aim is to produce the most comprehensive set of solutions for the enterprise, which are designed to be used together. We are making explicit the coordination and management through a synchronized release cycle or "Release Train" (a la Eclipse). What you see at SpringFramework.org on the subprojects page is the definitive guide to what's official Spring.
  25. Spring Java Config[ Go to top ]

    After a first pass over the documentation, I gather that the XML bean configuration schema has been ported to annotations. So you can have @Configuration at the class level to define the application context, and @Bean at the method level to define beans.
    Yes, the metadata holds similar information. But Java configuration gives you the flexibility of a Java method body to instantiate your bean. The bean, once instantiated, will benefit from all Spring's services, and can be injected anywhere else, so it's a significant advance on simply instantiating the class yourself without Spring. Configuration classes can also participate in inheritance hierarchies, which is an interesting benefit. For example, you could leave some @Bean or @ExternalBean or other methods abstract and force users to fill in the blanks. I initially described the usage model in my blog here.
    Is there a reason why the examples of @Bean usage in the documentation do not use getter methods? Also, is field-level injection supported?
    I'm not sure I understand the question. The default for an @Bean method is for the bean name to be the method name. So unless you want beans named "getWhatever" you wouldn't use getters. Also, such methods, which create an object that may subsequently be cached, don't match up with the typical semantics of getters. Field-level injection is supported since 2.5 in any object. An @Configuration class can itself by injected, so you can inject any fields you like on it. When you create objects in the body of @Bean methods, you can invoke fields if they're accessible, but of course it's not usually good practice to expose fields to make them accessible to Java code. Thanks for the questions. Rgds Rod
  26. Re: Spring Java Config[ Go to top ]

    Is there a reason why the examples of @Bean usage in the documentation do not use getter methods? Also, is field-level injection supported?
    I'm not sure I understand the question. The default for an @Bean method is for the bean name to be the method name. So unless you want beans named "getWhatever" you wouldn't use getters. Also, such methods, which create an object that may subsequently be cached, don't match up with the typical semantics of getters. Thanks for the replies Rod. Actually I was confused about the various annotation sets in Spring. I see now that Spring Java Config provides an annotation-based configuration model. I was looking for something like the stereotype and autowire annotations to do basic dependency injection and was unsure where to look. Everything is clearer now! :-)