New feature reviews for Spring 2.0

Spring2.0 's release is probably a big event in the 2006 Java community. A summary of 2.0 new features is presented in the documentation included with the Spring2.0 release, and 2.0 of the new features are naturally our most concerned:

First, spring XML configuration introduces XML Schema syntax simplifies configuration

In the spring1.x series, the bean's configuration file uses a DTD and is not namespace delimited. A very big improvement in 2.0 is the introduction of the namespace of XML schemas, so that the bean's configuration file can be substantially simplified. These simplifications include various simplification of bean properties, simplification of AOP configuration, simplification of transaction configuration, simplification of jndi configuration, and so on. Of course, while simplifying the configuration, the new XML schema actually introduces more XML syntax, so it is necessary to use an XML editor that supports XML schemas, such as the Eclipse WTP to provide syntax automatic hints and checksums for schemas.

The spring1.x bean configuration file is increasingly complex and cumbersome, which is one of the major problems in spring's history. The configuration of XML Schema syntax in Spring2.0 can considerably reduce the complexity and sophistication of the configuration file and can be seen as one of the major improvements in spring. But we also have to see that the XML schema does not solve the problem of complex XML configuration from the root cause, but only alleviates it.

All the dependencies between the beans, the assembly relationships are all used XML to describe, itself will cause XML to read and modify some difficulties. And the XML configuration itself cannot be used directly for unit testing to validate dependencies. Therefore, the more complex the relationship between the beans, the maintenance of the XML configuration file itself is also a burden.

I personally expect spring to be able to use the scripting language to write and assemble the relationships between beans, so the assembly script itself is testable, and the script is far better descriptive than the XML configuration file, and is easier to write and maintain than XML.

Second, provide the request and session scope of the Bean

Introducing the request scope and session scope bean, I feel like a double-edged sword. For ordinary Java web Framework applications, the operations associated with the servlet container should be limited to the web layer, and the business tier should not involve the scope of the request and session, otherwise the business layer code cannot be unit tested out of the servlet container. For users who use the Webwork/struts framework, this feature is unlikely to be used, and, as I understand it, perhaps the request/session scope Bean is also intended to be used for the controller of Spring MVC.

In addition, this feature is useful for Ajax Web service calls. For this scenario, JS calls through Ajax, throwing away the web-layer framework, direct access to the business layer bean, this time need to provide request/session scope of beans.

Three, integrated ASPECTJ, can manage the object outside the container, provide the dependency injection of the domain model

The persistent object Po, typically managed by hibernate, is not initialized by the spring container, often by the user being new or created by the Find,load method, and the result is that the spring container cannot inject bean dependency on objects created outside such containers.

In Spring2.0, the domain model can be statically woven using ASPECTJ, so that when the domain model is created outside the container, a callback to the container is generated and a dependency is injected.

This feature, provided by Spring2.0, ensures the viability of Martin Folwer's rich Domain object, which is likely to have a far-reaching impact on the design of many future Java systems.

In fact, in the case of rich Domain object, if you use DAO as the abstract parent class of domain object, then the persistent object Po gathers po,dao,service objects, the entire business layer, the persistence layer is completely merged into one object, The result of simplifying the framework in this way is that the MVC framework is highly similar to the full-stack of Ruby on Rails.

Iv. JPA Support

There's really nothing to comment on, and it's a well-deserved thing to provide JPA support.

V. the namedparameterjdbctemplate of JDBC

Namedparameterjdbctemplate I think it makes sense to provide a placeholder for a JDBC query with named arguments, not just JDBC's own "?", so that when you use JDBC, you can easily construct dynamic conditional queries with placeholders, Instead of the concatenation of the parameter values into the way the SQL string.

A large expansion of the Spring Web MVC function

See, in Spring2.0. The WEB MVC feature expands dramatically, and UI taglib that were not provided in the past are finally available, and configuration files are simplified as necessary. Although spring MVC is far less creative from a framework design perspective than webwork, it is also a step improvement that, together with support from various peripheral frameworks such as spring webflow, can predict that spring MVC will grow to be a webwork foe.

VII. support for dynamic language Ruby,groovy,beanshell

Dynamic language support now seems simpler and less powerful, but it shows an attitude of spring, and I personally hope that spring can strengthen this support, and even boldly, provide a bean assembly configuration written in a dynamic scripting language.

Eight, asynchronous JMS support, JMX support, JCA support features complete

Spring2.0 itself offers two types of simple JMS containter, as well as external JMS server interfaces, support for JMX functionality, and support for JCA functionality in the further refinement process.

SPRING2.0 's functional support in these areas is not so compelling, since ordinary Java Web applications rarely use these aspects. But spring provides a profound support for these features, because they are the functionality required by the Java EE specification, and are a traditional advantage for traditional application server vendors, which are relatively much more than the Open-source framework. Once Spring2.0 provides complete support for these features, the technical hurdles to completely migrate traditional Java enterprise applications to the spring framework are dispelled.

So spring is a very ambitious framework, and in the present situation, spring can be said to be the epitome of the Java Open Source framework, and in the future spring will provide all the necessary functionality that the EE vendors can provide, and eventually spring will be able to take over the specification and Become the fact platform and fact standard of Java Enterprise development.

Overall, Spring2.0 will take another big step towards the ambitious goals of the future. But for the development requirements of my common Java Web Project, 2.0 of the new features are not particularly needed.