Spring Framework 3.0 M3 released

Juergen Hoeller

We are pleased to announce that the third Spring 3.0 milestone is available now (download page)! This release comes with many new features and refinements, including…

Reference documentation: M3 is the first Spring 3.0 milestone that comes with reference documentation, in both HTML and PDF format. Even if the documentation is still a work in progress, it does cover many 3.0 feature areas at this point already. We hope that you'll find this early cut of the documentation useful for learning more about the 3.0 milestone features.

Annotated factory methods: Spring 3.0 M3 includes the core functionality of the Spring JavaConfig project, namely configuration classes with annotated factory methods that define managed beans.

@Bean @Primary @Lazy
public RewardsService rewardsService() {
return new RewardsServiceImpl(…);
}

Such factory methods are supported on any annotated component class (e.g. plain @Component classes), building and exposing bean objects based on the component's state. They will simply be treated as further bean definitions derived from that component class, in addition to the bean definition for the containing component. The default name for such a bean definition is the name of its factory method (in the example above: "rewardsService"). Those bean instances will be obtained through factory method calls whenever the container needs to obtain a fresh instance. This is semantically close to XML bean definitions with a factory-bean/factory-method reference.

Beyond simple factory methods, we support the JavaConfig mode of operation as well: If factory methods are defined on a class marked with the @Configuration annotation, then special behavior applies… Factory methods on such explicit configuration components are allowed to call other factory methods on the same component, with those internal factory method calls being rerouted through the container! This allows for building graphs of container-managed bean instances, with the builder code simply consisting of chained Java factory method calls. Like the original JavaConfig project, we are generating CGLIB subclasses of such configuration classes in order to provide those extended semantics.

Note that annotated factory methods can be mixed and matched with XML bean definitions in a seamless fashion. They can also be mixed and matched with regular annotated component classes, reusing many common annotations such as @Scope, @Lazy, @Primary, and @Qualifier. Components containing annotated factory methods may be defined in XML or detected through component scanning in the classpath. Basically, the same rules as for any regular Spring beans apply; this is now a natural extension of Spring 2.5's support for annotated components.

Extended support for meta-annotations: Spring's @Scope and @Transactional annotations, as well as specialized stereotypes such as @Service and @Controller, can be applied as meta-annotations on custom annotations now. For example:

@Service
@Scope("request")
@Transactional(rollbackFor=Exception.class)

@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}

@MyService
public class RewardsService {

}

This is a powerful way of defining custom stereotype annotations with extended default semantics as shown above. Alternatively, you may build simple custom scope annotations: e.g. a custom @RequestScoped annotation marked with @Scope("request"), or custom transaction annotations: e.g. @MyTx marked with @Transactional(rollbackFor=Exception.class). In other words, this allows for creating convenient shortcut annotations for your preferred configuration variants!

TaskScheduler abstraction: Spring provides a full-fledged scheduling facade API now, including adapters for standard ScheduledExecutorServices and also CommonJ TimerManagers. This comes with a Trigger abstraction and a CronTrigger implementation for simple scheduling based on cron expressions. In 3.0 RC1, we'll be adding a scheduling namespace for convenient XML-based configuration on top of this.

New type conversion SPI and converter API: Inspired by the capabilities of Spring Web Flow's binding subsystem, Spring supports stateless Java 5 based type converters now. This has been integrated with Spring 3.0's expression parser already and will be fully supported as an alternative to standard JDK PropertyEditors for all Spring binding purposes in 3.0 RC1. Likewise, Spring Web Flow 3.0 will be using this new unified conversion subsystem as well.

We are now moving on to Spring 3.0 RC1 which is scheduled for release in June. A major new feature planned for RC1 is support for annotation-based validation: specifically, the integration of JSR-303 Bean Validation providers. We are also researching refinements to the start/stop lifecycle in ApplicationContexts and are working on a serializability solution for Spring-managed scoped proxies. Watch this space!

P.S.: We are about to release a completely revised version of the good old PetClinic sample application, as a showcase for a modern Spring 3.0 web application, which will be available in a separate distribution. Keith will be blogging about this within the next couple of days.

Similar Posts

Share this Post
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Slashdot
  • Technorati
  • TwitThis
 

23 responses


  1. Hi there, congrats on this release, I'm looking forward to testing out the RESTful aspects.

    We're big users of Maven, so any chance that this milestone release will make it into the Spring repos in the next couple of days?

    Cheers,
    Martijn


  2. Ah, nevermind, I forgot about the new OSGI naming impact on the artifact id, ignore my previous comment :)


  3. Martiijn and all other Maven users:

    Check out http://twitter.com/kdonald/status/1718829231. You can use the mentioned Petclinic 3 sample .pom as a reference.

    Note this .pom pulls from maven.springframework.org, a repository that is compatible with Maven Central artifact ids. The release is also published in our bundle repository for those running in an OSGi environment.


  4. Thanks for the 3.0 reference guide :D Extended meta-annotations is really cool. Will we see the same thing with MVC annotations? For example: @RequestMapping(value="/users/{id}", method=RequestMethod.GET) for @Get("/users/{id}").

    I would love to see declarative validation in groovy, maybe with validator DSL or allow the MVC to use Grails validator.


  5. Can't download from amazon s3 site due to restrictions from office. Don't you have alternate sites for download?


  6. All these annotation things sound great; however, they inject proprietary stuff right into java sources. I am not comfortable with that, though I understand how it will be beneficial for your company.

    I hope xml configuration will continue to be fully supported for all spring functionality.


  7. Dimitris,

    XML configuration is not going anywhere.

    But I think you're actually missing the way that annotations like @Configuration and @Bean work. As opposed to something like the @Autorwired annotation introduced by Spring 2.5, which lives inside the code that is being injected, @Configuration and @Bean allow you to created externalized configuration definitions expressed as Java with annotations. Think of it like a Java equivalent of an XML application context definition. The annotations are generally not in the Java source that is being injected, but in an external class file.

    So basically, Spring users have the ability to use whatever combination of XML, internal (invasive) annotation and externalized annotation config that makes sense for them, their company, and the particular application and use case.

    Regards,
    Colin


  8. Dimitris,

    Of course XML configuration continues to be fully supported! As a matter of fact, the Spring core container still does not know about a single annotation… They all come in through post-processors and other strategies. The BeanDefinition object model – and its XML equivalent as the most direct metadata mapping – remain to be the core of the Spring container. We are also adding further XML namespaces in Spring 3.0, such as the scheduling namespace.

    As for our "proprietary" annotations, we try hard to make them useful on a general basis, not just for Spring purposes – even if they happen to live in an "org.springframework" package. Our annotations usually have a descriptive characteristic about them as well; they allow the container to derive default behavior from them, but they do not strongly tie the annotated class to Spring. In other words, we try hard to keep our use of annotations down to earth.

    That aside, we are also keen on standardizing a useful set of core annotations – exactly because we think it would generally be preferable to have javax.* annotations instead of org.springframework.* annotations in your domain model. JSR-250 ("Common Annotations for the Java Platform") was a good start that gave us @PostConstruct, @PreDestroy and also @Resource. JSR-303 ("Bean Validation") provides standard constraint annotations for use in domain classes, which we will be supporting in Spring 3.0 RC1. And now we are even proposing a standard set of DI annotations in partnership with Google: http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html

    Juergen


  9. I want to make a feature request to make sure Dreamsource ORM to work in Spring seamless. How do I do it? I can not find any link. Please drop me an email. There are some examples of Spring-Dreamsource ORM in http://www.leeonsoft.com.

    Jim


  10. Hi,

    I was playing with the Petclinic sample application and I found out that the dependency for quartz is wrongly defined in spring-context-support. The groupId should be opensymphony not quartz anymore.

    On the other hand everything is perfect, I loved the RestTemplate, simple but powerful, thanks.

    Umut


  11. Hi

    I'm using the maven settings from the twitter link you provided however it looks like spring-core depends on spring-parent and the latter is missing from the repository:

    [INFO] Unable to find resource 'org.springframework:spring-parent:pom:3.0.0.BUILD-SNAPSHOT' in repository org.springsource.maven.snapshot (http://maven.springframework.org/snapshot)

    Can this be fixed?

    Cheers,
    Jon


  12. Apologies for the double (now triple) posting, however yesterday this blog had captcha verification without showing a captcha image, so i assumed it had rejected my post.

    jon


  13. Hi all,

    i have problems to build the framework. I googled around but did not find a solution. Whenever i tried to build the framework i got the following output:

    joerg@belloStoneOne:~/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/build-spring-framework$ ant



    BUILD FAILED
    /home/joerg/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/spring-build/multi-bundle/artifact.xml:45: The following error occurred while executing this line:
    /home/joerg/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/spring-build/multi-bundle/common.xml:71: The following error occurred while executing this line:
    /home/joerg/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/spring-build/common/common.xml:87: impossible to configure ivy:settings with given file: /home/joerg/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/spring-build/common/ivysettings.xml : java.text.ParseException: failed to load settings from file:/home/joerg/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/spring-build/common/ivysettings.xml: impossible to define new type: class not found: org.springframework.aws.ivy.S3Resolver in [] nor Ivy classloader

    I found some entries in the spring-forum that the problem can be a ivy.jar in $ANT_HOME/lib but i am sure, my ANT is ivy-free.
    I have only "java" and "ant" in required versions in my path:

    joerg@belloStoneOne:~/DEVELOPMENT/WORK/SPRING/spring-framework-3.0.0.M3/build-spring-framework$ echo $PATH
    /usr/lib/jvm/java-6-sun-1.6.0.13/bin:/home/joerg/DEVELOPMENT/JAVA/apache-ant-1.7.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

    What did i wrong?


  14. Joerg,

    If you are sure your …/ant/lib dir does not have an old version of Ivy in it, also look inside your ~/.ant/lib directory. I started getting the same build issue actually, and something had actually placed an older version of Ivy there. When I removed the Ivy jar under that home location, the build worked fine.

    Colin


  15. Thank you Colin,

    that was the problem. I found an ivy.jar in ~/.ant/lib. After removing it the build runs as expected. Don't know who placed it there.

    Thank you again.

    MfG
    Jörg


  16. Has anyone else come across a MalformedParameterizedTypeException when using 3.0.0.M3

    I tried building my app against 3.0.0.M3 and came across this while running my integration tests (more specifically – while creating a LocalSessionFactoryBean ).
    The strange thing is that it seems to work under certain circumstances (a simpler set of tests).

    If I can narrow this issue down a bit further I will log this bug.

    Donnchadh


  17. I encountered the MalformedParameterizedTypeException as well. Apparently this exception occurs when a mixture of spring 3.0 and spring 2.5.6 (or lower) are on your classpath. For me this was the case because I'm also including the spring-flex project, which still has dependencies on some spring 2.5.6A artifacts. After adding explicit exclusions for those artifacts in my pom, I'm no longer getting the MalformedParameterizedTypeException.


  18. I am using the M3 release for a REST MVC implementation. I am having an exception being throwed when using the @RequestBody annotation.

    Somewhere in the process, the Content-Type is being tested but the method getHeaderNames is converting them in lower case. The getContentType with the constant in CONTENT_TYPE (defined as Content-Type) in HttpHeaders class always returns null…
    Could you help me fix this?

    My request is a post request with Content-Type : text/xml.


  19. We've just posted short overview of new Spring 3.0 M3 features on Ukrainian software developers site – http://www.rozrobka.com/blog/java/14.html


  20. I have upgraded my project to use Spring 3.0.M2. When trying to access my application I am getting the below error.

    org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/LogReaderDispatcher-servlet.xml]; nested exception is java.lang.NoClassDefFoundError: org/springframework/core/type/classreading/AnnotationMetadataReadingVisitor

    Even I have spring.core jar dependency in my web-inf/lib folder. Can any one please give me the suggestion to solve this problem?

    Thanks in Advance,
    Ramesh.


  21. Hi,
    We just tried to upgrade to spring 3M3 and faced following issues:–
    1. Spring 3.0 M3 jars have spring 2.5 xsd, while in the reference document it says to use spring 3.0 xsds. Are we expect to use 2.5 xsd or 3.0?

    If we use xsd 2.5 references, it looks for ‘org/aopalliance/intercept/MethodInterceptor’ while trying to create bean for ‘dataSourceSessionAwareProcessor’ and throws an error. The stack trace is as follows:–

    Thu 6/25/09 13:00:24: Tomcat main: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSourceSessionAwareProcessor' defined in class path resource [config/mvc/mvc.xml]: Cannot resolve reference to bean 'dataSourceSession' while setting bean property 'session'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSourceSession' defined in BeanDefinition defined in class path resource [config/mvc/mvc.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/aopalliance/intercept/MethodInterceptor

    It seems org/aopalliance/intercept/MethodInterceptor class have been removed for the spring 3.0 M3 jars. do we expect to use 'aopalliance' jar files separately?

    Thanks in advance,

    Pranay


  22. Juergen, you said Spring 3.0 RC1 is scheduled for release in June. Can you give a new estimate now that it's August? Are there problems holding up the RC?


  23. Darren, we did indeed discover plenty of little issues to resolve, which took way longer than expected. These issues range from gaps in the REST support down to proper EL integration and ConversionService integration. We were also working on the new TaskScheduler facility and the corresponding task namespace, and on alignment with the OSGi RFC-124 specification.

    Just a couple of days ago, we revisited the release plan and decided to do an intermediate 3.0 M4 release on Monday – shipping more than 150 fixes and enhancements that accumulated since M3. We are nearly feature-complete; there is just work in very specific areas left now, such as converting/formatting and validation. The public 3.0 RC1 release is expected for September.

    Juergen

6 trackbacks

Leave a Reply