I am glad to report (along side Adrian) that after 3 milestones and 2 release candidates, Spring Dynamic Modules (formerly known as Spring OSGi) 1.0 has been released.

A lot of features have been improved or added since my previous post (about 1.0 M1); I'll talk more about them in future entries (there is also the reference documentation that explains the library at length) so I'll just name a few:

- consistency

We want to provide a powerful, simple and consistent programming model. That's why Spring Dynamic Modules builds on top of Spring and uses its proven concepts, reliability and ubiquity.

- highly non-intrusive nature

The recommended way to use Spring DM is to not use its classes inside your code or have any imports for them inside your bundle manifests. If you are not using Spring inside your code and only for your application configuration, the same rule applies. Spring DM creates the application context for you, so there is no need for you to depend on Spring or Spring DM. And don't worry about things such as custom namespace or XML schemas - we've already covered them.

- OSGi service dynamics life cycle management

This is one of the most important Spring DM features - the ability to interact with OSGi services just as you would with normal beans. You can publish and consume OSGi services without writing any code; we'll deal with the dynamics for you - and you have full control (more about this in the future).

- smarter integration testing framework

Since we used Spring-DM integration testing extensively internally, we improved the defaults, the maven integration and made the automatic manifest generation faster and smarter then before. For example, the framework automatically determines the classes available in the test bundle and will not generated imports for it.

- simple bundle interaction

Andy Piper (blog) added a simple, declaratively way to install/start/stop/update bundles based on the module life cycle and Spring beans dependency.

- managed startup/shutdown context creation

In OSGi applications are broken into various modules (also known as bundles) which rely on each other services. This creates a dependency tree between the module which becomes important during startup and shutdown. Traditionally this can be addressed by installing and starting the bundles based on the dependency order however, this doesn't solve entirely solve the problem. As the OSGi specification recommends, OSGi services that take a long time to initialize (such as connection pools) should rely on a different thread then the one used for starting and stopping the bundle. This means that if a bundle is started, it does not mean its services are. And not every application is ready to wait for its required service during start up - in fact, few do. This means that a bundle will fail since it relied on a service published several milliseconds later (OSGi is, by default, an in-VM platform where things happen really fast).

This behavior is not rare - in fact, it's quite common at startup on multi-core platforms with multiple bundles. Spring DM addresses this problem by determining the dependencies (from the Spring configuration) and waiting for them to become available before creating the application context. A similar process will be used at shutdown, when Spring DM will stop the contexts based on their dependency order so you don't have to worry about starting or stopping your bundles.

- thread-less dependency waiting

I cannot discuss the dependency mechanism without mentioning the 'thread-less' approach used for dependency waiting (sounds a bit like an oxymoron, I know - we're working on a fancy title for it) implemented by Hal Hildebrand (see his blog). Since various services need to be available for a module to properly start some sort of waiting/monitoring is required which traditionally implies using a thread.

However, on an OSGi platform can be (and there will be) multiple modules (several dozens easily) - using a waiting thread per module simply does not scale. One thing which we worked hard on was improve this model and I believe we provided a very nice solution - using no thread at all for the waiting process. This means that no matter if 3 bundles are deployed or 300, no CPU time will be spent unless your modules actually start.

 

Spring Dynamic Modules is not just about 'spring'-ifying an API but rather dealing with a different runtime environment.

 

With regard to tooling, Spring IDE supports Spring DM namespaces and (thanks to Christian) also provides Spring-DM specific targets for Eclipse PDE, a features available in Spring IDE nightly builds (more info on installing and using the plug-in is available in the reference documentation).

 

Future directions

 

So now that 1.0 has been released, what's next? Plenty of areas to cover:

Web Support

OSGi platforms provides a dedicated Http Service but using it requires coding. Things such as resource loading, JSP generation and deployment can be significantly simplified. This is the main are of focus of the 1.1 release.

Persistence

Modern persistent tools provide advanced features such as lazy-loading which bend the modularity borders enforced by the OSGi environment as they rely on class generation and proxying. We want to address this problem and, just like with web support, provide a smooth experience whether plain JDBC or/and ORM tools are being used.

AOP

Following the persistence problem, we are seeking solutions for doing generic AOP inside OSGi. It's a hard nut to crack and to do it properly, internal OSGi platform support is required. The good news is that projects like Equinox Aspects have already led the way and OSGi Enterprise Expert Group (EEG) have the problem on their radar.

 

Enough talking

 

If you want to know more about Spring Dynamic Modules, see the project page and the reference documentation and do use our mailing list (the forum will appear shortly). Moreover, lately we worked on some OSGi/Spring DM screencasts which are available on the Spring DM home page. The first one (composed by two parts), made by yours truly, shows how to quickly create a project to do integration testing with Spring DM.
Why integration testing? Since with Spring DM it's a very simple and fast process and a very effective way to learn about OSGi (especially with regard to modularity).

There will be more screencasts in the future - just let us know what you'd like to see and based on the number of requests, we'll queue them accordingly.

Without further ado, "Using Spring DM for OSGi integration testing":

 

Spring's dependency injection (DI) mechanism allows configuring beans defined in application context. What if you want to extend the same idea to non-beans? Spring's support for domain object DI utilizes AspectJ weaving to extend DI to any object, even if it is created by, say, a web or an ORM framework. This enables creating domain behavior rich objects, since domain objects can now collaborate with the injected objects. In this blog, I discuss the latest improvements in the Spring framework in this area.

The core idea behind domain object DI is quite simple: An AspectJ-woven aspect selects join points corresponding to creation or deserialization of any object matching certain specification. Advice to those join points inject dependencies into the object being created or deserialized. Of course, the devil is in the details. For example, how do you select join point corresponding to deserialization or how do you inject dependency only once per object? By offering a few pre-written…

Job listings are a good indicator of the true adoption of technologies. They indicate whether or not companies are spending money, making it possible to distinguish substance from hype; they indicate the importance for developers of gaining and growing the relevant skills (an important element of technology perpetuation); and they provide a good guide to the safety for companies in adopting a particular technology.

Thus the jobtrends site of Indeed.com, a job listing aggregation site, is an important resource. It allows trends in the number of job requirements to be tracked over time, and…

Note: This post has been edited to reflect Spring's move to Pivotal. A more recent blog on Spring Training and Certification is here.

Since I joined SpringSource six months ago as the Director of Training, I have been hearing one consistent request. Based on the growing demand for Spring skills, developers and consultants worldwide are seeking quantifiable ways to demonstrate their Spring expertise. Likewise, the hiring managers behind that demand are asking for a certification program to help identify and hire technologists who have an immediately useful, baseline knowledge of Spring.

Much like the way the Spring project teams respond to the needs of the open source community, we have responded and are pleased to announce the SpringSource Certification Program. This program kicks off this month, January 2008, with the Spring Framework Professional…

Quite a day for news as we complete our first annual Spring eXchange in London. First, the news that Sun Microsystems acquired MySQL, and then the long anticipated acquisition of BEA Systems by Oracle. Before commenting any further, I want to congratulate all of our friends at MySQL, especially Mårten Mickos, and all of our friends at BEA. The trend of consolidation in this industry is increasing.

As an open source company, we are thrilled to see MySQL rewarded for their effort. We have seen how hard Mårten and his colleagues have worked to build their software, community and a strong…

Last Friday was Tony (C.A.R.) Hoare's birthday. Who is C. A. R. Hoare? If you're a programmer, you're probably familiar with Quicksort--an elegant and surprisingly simple sorting algorithm that is blazingly fast in most cases. If you studied computer science, you've almost certainly implemented Quicksort in numerous languages, and will recognize the animation on this page. Hoare invented Quicksort in 1960, and it's now the most widely used sorting algorithm.

Among other contributions, Hoare also invented the Communicating Sequential Processes (CSP) language used to specify the interactions of…

At The Spring Experience, I hosted a session various aspects. One of them was the Hibernate synchronization aspect that I described last week. Another was an aspect capable of capturing first failures and system state, sometimes called First-Failure Data Capture (FFDC). I hosted this session to show off some aspects that are very useful, but that people might not have come across in practice yet. I often hear people asking about aspects other than logging, tracing, transaction management and security. The Hibernate synchronization aspect and the FFDC aspect are nice examples I think.

Introduction

The objective of FFDC is to capture as much information about the current state of the system when an error occurs. The following entry explains how this aspect works and how you can use in your own applications.

Let's…

Mixing code in one and the same transaction that uses an Object-Relational Mapper with code that doesn't, can cause issues with data not being available in the underlying database when it should be. Since this is a situation I come across once every now and then, I figured it would be helpful for all if I write down my solution to this problem.

In short: what I will present in the remainder of this post is an aspect that triggers the underlying persistence mechanism (JPA, Hibernate, TopLink) to send any dirty data to the database.

I presented this aspect by the way during one of my sessions at The Spring Experience last December and this post also has the source code for those of you…

It has been quite a year for Spring.NET. We have gone through two milestone and two release candidates before the GA release in December. The first chunks of code for the 1.1 release were made way back in late 2004 by Aleks Seovic who started work on the ASP.NET framework. In short, it has been a long time in the making. Being the end of year, a natural time for reflection both past and present, I'd like to say thanks to the other members of the project and the Spring.NET community for all their contributions and support. I'm looking forward to a great 2008!

The feature set of Spring.NET 1.1 is quite broad. An IoC container for Dependency Injection, AOP, ASP.NET framework, declarative transaction management and more. However, the biggest bang for the buck you can get to improve the structure and testability of your code is to add Dependency Injection and AOP into your proverbial developer tool chest. Dependency Injection is the more foundational…