Nevertheless, I will, as I play around with the recent Spring 2.5 Release Candidate, blog about all noteworthy experiences. In the meantime, my german readers might enjoy reading the Spring Praxishandbuch
Spring 3.0…
Apart from the switch to Java 5 that I mentioned earlier, the main new features of Spring 3.0 will revolve around the two areas of Spring EL (dubbed Unified EL++) and the Spring web modules. While I have already written a rather detailed roundup of the former, I had a chance to get a glimpse at the upcoming usage of expression language within Spring bean definitions.
Spring EL
Having made a first appearance in Spring Web MVC, Spring EL is not entirely new. Nevertheless, the promotion of this feature to the Spring core will enable all modules to incorporate it into their functionality. Before I give you some examples regarding Spring XML configuration, let me explain what Spring EL will actually do.
Expressions will be evaluated relative to the context they appear in and can be used to address what Jürgen called implicit attributes of the respective contexts. Inside the definition of a session scoped bean, you will, for example, be able to reference session and request attributes. You will also be able to use system properties and fields of Spring-managed beans. The really interesting thing is, that, instead of binding early as BeanPostProcessors do, EL expressions will return the value available at bean instantiation time.
Now for the example:
<bean id="anotherBean" class="com.springify.example.AnotherClass" />
The current value of anotherBean’s anotherProperty will be injected at someBean’s creation time, i.e. every time someBean is accessed, as its scope is set to prototype.
Similar functionality will also be provided by means of annotation configuration. The examples from the presentation sported the syntax…
…, in this case providing a dynamically bound default value for someProperty.
REST support for Spring Web MVC
I’ve already blogged about the upcoming REST support, so I will only give you a quick overview of what’s new. Apparently, there’s now a consensus about how requests for different representations will be handled. As mentioned before, both accept headers and file name extensions will be evaluated. The actual functionality will be implemented on top of Spring Web MVC well know view resolution mechanism, complete with new View types for the most commonly used representations (JSON, XML, Atom).
Portlet 2.0 support
By now there’s more to the web than servlets, and the Spring support for JSR 168 has always worked like a bliss. With the recently finalized Portlet 2.0 specification, some long awaited features will soon make their way into the popular portlet containers. Spring Portlet MVC will address the most important of those in the 3.0 release, namely named actions, resource request and event-based inter-portlet communications, by means of additional annotations for @Controller annotated portlet controllers. @ActionMapping and @RenderMapping will be able to bind to named actions. @ResourceMapping will allow serving server-side resources while @EventMapping will allow you to implement handling of inter-portlet events.
Model Validation
With the advent of annotation based configuration, the old Validator mechanism feeled a little old-fashioned every now and then. For those of you who wished for something more Java 5 like, there’s hope on the horizon. Annotation-based model validation will be part of the final Spring 3.0 release. While the exact syntax is not yet finalized, the examplex given showed @NotNull and @ShortDate as field leven annotations. Probably one of the more interesting facts about the new model validation mechanisms is the deep integration with Spring Web MVC and Spring JS to provide gracefully degrading client side validation when using the form namespace to bind to an annotated model class.
Also, the Spring team seems to be evaluating JSR 303 and the Hibernate Validator project, so we can probably hope for support for standard validation annotations.
Conversational scope and stateful controller objects
While not as detailed as the features above, Jürgen also said that the team was evaluation possibilities for providing something along the lines of the Spring SWF conversation scope inside the Spring core. It would most likely be implemented as combination of a new bean scope and an API to programatically start and end conversations. While Spring SWF provides a very high level, declarative way of dealing with conversation semantics, this would enable all Spring modules and Spring based applications to utilize similar functionality.
Factory annotations
Spring 3.0 will contain a new stereotype annotation @Factory, that, combined with a method level @FactoryMethod annotation will allow implementing functionality similar to the current BeanFactory but with multiple bean creation methods.
Pruning and deprecating
It has now be confirmed that all currently deprecated artifacts will be removed with the final release of Spring 3.0 as long as there is no really compelling reason to leave them in the codebase. Most likely, the traditional MVC controller class hierarchy will be deprecated in favour of the new @Controller style. The same fate awaits the JUnit 3.8 based integration test class hierarchy and probably the HibernateTemplate and JPATemplated based classes. Additionally, support for Commons Attributes and the traditional Toplink API will be removed from the Spring core and probably factored out into separate legacy modules.
Roadmap
While Jürgen was very careful not to actually promise any release dates, the team is pressing hard to release a first milestone this month, containing a good share of the REST support as well as some of new the Spring EL functionality. RC1 is planned for December, probably just before christmas. Depending on community feedback on this and subsequently published release candidates, the release of a GA version should occur around February 2009.
… and beyond.
Jürgen made clear that plans don’t end with 3.0. There’s already some vision of the upcoming functionality in Spring 3.1 and 3.2, although, given the timeframe, this should apparently be handled with care. Spring 3.1, which is scheduled for July 2009 might contain support for JAX-RS’s endpoint model as alternative to Spring Web MVC based RESTFUL applications as well as support for the upcoming Servlet 3.0 specification. There’s also a discussion about supporting Web Beans annotations while that specification is awaiting it’s finalization.
About Spring 3.2, due in late 2009, only wild guesses can be made, but there will likely be some support for Java 7 features (like binding support for the new DateTime API). Java 5 support will, however, be guaranteed throughout the lifetime of Spring 3.x.
]]>REST support will be based on Spring MVC instead of Spring WS
Those of you who have already had a look at the Spring MVC 2.5 @Controller annotation and its companions, @RequestMapping, @RequestParam and @ModelAttribute will have noticed that it’s possible to map a request based on its HTTP method:
This already "smelled" REST-like, so I guess it was just consequential to use Spring MVC as base for the upcoming REST support in Spring 3.0. I had the opportunity to talk about it with Arjen and he explained that they were actually experimenting with various concepts for doing this in Spring WS, but in the end, Spring MVC felt like the more natural choice.
But what will it look like then? Extend a welcome to…
UriTemplate and @PathParam
Well, actually @PathParam might not be the final name, I’ve also seen @UriParam somewhere, but the usage will be the same. I’ll just give you an example:
It can’t possibly get easier that that. Best of all, you can reuse your investment in Spring MVC because the programming model doesn’t change. The final release will include support for binding to more than one URI wildcard as well as identification of the requested representation based on HTTP Accept headers (for machine clients) or file extensions (for browsers).
Additional feature will include:
You might wonder whether there will be any support for building REST clients as well. Indeed there is, and it’s - not much of a surprise here - …
RestTemplate
You can expect the usual usage patterns here and Arjen showed some actual code, so it’s pretty clear what the API (which by the way seems to be implemented on top of Commons HttpClient) is going to look like. I’ll just give a few examples based on Arjen’s slides here:
// Creating a resource with postForLocation
// (with parameter substitution, map variant)
Map<String, String> params =
new HashMap<String, String>();
params.put("id", 42);
URI uri = template.postForLocation(
"http://www.springify.com/gadgets/{id}/features",
new Feature("Glows in the dark."), params);
// Deleting a resource with delete
template.delete(
"http://www.springify.com/gadgets/{id}", someId);
// … and the obligatory callback pattern, albeit without
// further details yet. Method parameter will be provided
// in the form of Enum types.
template.execute(
"http://www.springify.com/gadgets/42/feature/1",
POST,
aRequestCallback,
aResponseCallback);
Looks pretty straightforward to me. So now that we know the "what", what about the "when". Well, there’s some good news here. The first two features, namely RestTemplate for building clients and @PathParam for mapping to UriTemplate wildcards will be available in Spring 3.0 M1, which is scheduled for July or August. The remaining features will follow while Spring progresses towards 3.0 GA in late 2008.
What’s left
Well, there’s the issue of authentication and authorization, which is apparently taken care of by the Spring Security team. Arjen mentioned support for configuring access restrictions based on both HTTP methods and URLs, but I don’t have any details here.
That’s it for tonight as it’s getting late and I need to catch the train back home early tomorrow. I hope to post a summary of the SpringSource Application Platform sessions early next week, so keep an eye on the feed.
]]>Timeline
According to Jürgen, there’s the plan to have a first milestone by August 2008, although I’ve also heard July mentioned. If everything goes well, we might see a GA release late in Q4 2008.
Theme
Actually, Spring 3.0 will probably intensify what Spring 2.5 started: the embrace of the Java 5 programming model, this time to the extend that the Spring Core itself will be partially rearchitected and for the first time depend on Java 5. Internal (and gracefully downgrading) usage of Java 6 features will be expanded, although where and what was not announced. Also, there seems to be the trend to generalise certain parts of non-core modules in order to incorporate them into the core - for more about this see below.
Features
Well, there was not an aweful lot of information availabe about new features planned for 3.0 (with the exception of RESTful Spring, I’ll blog about that later tonight when I’ve ordered my notes), but here you go:
There’s probably more planned, but I guess we’ll have to wait for the first milestone to get a detailed roadmap.
Important changes
The one apparent and rather fundamental change is that Spring 3.0 will no longer run on Java 1.4. Apparently most of the core is refactored to use generics, enumerations and variable argument lists. Apart from that, some pruning is going to happen:
According to Jürgen, the programming model itself will be 100% backwards compatible with Spring 2.5. The framework’s extension points will, however, be pruned to accomodate for the fact that some of them won’t make sense in a Java 5 environment. Jürgen mentioned 95% backwards compatibility with regards to extension points, so that shouldn’t be much of an issue.
That’s it for now, expect another posting about developing RESTful Spring applications with Spring 3.0 later tonight.
]]>One of the main themes in Spring 2.5 has been the progression towards Java 5 and JEE 5 programming models (e.g. by means of annotation driven configuration options and support for JEE annotations). The other apparent trend was the advent of load-time weaving as alternative to the traditionally proxy-based AOP model in earlier Spring releases. As Jürgen explained the major features that have been introduces in this context, he mentioned a couple of not so obvious facts about Spring 2.5 that I’d like to relay to you:
Registering custom annotations for component scan
You can write your own stereotype annotations (yes, completely independent from the Spring annotations) and make the container automatically pick up your annotated components by supplying filters to the ClassPathBeanDefinitionScanner responsible for determining valid candidates. See the documentation for details. This sounds great for implementing domain-driven design principles by providing intention revealing annotations.
OpenJPA save point support
Spring’s OpenJpaVendorAdapter exposes OpenJPA’s extended EntityManager implementation. As Spring’s JpaTransactionManager has support for JDBC 3.0 savepoints, this eventually allows you to use OpenJPA’s save point semantics. I’ll make sure to give this a try and blog about how it works.
LTW mode for <tx:annotation-driven/>
All of you know about the annotation driven transaction demarcation, which is usually done by the application context scanning your classes for @Transactional and wrap them in Proxies. While this usually works great, there is, as various forum threads suggest, some amount of confusion regarding the limits of dynamic proxies, mainly when transaction propagation doesn’t work as expected with “class-internal” method calls. As I just learned, you can alleviate that problem by enabling load-time weaving via an agent or the custom classloader implementations that are bundled with Spring and configuring the transaction support with an additional attribute like shown here (ommiting the loadtime weaving configuration itself):
Neat, isn’t it? Methods annotated with @Transactional will be augmented during load-time afterwards, no more proxies are needed.
Well, that’s it for now, I’m off to listen to Mark Fisher’s talk about Spring Integration.
]]>@Apac
public class SomeLocalizedService implements SomeService {
// Implementation omitted
}
public class SomeConsumer {
@Apac
SomeService someService;
// Implementation omitted
}
The framework will associate the custom annotations and use them to chose the proper instance instance for injection. This leads to using Spring annotations as “meta-annotations” (a term just coined by Rod) to build own sets of domain-specific annotations that turn classes they are applied to to Spring-managed components. Combined with the classpath scanning functionality included in Spring 2.5, you could - if you really wanted to - avoid writing any XML configuration at all.
As the keynote progresses, Rod’s stressing that one of the most important freebies you get when using Spring is the ability to secure your application by means of Spring Security (formerly Acegi Security). As we all happen to know by now, every time you used Acegi, a fairy died. The configuration was just horrible (someone compared it to strangling a dragon with bare hands, though I seem to have lost the link; speak up if its you) as it basically boiled down to writing bean definition for all the Acegi low level components. Spring Security comes with a custom namespace that (almost) solves this problem. Personally I still find it daunting, but I also think that the domain it applies to is important enough to use it nevertheless.
One thing Rod seems to be surprised of - and I’m with him there - is that almost no one in the audience uses the Spring integration testing framework provided by means of Spring TestContext. For those of you not attending SpringOne, I’m gladly relaying his invitation to give it a try and donate the money you save by doing so (to him, but that’s just an implementation detail you’re free to change). I gave an example of how to use it for test-driven development in a recent post.
Spring Integration is another new addition to the Spring Framework family. Considering that Spring has always been a strong integration platform, being able to use it as quasi service bus with a domain specific configuration language implementing Gregor Hohpe’s EAI patterns seems pretty convenient. I’m going to blog about this in detail in the near future, so I will not dig into the details here.
If you have used Spring MVC in Spring 2.0, you should also have a look at the new features introduced with the 2.5 release. I have written about it before, but I think the new “convention over configuration” mentality introduced here - especially with the advent of @Controller - is worth noting again. Things have become a lot easier and, combined with the new Spring Web Flow release, development web applications with Java might even become fun (well, in the broader sense). Some of the highlights of both frameworks, namely the aforementioned @Controller annotation, SWF’s Ajax features, Spring JavaScript (which is, according to Keith, who just took over the microphone, is “a toolkit for progressively enhancing web pages with AJAX” built on DOJO) and Spring Faces (which basically makes JSF as component framework available within Spring Web Flow driven applications and could be considered a JSF integration layer) found their way into the keynote.
With Rod back at the microphone, the topic now is deployment models and runtimes for Spring based application. He stresses that developing with the Spring programming models in fact decouples your code from the runtime environment, as Spring as container works in all deployment models available today (JEE, Servlet, OSGi, etc.). While portability on this level doesn’t seem like an issue, there’s the ongoing trend of deploying to to lightweight servlet containers like Tomcat and Jetty instead of commercial JEE containers. Whether or not OSGi will be the next generation enterprise runtime is yet to be determined, nevertheless the announcement of SpringSource Application Platform (I blogged about it here) last month seems to be an indicator for it’s relevance. Rob, Application Platform lead, just entered the stage with an awesome S2AP t-shirt (100% bloat-free); if I am able to get one of those, I’ll post a picture here.
Rod’s talking about the SpringSource Enterprise subscription now, which, besides official support (including indemnification), grants access to the SpringSource Tool Suite, an Eclipse-based integrated development environment for Spring-based applications. As of the latest developer release, the Tool Suite comes with support for the PAR deployment style introduced with S2AP. Even while I’m not that much of an Eclipse person, I will try to give you an overview of what’s being presented here. I also have to mention the incredible pace at which Christian, Spring IDE and STS lead, keeps up with the rapidly expanding and changing Spring stack. One interesting feature seems to be what Christian is calling “runtime error analysis”, which allows you to automatically look up stack traces in a knowledge base to find likely solutions to your programming problems. Actually STS incorporates a lot of what I’d call community features like forum access, recent news, etc. If you hate media disruptions as I do, this might be a good thing for you. Christian stresses that, due to the comprehensive context sensitive hints and the comprehensive knowledge about Spring best practices built into it, the Tool Suite can be used as a consulting and teaching platform for Spring based projects.
The subscription also lets you use the SpringSource Application Management Suite, which is a runtime monitoring platform for Spring applications with support for all major JEE containers as well as Tomcat. I leave it up to you to look up the details of this and the other SpringSource enterprise products (fingers are already hurting) and write about SpringSource’s goals and motivations as presented by Rod at this moment.
Interesting enough Peter Cooper-Ellis, former WebLogic Unit Excutive, has just been hired by SpringSource for Engineering and Product Management. He’s right now talking about his background with proprietary software and how the the whole industry is moving towards deployment scenarios like cloud computing. One of his roles at SpringSource seems to be to help the Spring framework meet the demands those trends will make on the next generation’s application frameworks.
Well, I think that’s about it for now. I’ll keep you posted about any ground-breaking news, so make sure to subscribe to the feed.
]]>Let me summarize the article for those of you who haven’t yet had the opportunity to read it. To put it in a nutshell, SpringSource is about to or already released as beta their own Java application container based on Spring, Tomcat and OSGi. I’m not actually surprised by this move as there have been a lot of hints pointing into this direction in the past, the acquisition of Covalent probably being the most prominent one.
Anyway, I personally find it exciting news as, if the bundle delivers what is promised in the article, this might mean that there will be a “natural” application container choice for Spring-based projects. Having seen a lot of high-profile app-server installations in the field that were used as mere servlet containers (but with a hefty administration and footprint overhead), I consider this a good thing. Add the SpringSource support offer and you will have a much easier time arguing in favour of Tomcat as a lightweight alternative.
Vice versa, it might be easier to argue in favour of the Spring programming model once you can toss in a fully supported and integrated runtime environment for it too.
I hope I can get my hands on a beta release soon to play around with the OSGi deployment model (and to see whether I can bully Maven into building PAR archives for me). In the meantime I’d really like to hear what you think about the announcement.
]]>I started with the following integration test:
import static org.hamcrest.core.Is.is;
import static org.junit.Assert.assertThat;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestExecutionListeners;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:/com/springify/example/applicationContext.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})
public class UserServiceIntegrationTest {
@Autowired
private UserService userService;
@Test
public void addUserAndLogin() {
userService.registerUser("admin", "password");
assertThat(userService.login("admin", "password"), is(true));
}
}
Please note that I only had to use the @TestExecutionListeners annotation because for the purpose of demonstrating TDD I felt no urge to dive into the complexities of transaction management. While this is already pretty concise considering I’m setting up a complete environment here, just have a look at the bean definition:
<context:component-scan base-package="com.springify"/>
<context:annotation-config/>
</beans>
Not much in there, actually. But it has to be somewhere, doesn’t it? Maybe…
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
@Service
public class DefaultUserService implements UserService {
public boolean login(String userName, String password) {
throw new UnsupportedOperationException("TODO");
}
public void registerUser(String userName, String password) {
throw new UnsupportedOperationException("TODO");
}
@Autowired
public void injectUserRepository(UserRepository userRepository) {
// TODO
}
}
and …
import org.springframework.stereotype.Repository;
@Repository
public class DefaultUserRepository implements UserRepository {
public User getUser(String username, String password) throws LoginFailedException {
throw new UnsupportedOperationException("TODO");
}
public void addUser(User user, String password) {
throw new UnsupportedOperationException("TODO");
}
}
Yes, that looks like it could do the trick. Even if the amount of configuration saved by this approach might not be huge for the few beans used in this example, it still felt a lot more natural and … dare I say… agile, because I was able to concentrate on driving the design with my tests instead of wiring changing bean graphs together.
As a side note, it was fun to use the new Spring TestContext with my favorite acceptance testing framework Concordion. For quick results, all you actually have to do is copy the code from org.concordion.integration.junit3.ConcordionTestCase into a base class:
import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;
import org.junit.Test;
import org.concordion.Concordion;
import org.concordion.api.ResultSummary;
import org.concordion.internal.ConcordionBuilder;
import java.io.IOException;
public abstract class AbstractSpringConcordionTest extends AbstractJUnit4SpringContextTests {
@Test
public void concordion() throws IOException {
Concordion concordion = new ConcordionBuilder().build();
ResultSummary resultSummary = concordion.process(this);
System.out.print("Successes: " + resultSummary.getSuccessCount());
System.out.print(", Failures: " + resultSummary.getFailureCount());
if (resultSummary.hasExceptions()) {
System.out.print(", Exceptions: " + resultSummary.getExceptionCount());
}
System.out.println("\n");
resultSummary.assertIsSatisfied();
}
}
After that, you can create your dependency-injected fixtures like this:
import com.springify.integration.concordion.AbstractSpringConcordionTest;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:/com/springify/example/applicationContext.xml"})
public class LoginTest extends AbstractSpringConcordionTest {
@Autowired
private UserService userService;
public void addUser(String userName, String password) {
userService.registerUser(userName, password);
}
public String loginWith(String userName, String password) {
return (userService.login(userName, password) ? "was successful" : "failed");
}
}
I also appreciate the efford that has gone into obtaining WebSphere certification for Spring 2.5, as lack of server vendor support can - at least with the clients I usually work for - still be an exclusion criterion.
So, to put it in a nutshell: Congratulations on this release to everybody at SpringSource and thanks for the awesome job you’re doing there.
]]>Nevertheless, I will, as I play around with the recent Spring 2.5 Release Candidate, blog about all noteworthy experiences. In the meantime, my german readers might enjoy reading the Spring Praxishandbuch
Until then, I would like to point any German readers to the articles I have written for the Advanced Spring series published in the German Java Magazin. Feel free to leave your comments and questions here.
]]>