Portability is a key factor in the Spring universe. We believe in portability at the framework level: Application components are written against a specific framework (or framework generation), such as Spring 2.5; the framework is then in turn responsible for adapting onto any underlying hosting environment. However, the specific application framework is above and distinct from the hosting environment. A brand-new framework version may be deployed onto an established generation of the hosting platform, as long as the fundamental capabilities of the environment are sufficient. This approach differs significantly from the traditional approach of baking component frameworks into the deployment platform itself, where the environment supports a specific version of the framework only - and an intended update of the framework requires an update of the entire platform.
The Spring Blog
Yesterday I gave the opening keynote at the JAX conference in Wiesbaden, Germany. JAX is one of Europe’s largest Java conferences, with over 2,000 attendees. The topic was The Future of Enterprise Java, and I expanded on the themes of my recent blog of predictions, going into more detail about the implications of Java EE 6 and the future of the application server.
I’ve uploaded the slides, which include 8 predictions for an interesting period in the evolution of enterprise Java. This is the first time I’ve referred to Joseph Stalin, Monica Lewinsky and Monty Python in the same presentation.
JAX was an enjoyable experience overall, with excellent speakers from both Europe and North America and great questions from attendees. The SpringSource booth looked great as always, and it was good to see so many attendees. And, of course, German beer tastes as good as ever!
This seems to be the most active time of year for conferences. In the last few weeks I’ve spoken at QCon in London and the ServerSide in Vegas, and I have several more conferences coming up:
Spring Security 2.0 has been released. This is a major step forward for the Spring Portfolio. Spring (Acegi) Security is already the Java platform’s most widely used enterprise security framework, with over 250,000 downloads on SourceForge and over 20,000 downloads per release. Through making it so much simpler to use, this release will undoubtedly take adoption to a new level.
I’m particularly pleased about this release for a number of reasons:
- It’s a great thing for the Spring community. It’s (a lot) simpler to use, as well as more powerful. It puts the most powerful enterprise Java security solution within the reach of many more users, pretty much eliminating the hurdles to adoption. See this tutorial for an example of just how much easier it makes it to secure a typical web application. The proliferation of XML bean definitions is a thing of the past.
- It’s a continuation of the work of Spring 2.x, through applying the power of a custom XML namespace to enable aggressive defaulting, while still allowing for customization.
- Like Spring 2.5, it exhibits the current Spring Portfolio trend toward radical reduction in the need for XML.
- It’s a proof of the value of the SpringSource business model. Our revenue model enables us to invest more than ever in creating open source software. Without being able to hire both Acegi/Spring Security creator Ben Alex and the other major committer, Luke Taylor, this release either wouldn’t have occurred or would have been much less extensive.
- It’s good for the fairy kingdom.
Three weeks ago, the SpringSource Tool Suite was released. Christian, in charge of this product blogged about it already and we also have a webinar available for those of you that want to get up to speed with all of the functionality it currently offers. In this entry, I wanted to highlight the runtime error reporting functionality specifically.
When I’m programming, sometimes, the console window shows dozens of stack traces due to some error I’ve caused. Sometimes, I’m lucky and the stack trace looks familiar. If so, then the problem is probably easy to solve. Sometimes however, the information you need is buried so deep inside all those stack traces, that figuring out what the real problem is takes a while.
If the tech community were to host their own version of the popular TV show The Biggest Loser (or maybe Celebrity Fit Club) you would see enterprise Java front and center—bloated, overweight, tired, and drained.
The future of enterprise Java is becoming clear. The morbidly obese legacy platforms are in decline, with leaner solutions increasingly used in production as well as in development. Legacy technologies such as EJB are becoming less and less relevant.The lukewarm takeup of Java EE 5 leaves it looking increasingly like the last gasp of traditional J2EE bloatware. Meanwhile, the Java EE 6 specification is finally set to allow for greater modularity, in a radical change which will have important implications for developers and is likely to rejuvenate competition among implementations. As the standards and the products based upon them have gathered pound after pound of cellulite, SOA, Web 2.0 and other infrastructural changes continually impose new requirements that were not foreseen when J2EE was conceived a decade ago, as a chubby but cute baby.
It’s been a while… for the Amsterdam Java Meetup that is. I’ve been traveling a lot and haven’t been able to organize another meetup past quarter. But here we go again: the (almost) quarterly Amsterdam Java Meetup with free drinks (or at least, the first few rounds) will be hosted in grand-cafe de Jaren in Amsterdam (see below for more info on the location) on the 23rd of May. You can expect many Java devs (usually between 50 and 80 people turn up), technical as well as non-technical discussions and of course, the latest gossip in the Dutch Java industry. We’d love to hear from people from ‘the other side’ (other other sides, I should say) as well, so if you’re doing Ruby or .NET, don’t hesitate to join in too!!
It has been a busy few months since SpringSource partnered with Hyperic to bring our Application Management Suite (AMS) product to market. I am pleased to announce that the SpringSource AMS beta release is now available to all. Please take a moment to evaluate the software and post your thoughts on the beta forum. We are committed to providing the best application management experience possible for Spring-powered applications, and your feedback is much appreciated!
Those who expressed an interest in SpringSource AMS at The Spring Experience in December received an email announcing the beta release. Here is an excerpt from that email that introduces SpringSource AMS and outlines some of its additional features:
After being in the works for about six months, I’m happy to announce that Spring Web Services 1.5.0 has been released! In this post, I’d like to go over some of the major new features.
The 1.5 release includes two new transports: JMS and email. Using these new transports requires no Java code changes: just add a bit of configuration, and you’re off! The JMS transport integrates nicely with Spring 2’s Message-Driven POJO model, as indicated by the following piece of configuration taken from the airline sample application:
Today I am delivering a presentation entitled Spring for Java Server Faces at TSSJS in Las Vegas. The presentation looks at how JSF and Spring fit together, and walks the audience through approaches to integrating these two technologies.
The slides are available for your viewing pleasure, and for you to use as you see fit.
In the presentation, I outline two approaches to integrating JSF and Spring. The first approach is what I call “JSF-centric”, which is the integration approach most folks with a traditional JSF background employ today. The second approach is what I call “Spring-centric”, which is a new, groundbreaking approach to JSF integration driven by the work done in the Web Flow 2 distribution.
Today marks the third milestone release of the Spring Java Configuration project (JavaConfig for short). The release contains numerous bug fixes and new features - I’ll highlight a few of the most interesting changes below, but first let me give a quick refresher as to what JavaConfig is all about.
If you have any experience with Spring, the following snippet of XML configuration will likely be familiar. Let’s assume we’re looking at a file named application-config.xml:
<beans> <bean id="orderService" class="com.acme.OrderService"/> <constructor-arg ref="orderRepository"/> </bean> <bean id="orderRepository" class="com.acme.OrderRepository"/> <constructor-arg ref="dataSource"/> </bean> </beans>