sorted by: recent | see : popular

Content Tagged with License:ASF2.0 + Spring

In this blog entry I introduce small library that extends base functionality of Spring framework by allowing specifying references between in beans using "opposite" direction of them comparing to standard Spring approach.

What I’ve tried to solve

Several days ago I’ve blogged about necessity and possibilities of specifying dependencies in Spring context using "opposite" direction of references.

In just two words, if we have, say, two beans defined within context, and first bean refers to other bean, that reference should be described within bean context configuration XML directly as part of referring bean definition. This is casual and "natural" Spring way of defining dependencies between beans.

However, for some types of applications that approach does not work. The major drawback of it is as follows: during definition of referring bean it’s assumed that the name of bean to which it refers is known.

Unfortunately, for applications that are built using plugin architecture, that assumption becomes serious limitation, since it does not allow to create really extensible application without necessity of Spring context modification – of course, that does not corresponds to overall idea of plugins at all. And that’s even more sad if we’ll consider functionality that is already included into Spring – like creation of application context from several files that could be resolved dynamically (say, via direct list of their locations or via wildcards withing classpath).

Therefore, to obtain truly extensible applications, we need to have ability to "extend" existing content of Spring context.

From that point of view, the application may include, for example, one or more Spring configuration files with beans that represents "extension points" and, several dynamically loaded modules of plugins which may include beans that may be plugged into that extension points.

The following picture illustrates this concept:

What should be considered as extension point there? Well, the answer is pretty simple there – just properties of some beans. We have named bean, we have named property – so we could address the point where we could inject our reference pretty precise.

Of course, in extending context we need to know names of beans and properties to which we may inject beans from extending contexts. However, this issues is completely different to original approach of Spring – in such case, beans in "core" context represents a kind of dynamic API (pretty funny, but I suppose that such and context definition may be considered as API without API), and at the moment of defining beans in "core" context we are completely not aware how ones will be customized later (or even probably by third-party plugin developer).

Ok, now that we have extension points, the only thing we need to make the entire concept of such injection live is just an ability to specify that beans should be wired outside of referencing bean definition.

In other words, here we need to have some mechanism which will said Spring that beans should be wired not in "core" context, but directly in "extending" one.

The following picture illustrates difference between "normal" and "opposite" directions of references:

Now we are almost ready to move further. The only thing that we need to consider at the moment is types of references. Spring provides several standard ways to specify references between beans:

• using ordinary reference;
• using list of beans;
• using map of beans;
• using set of beans.

And, of course, there is ability to specify value of particular property. If we’ll look on these ways of defining relations between beans it will be clear that it’s quite possible to use opposite direction of injection to support them.

Inject4Spring overview

Well, that was background for tasks which are solved by Inject4Spring library. It’s a small (about 35k in jar) library which I wrote about year ago to have support of such "opposite" directions of specifying references between beans. At the moment, we’ve used it in several projects developed in SoftAMIS. Inject4Spring is released under Apache License, so it could be used both in open source and commercial applications.

In general, while it could be used for Spring 1.x, primarily it’s targeted to Spring 2.x, since it heavy relies on custom namespaces functionality introduced in Spring 2.0. Actually, from the usage point of view, all functionality of that library is exposed via set of custom XML tags that belongs to "inject" namespace.

Here is brief overview of possible types of dependencies in Spring and custom tags included into Inject4Spring that corresponds them:

License and download

Inject4Spring is released under Apache License, so it could be used both in open source and commercial applications. At the moment, you may to download it directly from our site, but probably later I’ll move it as project on SourceForge or something like that.

At the moment it’s quite stable and we’ve used it during last year for several projects. However, if you’ll have some comments, issues, requests for improvements – please do not hesitate contacting me

---

The Inject4Spring library was developed in SoftAMIS, a Ukraine based software development company specialized on Java and Web development outsourcing services. To find more about SoftAMIS, our services, skills and experience, please visit our site –

http://www.soft-amis.com

The home page of Inject4Spring is currently located here

Spring is a Java/J2EE application framework that assembles components via configuration files. Spring is an open source project but is developed by engineers with Interface 21, and Spring Framework is a trademark of Interface 21. Spring is supported by a number of companies including Interface21 and SourceLabs, and is covered in SourceLabs Self-support Suite for Linux and Open Source Java

Spring’s core technical selling point has been the Inversion of Control design idea, where programming is focused on interfaces rather than classes. Spring’s design comes from the book Expert One-on-One J2EE Design and Development by Rod Johnson.

Mission

Spring’s mission statement as articulated by Interface21 includes these points:

1. J2EE should be easier
2. Interfaces > Classes
3. JavaBeans are good for configuration
4. OOP > implementation technology (J2EE)
5. Testability is important and should be easier
6. Frameworks shouldn’t force recoverable exception catching

And these direct points about Spring

1. Spring should be a pleasure to use
2. Spring APIs should not be a dependency
3. Spring should not compete with good existing solutions like JDO and Hibernate.

External Links

• Spring tutorial
• Spring FAQs
• Introduction to Spring Web Flow
• Spring – iBatis integration tutorial
• Spring 1.1 locations of jar files in Spring that potentially cause classpath problems

From Rod Johnson

• Original introduction to Spring
• Video presentation of Spring

Reviews of Spring

• A Spring Jump Start
• On the MVC model of Spring
• Spring: creating objects so you don’t have to
• 5 Things I Love About Spring

Critiques of Spring

• a critique of spring, and the abuse of the spring framework
• I don’t get spring

Spring-dashboard provides a real-time statistics and flow monitoring view of any spring-framework web application.

Status

Release 1.0 contains a framework for gathering statistical runtime information on a Spring Web application, a configurable dashboard view with a default AJAX implementation, and an example application that demonstrates Spring-Dashboard’s basic abilities.

Spring IDE for Eclipse provides plugins for the Eclipse platform to ease working with Bean Factory configuration files for the Spring Framework.

It contains a Spring project nature (with an incremental builder for validating Spring bean config files), an image decorator (which decorates Spring projects and all Spring bean config files), a Spring view (which allows one to browse Spring projects and their Spring bean config files, including bean properties), and an editor showing a graph from the beans of a single config file or a set of config files.

Lingo is a lightweight POJO based remoting and messaging library based on Spring’s Remoting which extends it to support JMS and support a wide range of message exchange patterns including both synchronous and asynchronous message exchange.