In a recent post on the Pulihora blog, the author questions Spring’s capability of handling non-singleton objects, amongst others.

While there’s truth in some of his arguments, I’d like to elaborate on two of them.

First of all I’d like to touch base on what Spring offers (and will offer in the near future) in the area of support for non-singleton objects. Spring has had support for prototypes and other instantiation and scoping strategies since the early beginning. There are some limitations.

For the ‘Singleton A that needs Prototype B’ problem, Spring provides several options such as lookup-methods, target sources and manual lookups. I’m not going to discuss these in detail here and if you’re reading more about them, you’ll find out that each one of them has its pros and cons, but that’s not what I’m here to talk about. The bottom-line is that Spring’s DI container provides support for solving this problem and although it might not be perfect, it’s still better than what we used to code (custom factories, et cetera). Dependency Injection is a good idea and when you keep in mind the limitations of the underlying technology in practice it actually works out pretty well.

The author of the blog entry also mentions another limitation, namely the lack of support for temporal objects and sharing (stateful) prototypes. Spring has had support for this for a long time already through the use of the ThreadLocalTargetSource for example. This target source allows you to create thread-bound objects. Target sources can be implemented for different scopes if you like and something like this is exactly what Spring 2.0 will be offering. Through the use of a generic scoping mechanism you can create objects in any arbitrary scope (with out-of-the-box support for the HttpSession scope and the HttpServletRequest scope). Implementing new scopes is pretty easy and creating scoped objects is merely a matter of (something like) the following:

Another thing I’d like to say is that we’re certainly not there yet. Through the use of ApsectJ and by improving the core container itself, we’ll continue to improve the capabilities of the DI features in the coming time.

On the subject of remoting; the author of the blog entry has clearly not read Spring’s documentation well enough. Spring has support for several remoting protocols, including Hessian, Burlap and HttpInvoker. Spring however does support exporting RMI services and RMI-IIOP services as well. With respect to transaction propagation, I guess it’s just a matter of getting the right infrastructure in place (a remote capable JTA transaction manager and so on).

Resources:

• Transaction: How Distributed Are You? by Peter Holditch, 2004
• Spring Instance Management - part I - pooling by myself in 2005