Semergence

Expert Spring MVC and Web Flow is my first book, soon to be published by APress. The official book page has been updated with the correct book description and cover thumbnail. If I were you, I wouldn’t wait for the movie version, so go buy a copy! The contract negotiations with Natalie Portman are still in the works.

> Expert Spring MVC and Web Flow provides in-depth coverage of Spring MVC and Spring Web Flow, two highly customizable and powerful web frameworks brought to you by the developers and community of the Spring Framework. Spring MVC is a modern web application framework built upon the Spring Framework, and Spring Web Flow is a new project that compliments Spring MVC for building reusable web controller modules that encapsulate rich page navigation rules. Along with detailed analysis of the code and functionality, plus the first-published coverage of Spring Web Flow, this book includes numerous tips and tricks to help you get the most out of Spring MVC, Spring Web Flow, and web development in general.

Spring 2.0 will have support for autogenerating view names from a request. Rob Harrop has checked in this new strategy interface, reducing the amount of configuration required when writing Spring MVC applications.

/**
 * Strategy interface used to translate an incoming {@link javax.servlet.http.HttpServletRequest}
 * into a view name when no view name is supplied by the user.
 *
 * @author Rob Harrop
 * @since 2.0M2
 */
public interface RequestToViewNameTranslator {

	/**
	 * Translate the incoming {@link HttpServletRequest} into a view name.
	 * Cannot return null.
	 */
	String translate(HttpServletRequest request);
}

This is largely added in order to simplify working with Spring MVC.

It looks like Rob Harrop is now moving scripting into the main tree with support for Groovy, BSF and JRuby.

Spring, meet Ruby.

The Spring 2.0 XML Schema files are now online. These include the specialized schemas for Spring 2.0’s custom tags:

[http://www.springframework.org/schema/aop/spring-aop.xsd](http://www.springframework.org/schema/aop/spring-aop.xsd)
[http://www.springframework.org/schema/beans/spring-beans.xsd](http://www.springframework.org/schema/beans/spring-beans.xsd)
[http://www.springframework.org/schema/jndi/spring-jndi.xsd](http://www.springframework.org/schema/jndi/spring-jndi.xsd)
[http://www.springframework.org/schema/tx/spring-tx.xsd](http://www.springframework.org/schema/tx/spring-tx.xsd)
[http://www.springframework.org/schema/util/spring-util.xsd](http://www.springframework.org/schema/util/spring-util.xsd)

Abstract Horizon has released the Spring Application Server, which is:

> Spring Application Server is simple, highly configurable and light-weight application container based on Spring Framework. Server components are POJOs defined under the Spring Framework that is extended to provide support for services.

The interesting part is its use of Modules, a concept that Spring doesn’t quite have yet.

> The server is organised around Modules. Each module describes an unit that exists within a server’s boundaries. The modules are organised in a hierarcy of dependancies.

Colin Sampaleanu sheds some more light on why the Hibernate classes were split into their own Jars from the Spring library:

> It’s not about splitting it out just to split it out. The problem is
that having both the Hibernate 2 and Hibernate 3 code together leads to
a lot of confusion. People end up importing the wrong classes all the
time. The actual class names are identical, and the packages as
identical except for one extra char, so it’s easy to import the wrong
one when you do an auto import in Eclipse. I see this over and over
during trainings, among other places. So back in the summer I suggested
we split things out to separate jars and have people just include
whichever one they wanted, but it didn’t make sense (for drop in
compatibility reasons) to do this in a 1.2 point release, but rather
only now with 2.0…

From Craig Walls, explaining what happened to Spring’s Hibernate classes in the latest Spring 2.0 M1 release:

> I stopped Rob, Rod, and Juergen in the lobby on the last day of TSE and asked the same question. It seems that Juergen has split out most of the vendor-specific ORM stuff into independent JARs (spring-hibernate.jar or spring-hibernate3.jar for instance). It’s my understanding that the decision was made because (1) the main JAR was getting quite large and (2)
Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring and thus should not be in the main JAR.

> So, yes, from a JAR dependency perspective, backwards compatibility is broken. But fixing it is simply a matter of including an addition JAR file in the classpath. Code-wise, backwards compatibility is still intact.

From Alef Arendsen’s blog, he has posted his JavaPolis Spring Web Tier slides

>Yesterday, Erwin Vervaet and me did a 3-hour session on Spring in the Web Tier. We mainly focused on Spring MVC and Web Flow. The sample is online; you can get to it from the Spring Framework site.

>The slides are here, in PDF format.

The final afternoon talk on the final day of The Spring Experience is Pragmatic AOP with Spring and AspectJ.

Aspects are modular, enhancing the value of the software overall. Aspects lead to DRY SOCs (Don’t Repeat Yourself, Separation of Concerns).

Join points are well defined points in the execution of the program.
Pointcuts are expressions that match join points.
Advice is action to take at those join points. Advice is not explicitly called, unlike methods.

Typical applications are Spring managed for data access, services, web controllers, transactions, etc. Up to now, the Domain Model has not been managed by Spring.

Spring AOP is a good fit for Spring managed beans, execution based join points, or coarser-grained service application. Or any time where the aspect is slower than the impact of the proxy itself (ie, transactions).

In Domain Driven Design, another separation of concern (SOC) is the Technical Concerns (transactions, auditing, etc) from the Business Concerns (the Ubiquitous Language, language of the business domain experts).

AspectJ is perfect for integration with the Domain Model, in contrast to Spring AOP which is good for advising the service layer.

What makes a good aspect? Does the aspect reduce coupling?

The afternoon sessions begin with Practical Quick Start with Acegi Security and Spring, presented by Ben Alex. Ben is the project lead for Acegi Security, a fully pluggable and flexible enterprise security framework. Specifically for your enterprise software, it’s not an Operating System security framework or any sort of browser or sandbox security solution.

The important thing to know about Acegi Security is it is more of a model and lexicon instead of pre-built security implementation. Because security varies across each application so widely, Acegi provides interfaces and extension points to make building a security framework much easier.

Acegi is much more than a replacement for Servlet API security. While it does fully replace the Servlet security features, it also provides fine grained ACLs on a per-object instance which is a huge feature. J2EE security does not support that at all. Other features include CAPTCHA, channel security, switch user, prohibit concurrent logins, and many others.

It’s important to note that Acegi Security is not specific to web applications. It’s perfectly viable as a security framework for your Rich Client project, too.

There are an insane amount of Authentican mechanisms, including Form, HTTP Basic, HTTP Digest, RMI X509, Yale CAS, SiteMinder, Remember-Me, Anonymous, and others.