Spring 2.5 and the runtime paradigm shift
I just finished reading up on the new features of Spring 2.5 and I have to say I'm pretty excited. One thing that bothered me from the start of the Spring project has always been the need for xml wiring of components. No matter what you do in Spring land, you will have to create at least a minimal stub of xml in your config files to make your component known to Spring. And now, the freshly released 2.5 version of Spring is reaping the benefits of annotation driven development and completely does away with that.
Sure, you can still wire your static beans if you want to, but much more excitingly you can use component scanning to look for beans at runtime. No fiddling with XML at all.
Mark Fisher does a very good job of explaining the full impact of this in his InfoQ article on Spring 2.5. Also there is the much more comprehensive Introduction to 2.5 by Rod Johnson on TSS.com.
But what really caught my interest was Interface 21 CTO Adrian Colyer's elaboration on Spring's investment into the OSGi spec. If you listen to him you suddenly realize why exactly the runtime wiring became necessary. The upcoming Spring OSGi API takes the fact into account that Spring configuration at runtime is cool and all, but modularity gets ever more important. Coyler talks about all the interest the application server vendors have in OSGi and how big Web application projects may look like in the future.
In large applications we may see lots of dynamic service OSGi modules, wired together at runtime by Spring, that, as a whole, make up one or more applications. Spring takes into account that OSGi services may come and go at any given moment. Thus updating parts of the application (deploying a new service) instead of changing out a monolithic WAR file becomes a possibility. Exciting stuff. I will look into that some more.
Of course there is plenty of other cool stuff in 2.5, just check out the SpringSource blog or read the Changelog.
Powered by FireStats
April 1st, 2009 - 02:18
Spring’s XML overly complex, static, non runtime configuration is well known and documented. It’s good to see Spring finally catching up with the light weight, easy to learn, run time based frameworks that have been around for years and are far easier to learn and debug with (because they use standard Java code for configuration).