Why Spring, Benefits using Spring Framework?

Following are the several reasons why I prefer Spring Framework:

1. It addresses important areas that other popular frameworks don't. Spring

focuses around providing a way to manage your business objects.
2. Spring is comprehensive and modular. Spring has a layered architecture,
meaning that you can choose to use just about any part of it in isolation, yet
its architecture is internally consistent. So you get maximum value from your
learning curve. You might choose to use Spring only to simplify use of JDBC,
for example, or you might choose to use Spring to manage all your business
objects. And it's easy to introduce Spring incrementally into existing projects.
3. Spring is designed from the ground up to help you write code that's easy to
test. Spring is an ideal framework for test driven projects.
4. Spring is an increasingly important integration technology, its role recognized
by vendors large and small.
5. The Spring Framework is the core of the Spring Portfolio , an increasingly
complete solution for enterprise Java development, exhibiting the same
consistency of approach developed in the Spring Framework itself.

#3
25-04-2009

pancham Join Date: Dec 2008

Posts: 144
Member
Re: Why Spring, Benefits using spring framework?
Architectural benefits of Spring

• Spring can effectively organize your middle tier objects. Spring takes care of
plumbing that would be left up to you if you use only Struts or other
frameworks geared to particular J2EE APIs. And Spring's configuration
management services can be used in any architectural layer, in whatever
runtime environment.
• Spring can eliminate the proliferation of Singletons seen on many projects. In
my experience, this is a major problem, reducing testability and object
orientation.
• Spring eliminates the need to use a variety of custom properties file formats,
by handling configuration in a consistent way throughout applications and
projects. Ever wondered what magic property keys or system properties a
particular class looks for, and had to read the Javadoc or even source code?
With Spring you simply look at the class's JavaBean properties or constructor
arguments. The use of Inversion of Control and Dependency Injection
(discussed below) helps achieve this simplification.
• Spring facilitates good programming practice by reducing the cost of
programming to interfaces, rather than classes, almost to zero.
• Spring is designed so that applications built with it depend on as few of its APIs
as possible. Most business objects in Spring applications have no dependency
on Spring.
• Applications built using Spring are very easy to test. For certain unit testing
scenarios, the Spring Framework provides mock objects and testing support

Classification: GE Internal
 classes. Spring also provides unique “integration testing” functionality in the
form of the Spring TestContext Framework and legacy JUnit 3.8 support
classes that enable you to test your code quickly and easily, even while
accessing a staging database.
• Spring helps you solve problems with the most lightweight possible
infrastructure. Spring provides an alternative to EJB that's appropriate for
many applications. For example, Spring can use AOP to deliver declarative
transaction management without using an EJB container; even without a JTA
implementation, if you only need to work with a single database, or want to
avoid two phase commit.
• Spring provides a consistent framework for data access, whether using JDBC or
an O/R mapping product such as TopLink, Hibernate or a JPA or JDO
implementation.
• Spring provides a consistent, simple programming model in many areas,
making it ideal architectural "glue." You can see this consistency in the Spring
approach to JDBC, JMS, JavaMail, JNDI and many other important APIs.

#4
25-04-2009

Adley Join Date: Oct 2008

Posts: 132
Member
Re: Why Spring, Benefits using spring framework?
If you use Spring you can scale up in power a bit. Some of the benefits are:

• Declarative transactions.
• More testable code.
• Promotes good OO design
• Removes boilerplate code
• Great lightweight remoting support
• Good documentation and samples.

Spring MVC also has advantages over Stuts:

- No ActionForms. Bind directly to domain objects
- More testable code (validation has no dependency on Servlet API)
- Well defined interface to business layer

For example of Spring reducing the boilerplate code, it can turn:

Code:
public List findAllEmployees() {
SessionFactory sessionFactory = new
Configuration().configure().buildSessionFactory();
Session session = sessionFactory.getSession();
try {
return session.find("from Employee order by surname, firstname");
} finally {
try {
session.close()

Classification: GE Internal
} catch(HibernateException he) {
throw new CustomRuntimeDAOException(he);
}
}
}
into
public List findAllEmployees() {
return getHibernateTemplate().find("from Employee order by surname,
firstname");
}

In 1990, I discovered white water. I thought I was completely in control. Whenever my

friends and I ran the smallest rapid, we'd leave one boater at the end of the rapid and put
two boaters on the banks with throw ropes. We thought we could prevent anything bad
from ever happening. While it was nice to have that illusion of perfect control, it just
wasn't practical. We learned to scout the easier rapids from the cockpit of the boat and
take steps to look out for each other. We took more time to set up good safety measures
for the most dangerous rapids. And in a few instances, that extra time made all the
difference in the world.

In kayaking, a lightweight strategy born on southeastern steep creeks saved me time so I

could paddle longer rivers and have more fun without compromising safety. In business,
lightweight development lets you finish on time and react to your customers, saving you
time and money.

In this series of articles, I focus on the basics of lightweight development -- an

overloaded term if ever there was one. This first article sets the groundwork and defines
lightweight development. Future articles will move freely from process to principles to
tools. I'll also focus on implementation philosophy and architecture at a higher level, and
provide actual implementation details in code.

This series is for developers who haven't done much lightweight development. If you've
used the Spring lightweight container for two years with an agile process, you might not
gain much. However, if you've worked with Enterprise JavaBeans™ (EJBs) in a
traditional development process, but want to move to lightweight development, this series
may be just the thing for you.

More than anything, I want to shed some light on this impressive movement sweeping
through the Java™ technology community. The lightweight buzzword graces containers
like Spring and Pico. And techniques from lightweight processes, such as automated unit
testing, now infiltrate many, if not most, development shops.

Classification: GE Internal
Debunking the myths of lightweight development

"Lightweight development" is usually attached to a set of development methods,

frameworks, and design philosophies that go well together.

• Lightweight methodologies include agile processes like extreme programming

(XP) and Scrum. They emphasize test-first development, heavy customer
involvement, and refactoring.
• Lightweight frameworks usually encourage programming with plain old Java
objects (POJOs) over heavier component-oriented models like EJB.
• Lightweight design patterns let you loosen coupling between objects and integrate
services without forcing code into business logic or the domain model.

As we investigate these ideas and technologies, you'll learn more about each one. But
first, let's clear up a few myths.

Myth: Lightweight developers play with toy technologies

Some development tools, like Microsoft® Visual Basic or PHP, often don't scale or
manage complexity well enough for large enterprise projects, so they earn the toy label.
Lightweight technologies like Spring and Hibernate are often dismissed as such. In fact,
most lightweight techniques evolved in enterprise development because other techniques
let us down. The Spring framework evolved as a lightweight alternative to EJB.
Similarly, the XP method evolved based on some failures in an enterprise setting. The
principles in my Jolt-winning book Better, Faster, Lighter Java provide information
about tools successfully deployed at my customer sites, including some Fortune 500
companies. Lightweight technologies thrive in the enterprise realm.

Myth: Lightweight development strategies build toys

Likewise, you might be tempted to believe that lightweight development is useful only
for building toy applications. Your goal is to deliver precisely what your customers want
and need. Let me be clear: Lightweight technologies can build things that scale. In fact,
the most impressive scaling usually happens because simple, elegant, stateless designs let
the infrastructure do its job.

Myth: A lightweight process lets you ignore discipline

In lightweight development, you need to carefully plan and negotiate requirements, and
you have to build rigorous automated unit tests to enable better refactoring. You fully
integrate when you drop changes, and the automated build notifies you when a test case
fails or a change induces errors. Lightweight development must be more disciplined than
other techniques, but the discipline comes from different sources.

Classification: GE Internal
I'm suggesting that this development style goes beyond a single technology or process. If
you want to lighten up, you need to select principles, processes, and technologies that
make it easy to work that way.

Back to top

Principles

When all is said and done, you need to decide what you value and make decisions based
on those values. If I feel that clients are misguided or unfocused, I'll often help them
establish some core principles first. The following list is a good starting point:

• Strive for simplicity. This value should permeate all that you do. Your process
should produce only enough artifacts to get the job done. Developers should
always try the simplest approach that can solve a problem. Your tools should let
you build clear, simple solutions.
• Fix what's broken. Some development methods may discourage refactoring or
changes in a process because those activities do not directly contribute to
generating customer code. Lightweight development demands the freedom to fix
code that gets too complex or bug-ridden. Budget for it. Demand it.
• Automate unit tests. Preferably, you should code test cases first. You may not
have success with test-first development, but accumulating test collateral gives
you the freedom to refactor your code. I'll go even further: Extensive unit testing
improves your customer experience and the design in your code because it forces
you to decouple code that's bound too tightly together.
• Use short cycles and active customer participation. Many of the best
programming shops simplify by eliminating unnecessary artifacts. If you've got
great customer participation, massive functional specifications become
increasingly unnecessary. Customers will enjoy the interaction and appreciate
your short cycle times because you'll be delivering business value at regular
increments.

These principles don't completely encompass your technology choices and development
process, but they go a long way toward defining your development experience. When
managers know and follow these principles as well, developers have some ammunition
when combating an ineffective technology choice or unnecessary bureaucracy. After you
establish principles, it's time to carve out an effective process.

Back to top

Process

A tighter, faster development process usually takes ideas from a family of methods
known as agile development methods. These methods aren't for everyone, though. If you

Classification: GE Internal
have a large team and no real access to the customer or a suitable surrogate, you're better
off with a more traditional method. But many projects have small enough teams -- no
more than about a dozen people -- and sufficient access to a customer to make such
methods fly. Usually, agility embraces principles like these:

• Focus on an on-site customer and code, rather than other design artifacts. You can
use other artifacts, but only if they help you do your job. The process doesn't
require it.
• Simplify the documentation that you need. For requirements, prefer a line in a
spreadsheet to a fancy use-case diagram.
• Do only enough design work to get the job done. Don't anticipate design or
performance problems, and don't back yourself into a corner.
• For development, strive for simplicity, integrate your build at least daily, and
refactor when necessary.
• Automate your testing.

Even if you work in a traditional organization, you can take advantage of a trimmed-
down development process. The trick is to sell principles rather than methodologies.
While selling your manager on extreme programming -- or anything else with extreme in
the title -- can be tough, selling principles like improved unit testing often makes more
sense. In fact, many of my customers use this technique to work an agile development
process into their conservative organizations, but their bosses have no idea that anything
is different.

Think of this technique in terms of rhetoric. Principles are lightweight ideas that pack a
punch. A process is heavyweight rhetoric, and you'll have a much bigger problem
implementing it.

Back to top

Technologies

I've provided an overview of the design philosophies that most lightweight developers
need to know and the important open source technologies out there that leverage these
philosophies.

Dependency injection

The new breed of containers, called lightweight containers, all use a common design
philosophy: dependency injection. It's a complicated term for a simple idea. Dependency
injection lets you give an object and its dependencies to a third party. The third party then
creates all the objects and wires them together. For example, say a data access object
called myDao needs a data source called ds. The container creates them both and sets a
property:

Classification: GE Internal
Listing 1. Creating a third-party assembler
myDao = new Dao();
ds = new DataSource();
myDao.setDataSource(ds);

Of course, instead of creating a third-party assembler like this one, you could rely on a
framework to do it for you and to do additional work like providing configuration
support. The Spring framework, Pico, and HiveMind take on this role. Other frameworks,
like JavaServer Faces (JSF), also leverage dependency injection.

Aspect-oriented programming

With aspect-oriented programming (AOP), you can code common blocks of functionality
(called aspects) -- such as logging, transactions, security, or persistence -- in one place.
AOP lets you attach these aspects to POJOs, then specify a point in time (like the
beginning of a method or exception generation) and another aspect to attach. For
example, you might want to make a facade object-transactional. You would attach a
TransactionBegin aspect to the facade's methods when the method fired. Then you
attach a RollBack aspect to the facade's exception when an exception fired. Finally, you
attach a Commit aspect to the facade's method when the method ended. You do this work
in configuration, rather than in code. With this ability, you can make a simple POJO
transactional, secure, or remote-accessible.

You've essentially got declarative transactions on a POJO, an extremely useful capability

for enterprise applications. With these tools at your disposal, you might decide to forgo
EJB altogether or at least minimize its role. And that's precisely what lightweight
containers let you do.

Transparent persistence

Persistence, too, is settling on a simpler programming model. Transparent persistence

frameworks let you add persistence to applications through configuration rather than
code. Because most of the applications written these days are object-oriented and access a
relational database, some experts assert that the time for object-relational mapping is
finally upon us. The top persistence solutions that I have found are SolarMetric's Kodo
JDO and Hibernate (see Resources). I'll compare these solutions in detail later in this
series. Other lightweight solutions, such as iBATIS and the Active Record design pattern,
don't try to do object-relational mapping at all.

Back to top

Summary

Classification: GE Internal
Basically, in lightweight development, you:

• Incorporate process, technology, and philosophy.

• Prefer simpler technologies.
• Build on a solid, lightweight foundation.
• Strive for the best possible transparency.
• Use ideas that give you leverage, like dependency injection and AOP.

It's important to understand that neither technologies nor processes can completely define
lightweight development. It's an all-encompassing philosophy. As this series progresses,
you'll see different types of discussions about lightweight technologies and philosophies.
I'll focus first on open source frameworks with an emphasis on lightweight containers. In
future articles, I'll talk about implementing lightweight methods in conservative
companies and even some alternatives that go beyond Java technology. I'm excited about
this series, and hope you enjoy it.

Resources

Learn

• Read Better, Faster, Lighter Java by Bruce Tate and Justin Gehtland for a good
overview of lightweight development.

• Spring: A Developer's Notebook by Bruce Tate and Justin Gehtland can help you
get started quickly on Spring.

• Pro Spring provides a more comprehensive treatment of Spring.

• Heavyweight architectures, such as Enterprise Java Beans can be overkill for

everyday problems. "Secrets of lightweight development success, Part 2: How to
lighten up your containers" introduces lightweight containers and explains how
they can provide the services your business needs without tying you to a given
programming model.

• Learn the basics of lightweight containers in "Secrets of lightweight development

success, Part 3: The emergence of Spring."

• In Part 4 of the series, three popular containers are compared: Spring, HiveMind,
and PicoContainer.

• Lightweight development works best with a lightweight process, but it can be

tough to get a conservative company to adopt agile methodologies. Learn how
you can propose and promote lightweight processes in your organization in Part 5
of this series.

Classification: GE Internal
 • The developerWorks article "Object-relation mapping without the container"
shows you how to use Spring persistence with Hibernate.

• Read the developerWorks article "AOP@Work: AOP tools comparison, Part 1"
for a treatment of AOP, a lightweight technique that can give you much better
transparency.

• Visit the developerWorks Open source zone for extensive how-to information,
tools, and project updates to help you develop with open source technologies and
use them with IBM's products.

Get products and technologies

• Innovate your next open source development project with IBM trial software,
available for download or on DVD.

Discuss

• Get involved in the developerWorks community by participating in

developerWorks blogs.

I'm an avid mountain biker. Some mountain bikers love hardcore equipment -- behemoths
that are fully suspended (with huge shocks in the front and back) -- and push them to
unnatural limits. I ride in the hill country around Austin, Texas, where the many rocky
ledges mean I've got to have a suspended bike, but a behemoth won't work for me. I can't
make it up the grueling climbs with a lot of extra weight. I've got to have a light bike.

The Java industry has gone through a few similar fads. EJB technology provided
hardcore enterprise services. If you programmed to a complex component-based model,
you could put your business components into a container that would provide services
such as transactions, remoting, security, and persistence.

There was a cost, though. The heavyweight architectures were overkill for many
problems. For example, entity beans made you code up to seven files for each entity. EJB
technology just wasn't worth all the extra effort it took to solve everyday problems.
Today, businesses still need the enterprise services, but they're looking in a new direction
to get them. They're using lightweight containers. In fact, the new EJB V3.0 standard
uses the lightweight container model.

What are lightweight containers?

Most container APIs, like EJB APIs, force you to code to some interface or a component
model. You put your component into the container, and the container does something for
you. EJB containers provide enterprise services. Servlet containers, such as Apache
Jakarta Tomcat, implement the Servlet API, letting you build dynamic content into pages
on the server that can then be sent to a Web browser.

Classification: GE Internal
Where traditional containers force a given programming model, lightweight containers do
not. They let you insert plain old Java objects (POJOs). The container can then wire the
POJOs together and attach services to them. Common characteristics of lightweight
containers include:

• POJO-based programming -- Lightweight containers are not invasive. The

containers do not enforce any API.
• Life-cycle management -- Lightweight containers manage the life cycle of the
objects you put into them. Minimally, they instantiate and destroy objects.
• Dependency resolution -- Lightweight containers provide a common
dependency-resolution strategy. Major containers today support a strategy called
dependency injection. Some support a Java 2 Platform, Enterprise Edition (J2EE)-
style strategy called service locators, as well.
• Consistent configuration -- Lightweight containers are a convenient place to
provide consistent configuration services.
• Service attachment -- Lightweight containers provide a way to attach services to
the objects in the container.

The advantages

Lightweight containers have many advantages over other container architectures. For
example, you get to use a simpler programming model based on POJOs. Because you're
programming with POJOs, your applications are easier to test. Your objects can also run
outside the container -- for example, in a test case. Through dependency injection,
lightweight containers reduce dependencies between components. They also protect your
investment in code because you can move more of your application between containers.

Back to top

Core design patterns

A rapid wave of innovation fuels the lightweight container movement. Dependency

management drove the movement in the beginning. Early lightweight containers, such as
Apache's Avalon, used the service locator strategy to manage dependencies. All the major
modern containers now manage dependencies with dependency injection.

However, resolving dependencies is only part of the problem. You also need to be able to
attach services to the POJOs in the container. EJB containers handled this problem with
code generation. Modern containers use aspect-oriented programming (AOP) and
interceptors.

Dependency injection

In Java technology, dependency injection is rapidly changing the way we build

applications. The concept is relatively simple: A consumer (like the Consumer class

Classification: GE Internal
below) needs a service. You add a property to the consumer that points to the service
(like the Speaker class below). Listing 1 shows an example of this concept.

Listing 1. Example of dependency injection

class Speaker {
void speak(String words) {
System.out.println(words);
}
}

class Consumer {
Speaker mySpeaker;
void saySomething() {
mySpeaker.speak("something");
}
}

Notice the Consumer class. It doesn't instantiate the Speaker class. With dependency
injection, that job goes to a third party -- call it the Container class (see Listing 2).

Listing 2. The Container class

class Container {
public static void main(String[] args) {
Speaker speaker=new Speaker();
Consumer consumer=new Consumer();
consumer.speaker = speaker;
consumer.saySomething();
}
}

The Container class instantiates the Speaker and Consumer classes. Then the
Container class sets the speaker property to the new Speaker class. This last step
represents the dependency injection.

Back to top

The power of interfaces

Let's refactor this code a bit. Build an interface called Speaker, then a couple of different
implementations: a Canadian speaker and a Californian speaker. So, you now have the
Speaker interface:

interface Speaker {
void speak(String words);
}

Classification: GE Internal
the CanadianSpeaker and CalifornianSpeaker:

class CanadianSpeaker implements Speaker {

public void speak(String words) {
System.out.println(words + ", ay?");
}
}

class CalifornianSpeaker implements Speaker {

public void speak(String words) {
System.out.println("Like, " + words);
}
}

and the one-line change in the container:

... Speaker speaker=new CalifornianSpeaker();

Notice that you can now change between implementations of the speaker, and the only
code that needs to change is the container. More to the point, you could easily inject a
mock object instead of a real Speaker implementation, and you could do a test without
affecting the rest of your code base.

Of course, your ultimate goal is to replace this handwritten container with one written for
you. Take, for example, the Spring container. In this case, it replaces your Container
class, and you can use a simple XML file that looks like the code in Listing 3.

Listing 3. XML file for the Spring container

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="mySpeaker" class="CanadianSpeaker">

</bean>

<bean id="consumer" class="Consumer">

<property name="speaker"><ref local=
"mySpeaker"/></property>
</bean>

</beans>
</code>

Classification: GE Internal
Now you can load the context, get the Consumer bean, and run it like this:

ApplicationContext ac =
new FileSystemXmlApplicationContext("context.xml");
Consumer c=(HelloWorld)ac.getBean("consumer");
c.saySomething();

The Spring container does the same thing yours did. It instantiated the beans and wired
them together by setting the properties. Notice that the two pieces of code are completely
decoupled; the interface and the container make sure that's true. You can use dependency
injection to satisfy the many dependencies you run across when you're doing enterprise
development, like data sources or transaction managers.

You can also see that the natural layers of an application naturally depend on each other.
You might have a Web user interface (UI) view that's called by a controller, which calls a
facade layer, which calls a data access object, which calls an object-relational mapper,
which calls a database. These relationships are dependencies. If you can decouple them,
you can more easily code, test, and maintain them.

Back to top

Interceptors

Dependency injection lets you weave together the main layers of your application, which,
in turn, lets you produce a loosely coupled application with view, model, and controller
layers. But lightweight containers solve another problem. You often have concerns --
such as logging, remoting, or security -- that hit many parts of your application. EJB
technology solved this problem with code generation and a container/component
interface. We can do better.

You can code your crosscutting concern in one place, then use a technique called the
interceptor to tie that code to methods that might need it. Say, for example, a caller wants
to invoke a method called speak(). Using the interceptor strategy (see Figure 1), you
create a proxy in front of the target object with the speak() method. The proxy should
have a speak() method with the same interface that the original target object has. When
the caller invokes the proxy, you're free to add any custom features you may require
before invoking the real method.

Figure 1. Staple interceptor strategy for lightweight containers

Classification: GE Internal
Using interceptors, you can effectively add custom services like security, declarative
transactions, and remoting to methods on your POJOs. Here's the kicker: Neither the
calling code nor the invoked method needs to change at all. Further, containers like
Spring come with prepackaged interceptors to perform these tasks and more.

Back to top

Aspect-oriented programming

AOP takes things one step further. With AOP, you can quickly specify all the methods
that require a given service at once, often using regular expressions. AOP programmers
call this collection of methods a point cut. For example, you may want to attach
declarative transactions to all the methods in a facade. For methods starting with insert
or update, you may want full transaction propagation; but for other methods, you may
want lightweight read-only propagation. (The EJB specification defines types of
transaction propagation. You just need to know that full propagation is more expensive
than read-only propagation, but it's also safer and necessary for certain types of updates.)

You get the right transactional behavior, in the right place, without modifying any code in
the caller, or the target method. Listing 4 shows part of a Spring context that specifies the
point cuts for such an application.

Listing 4. Code to specify point cuts in a Spring container

<property name="transactionAttributes">
<props>
<prop key="insert*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>

Back to top

The players

You can well imagine that many people would try to build lightweight containers. The
lightweight container space is rapidly consolidating around a few players: Spring, Pico,
HiveMind, and EJB technology.

Spring

Leading the charge is the Spring Framework. Spring uses XML configuration and relies
on setters for dependency injection. It can also use constructors or factory methods, but
most examples you'll see -- and the Spring code base itself -- focus on setters.

Classification: GE Internal
Spring goes beyond its lightweight container by adding a whole host of beans with glue
code. With the beans and code, you can drop in hundreds of different kinds of
components that let you use J2EE APIs, persistence engines from JDO to Hibernate,
workflow engines, view technologies, and dozens of other things. Spring is rapidly
maturing and has the critical mass to be a player for the foreseeable future.

Pico

The Pico container is the smallest available. The primary differences between Pico and
Spring relate to style. Pico programmers rely first on constructors to do injection. Instead
of XML, Pico uses Java code to register beans in the container. Like Spring, Pico also
supports setter injection, but the emphasis is strongly on constructors. Pico doesn't have
nearly the amount of support that Spring has. It's primarily a dependency injection
container. However, Pico is an excellent choice when you don't need all the enterprise
services Spring provides.

HiveMind

HiveMind is the newest of the open source lightweight containers. HiveMind has more
supporting modules than Pico does, but not nearly as many as Spring has. HiveMind
does, however, let you use Spring beans and services. It can manage dependencies with
both setters and constructors. HiveMind's primary contributions are two important ideas:

• A packaging concept called modules, loosely based on the Eclipse plug-in model,
lets you manage dependencies at a coarse-grained level.
• A documentation facility called HiveDoc lets you generate reference
documentation for the modules in the container, much like Javadoc lets you
generate documentation for your Java code.

It's too early to tell whether HiveMind will have a major impact.

EJB technology

Think about the things you do with EJB technology today, such as declarative
transactions, remoting, and security. If you could do most of what you do in EJB
environments with a lightweight container instead, why wouldn't you? That question is
compelling enough to force a massive redesign of the core EJB architecture, and the EJB
V3.0 expert group decided to do exactly that. EJB V3.0 will effectively implement a
lightweight container strategy. The primary differences between the current EJB
architecture and the new V3.0 architecture: The container will provide the primary
services you use and you'll be able to use XML to configure the container, but EJB
technology will also rely heavily on annotations for configuration.

Some good consultants have expressed concern about what they call overuse of
annotations in EJB technology. I also have my reservations, but EJB technology has
bigger problems. The EJB group must deliver something soon, or the lightweight

Classification: GE Internal
containers may render EJB technology irrelevant. Customers can already do most of what
they need to do with Spring. By the time EJB technology is used in volume, it may be too
late.

Back to top

Wrapping up

So, now you've seen an overview of lightweight containers. You know the basic design
philosophies:

• Build a container that accepts POJOs, rather than restricted components

• Use dependency injection to loosen and resolve dependencies
• Use interception and AOP to attach services to POJOs

In the next couple of articles, I'll take a more exhaustive look at the major lightweight
containers and indicate where you might use each. Then I'll take a fuller look at Spring,
the most popular container. I told you at the beginning of this article that I needed to
lighten up my bike without sacrificing my suspension. Now you know how to lighten up
your container without sacrificing enterprise services.

Happy trails!

In 2003, three mountain bikers and I screamed down the ledge-filled trail called Forrest
Ridge. It had just reopened, without fanfare, so most of Austin, Texas, didn't know.
Throughout that autumn, we had been running this gem alone. On this day, we had to
dodge more than 20 other bikers on a short stretch of trail. The secret was out.

Although the public discovery of our wonderful trail wasn't a good thing for my friends
and me, it is a good thing when your open source trail gets discovered. You can find
resources more easily, get fixes more quickly, and in general take advantage of the
additional community. Now, Spring has now been discovered. It's among the most
important open source projects, and it's well on its way to achieving Hibernate-like
success as a major player both in and out of enterprise environments. This article shows
you why Spring is so significant to lightweight development.

What is Spring?

If you're an enterprise developer, Spring can make your life easier. But what is it? With a
framework this comprehensive, that's not an easy question to answer. Basically, Spring is
a lightweight container. With Spring, you can program with plain old Java™ objects
(POJOs), resolve dependencies between them with dependency injection, and attach
services to them with aspect-oriented programming (AOP).

Classification: GE Internal
Spring also provides some glue code that makes it easier to use Java 2 Platform,
Enterprise Edition (J2EE) services, such as Java Transaction API (JTA), for transactions,
Remote Method Invocation (RMI) for remoting, Java Management Extensions (JMX) for
management, or Java Data Objects (JDO) for persistence. Spring also provides glue code
for open source frameworks, such as Hibernate, Tapestry, Struts, and JavaServer Faces
(JSF). Notice that some of the frameworks compete, and that's OK: Spring doesn't try to
pick a winner.

Some services are available with Spring. For example, Web Flow makes handling the
flow between Web pages easier. Similarly, Web MVC provides a Model-View-Controller
(MVC) architecture for Web-based applications that is similar to Struts.

So, Spring casts a broad shadow. Like Enterprise JavaBean (EJB) technology, Spring's
container lets you consume enterprise services. Unlike EJB 1.x and 2.x, however, you put
JavaBeans -- not some proprietary component -- into the container. In another separation
from EJB, Spring doesn't lock you into just a few standardized services. Instead, it lets
you choose from hundreds of services, or even build your own.

To me, Spring is the most important open source project in the Java community. It's
helping redefine J2EE. Partially as a result of the pressure from innovations in Spring, the
EJB 3 expert group built a specification describing an interface more like Spring's than
EJB 2.x. I can easily imagine a scenario in which Spring becomes as ubiquitous as Struts
for enterprise development. To help you understand why Spring is so important, let's peel
back the layers.

Back to top

The core container

First, look at how Spring works. I won't post full examples because you can find dozens
of Spring tutorials. Instead, I point you to the sample application for my latest book and
post snippets of that example to show what Spring can do for you.

The application simply maintains a list of bikes for an operation called RentaBike. Spring
serves as the backbone for the application. Spring's main container, the context, holds
references to all the main layers of the application and services. The main layers of the
application are a database, a persistence framework, a database access object, and user
interface (UI) controller and view layers.

The Spring context for the application is simply a list of beans the application uses. The
beans don't have to rely on any Spring interfaces, but sometimes, I choose to rely on
Spring to provide some of the repetitive glue code that holds the application together. In
the context, you'll find at least five types of metadata:

Classification: GE Internal
 • Configuration -- Because the container already has to do some configuration to
handle dependency injection (covered in Secrets of lightweight development
success, Part 2: How to lighten up your containers), it makes sense to handle other
configuration here, too, so that you have a convenient, consistent strategy.
• Major layers of the application -- In the RentaBike application, I expose a Data
Access Object (DAO) layer, a controller layer, and a view layer (see Listing 1). I
choose to wrap the DAO in an interface, so I can switch my data access layer to
use different persistence strategies.
• External dependencies -- For instance, my DAO needs a data source. Spring
injects the resources my DAO needs, such as data sources, and platform-specific
configuration, such as Hibernate's session factory.
• Transparent services -- One of the biggest benefits of EJB technology was
declarative transactions. You had to pay a lot to get them because you were forced
to use an EJB interface and heavyweight EJB containers. Spring lets you
configure only the services you need and apply them to POJOs. In Spring, you
can make any method transactional.
• Data -- Often, message data, information about application flow, and test data
might also be placed in the application context.

Listing 1. A partial context for RentaBike

<beans>

<bean id="rentaBike" class="com.springbook.JDBCRentABike">

<property name="storeName">
<value>Bruce's Bikes</value>
</property>
<property name="dataSource">
<ref bean="dataSource" />
</property>
</bean>

<bean id="bikesController" class="com.springbook.BikesController">

<property name="facade">
<ref bean="rentaBike" />
</property>

</bean>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManag
erDataSource">
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost/bikestore</value>
</property>
<property name="username">

Classification: GE Internal
 <value>bikestore</value>
</property>
</bean>

</beans>

If you look closely at a context, you'll notice that it's made up of beans. That's important
because earlier J2EE containers forced you to use a given API, especially EJB. Each bean
has a set of properties. Some are strings and other primitive values. Some are beans, like
the data source required by the rentaBikebean. You don't have to implement an API,
like the interface for EJB session beans. You just list beans and their properties. Some of
the properties satisfy dependencies. You've got better transparency, so you can run your
beans outside the container or move your application to other containers, should the need
arise.

Contexts for testing

You may wind up putting other types of beans in the context, too. For example, it often
makes sense to use the context to populate simple test data, or application flow, in the
context. In Spring: A Developer's Notebook, we drive the first implementations of our UI
with a stub that uses an array list instead of a database. Say I've got a database table with
names and e-mail addresses. I can build a simple stub that has an array list as a property,
then implement some simple data access methods quickly, as Listing 2 shows.

Listing 2. A testing stub to replace a database

public class StubEmailDirectory {
private List people;
public List getPeople() {
return people;
}
public void setPeople(List people) {
this.people = people;
}

public String findEmail(String name) {

Person p = findPerson(name);
if (p==null) {
return null;
}
return p.getEmail();
}
.
public Person findPerson(String name) {
if (people==null) {
return null;
}
int size = people.size();
for(int i=0;i<size;i++) {
Person p=(Person)people.get(i);

Classification: GE Internal
 if(p.getName().equals(name)) {
return p;
}
}
return null;
}
}

I can then populate it from the context, as Listing 3 shows.

Listing 3. Test data in a context

<beans>

<bean id="bruce" class="j2life.bus.Person">

<property name="name">
<value>Bruce</value>
</property>
<property name="email">
<value>bruce.t@j2life.com
</value>
</property>
</bean>

<bean id="maggie" class="j2life.bus.Person">

<property name="name">
<value>Maggie</value>
</property>
<property name="email">
<value>maggie.t@j2life.com
</value>
</property>
</bean>
<bean id="emails" class="j2life.bus.StubEmailDirectory">
<property name="people">
<list>
<ref bean="bruce"/>
<ref bean="maggie"/>
</list>
</property>
</bean>
</beans>

When you think about it, drawing test data from a context often makes sense. To make
test cases repeatable and verifiable, you can draw unpredictable data, such as system
times and random numbers, from a context instead of from the services. Spring's context
makes testing much easier because you can configure applications in different ways for
production and testing.

Classification: GE Internal
The foundation of Spring is the container, and it's important. But the container doesn't
even come close to telling the whole story.

Back to top

Leverage

Like me, world-champion cyclist Lance Armstrong is from Austin, Texas. I've enjoyed
watching him bike through the years, in part because he gets more leverage out of each
turn of the pedals than anyone else in the world. I look for opportunities for additional
leverage with everything I do. Spring gives me better leverage by providing glue code
that takes away the cumbersome repetitive resource management, configuration, and
grunt work similar across my applications.

Take persistence. Hibernate is a beautiful persistence alternative. But like all persistence
frameworks, it forces you to manage some low-level details I'd prefer to do without.
Listing 4 shows an example of a Hibernate application without Spring.

Listing 4. Hibernate without Spring

// Configuration code
Configuration config = new Configuration( );
config.addClass(Bike.class).addClass(Customer.class).
addClass(Reservation.class);
SessionFactory mySessionFactory = Configuration.buildSessionFactory(
);

public List getBikesOldWay( ) throws Exception {

List bikes = null;
Session s = null;
try {
s = mySessionFactory.openSession( );
bikes = s.find("from Bike");
}catch (Exception ex) {
//handle exception gracefully
}finally {
s.close( );
}
return bikes;
}

Listing 5 shows a similar example, but with Spring.

Listing 5. Hibernate with Spring

public List getBikes( ) {
return getHibernateTemplate( ).find("from Bike");

Classification: GE Internal
}

Look at the Hibernate template as the methods that implement things you'd want to do to
a session. Notice especially what you don't see. You don't have to worry about
transactions because Spring lets you configure them declaratively. You don't have to
worry about managing resources because that code is in the template. Spring always
closes the session, so you don't have to. You don't have to handle exceptions at this level
because Spring translates them to a common set of unchecked exceptions. I like
unchecked exceptions because I can choose to expose them at the appropriate level of the
architecture. You provide only the bare minimum needed to tell Hibernate what to do.
Spring handles the rest. That's leverage.

Spring provides leverage in other ways, too. By providing the same kind of glue code for
other services, Spring eases my burden as an application programmer. I don't have to
repeat myself nearly as often. I can use remoting, transactions, security, persistence, and
MVC code much more easily because Spring does the heavy lifting.

I'd like to point out that there is a down side here. When I decide to use Spring's glue
code instead of my own, I do build a dependency on the Spring framework. Most of the
time, I'm willing to pay that price.

Back to top

AOP

In Part 2 in this series, you learned that AOP can let you attach services to a POJO,
giving you much better transparency. With AOP, you can strip many cross-cutting
concerns right out of your code. So, why wouldn't you just download an AOP framework
and use it directly?

In reality, some teams do. It's been my experience that technologies are ready far before
we have the wisdom to use them. When I see AOP in the hands of intermediate and
novice programmers, I imagine kids with power tools. Face it: When it comes to AOP,
most of us are still kids. As it was with object-oriented programming, we've got to spend
a little time accumulating the wisdom it takes to use AOP effectively.

Spring gives me the ability to use AOP with training wheels. I can take some
prepackaged aspects and look at examples that show well-defined scenarios, thereby
getting much of the benefit of AOP without all the risk. In fact, you've often seen similar
strategies in the past. The Ada programming language allowed encapsulation, but only
limited inheritance. Early windowing environments like the Microsoft® Windows®
programming model internally had Window objects, events that looked like Smalltalk
messages, and even hierarchies, but exposed a procedural programming model. I believe
the same strategy is important for AOP.

Classification: GE Internal
Back to top

Spring's significance

For those who use it, Spring is revolutionary. These simple ideas lead to huge
consequences:

• Spring effectively opens up the enterprise services container. You no longer have
to be a slave to the API or services a container provides. You can use the Spring
context to manage prepackaged services, snap in third-party services, or write
your own.
• Spring represents a huge step forward in testability. With Spring, you can use
dependency injection to work mock objects into hard-to-reach places, run objects
outside the container (because they are POJOs), and even use the container to
serve unpredictable data.
• Spring's glue code makes it much easier to plug in enterprise services with very
little programming. You write less code, so you have to read less code for
maintenance or extension.
• Spring represents an open source project that's redefining the way in which Java's
commercial groups build their software. The influence of Spring on the latest EJB
specification is undeniable, and it's important.

Spring has become one of the pillars of enterprise lightweight development. The
resources below can show you how to get started or dig deeper into Spring. In the next
article in this series, I'll introduce you to a few persistence alternatives for lightweight
development.

May your favorite open source trail be discovered, too.

In a trip through Colorado in 2002, I caught the Arkansas River at a perfect level. The
river showcased stunning diversity across three different runs. The laid-back Brown's
Canyon run had wide open rapids with huge, fun wave trains. The characteristic cliffs of
the Royal Gorge channeled the power of the river beneath a massive vertical canyon, in
which little mistakes in the straightforward lines were punished with long swims. The
Numbers had nice drops requiring precise maneuvering among restricted boulder
gardens. In one river, I had three vastly different experiences.

In my last article, "Secrets of lightweight development success, Part 3: The emergence of

Spring," you learned the basics of lightweight containers. In this article, I walk you
through the three most popular containers:

• Spring Framework has a full-featured container, an aspect-oriented

programming (AOP) model, and integration code for just about anything you need
for enterprise development.

Classification: GE Internal
 • HiveMind, from the creator of Jakarta Tapestry, lets you perform dependency
injection for beans or larger components, called modules.
• PicoContainer is the smallest of the lightweight containers and uniquely supports
a Java™ technology-style configuration, rather than an XML configuration.

All these containers flow from dependency injection, but each has a vastly different
character. As I walk through a high-level description of each, you'll see each framework
in action, as well as where you can apply each framework.

Core philosophies

All of these containers accept plain old Java objects (POJOs), all have hooks for object
life cycles (so they can call your code when they create or destroy a bean), and they all
perform dependency injection. You might think these central themes would lead to
similar containers, but that's not at all the case. While the code that goes into each
container may be similar, the containers themselves reflect different capabilities, styles,
and overall philosophies. All in all, the authors of each container stay true to their
philosophies.

Spring Framework

The Geneva of open source frameworks, Spring Framework provides a lightweight

container and glue code for hundreds of Java 2 Platform, Enterprise Edition (J2EE) APIs
and open source frameworks. Spring has one overriding vision: to make J2EE easier to
use. After reading through some examples and books, you'll see some common themes:

• Spring supports three types of dependency injection -- setter, constructor, and

method injection -- but overall, the prevailing model is setter injection.
• Spring's XML-style configuration values flexibility over simplicity. You can do
just about anything, but the configuration files are hard to read and difficult for
novices to understand.
• Spring's founders believe that the container is a only small part of the overall
framework. Most of Spring's value comes from the thousands of lines of glue
code supporting the framework. It's easy to plug in just about anything.
• The Spring framework is the most complete and well polished of the three
container implementations. In particular, the excellent documentation is complete
and well written.
• Spring has an autowire mode, but most examples fail to use it. I don't quite
understand this decision, but at times, it's nice to see dependencies explicitly
listed.
• Spring provides a full AOP framework to make it easier to attach services. You
can use Spring's own framework or rely on the rich AspectJ integration (see
Resources).

If I were to characterize Spring with a phrase, I'd say, hardened for the enterprise.

Classification: GE Internal
HiveMind

Howard Lewis Ship, the creator of the Jakarta Tapestry Web framework, also created
HiveMind. As a container, HiveMind is clever, clean, and a joy to use. Like many of the
other, better, open source frameworks, Ship created HiveMind to help him solve real
problems. However, HiveMind adds a couple of new wrinkles to traditional lightweight
containers:

• The most important HiveMind innovation is the module. According to Ship, the
Eclipse plug-in inspired the HiveMind module.
• HiveMind forces you to program to interfaces. (Like all lightweight containers, it
doesn't impose an interface; you provide your own.)
• HiveMind is user-friendly, providing items like a documentation tool called
HiveDoc, a friendly and concise XML configuration, and line-precise error
reporting.
• HiveMind users typically prefer setter injection, but the container also supports
constructor injection.

If I were to characterize HiveMind with one phrase, I'd say it's conceptually sound.

PicoContainer

By far, the biggest overriding characteristic of PicoContainer is its size. It won't give you
a lot of extras, but it has a complete dependency injection container. PicoContainer also
has some unique properties:

• PicoContainer is small, so it doesn't have interceptors, AOP, or similar types of

services, preferring instead to let other frameworks create them.
• PicoContainer supports Java technology for configuration, rather than XML, like
the other containers.
• PicoContainer's prevailing usage model is constructor injection, although it also
supports setter injection.
• PicoContainer doesn't give you much documentation, and some of the existing
documentation is incomplete, although you don't need much.
• PicoContainer has one autowire mode, and it's nice.
• PicoContainer's development seems to have stagnated somewhat.

If I were to characterize PicoContainer with a phrase, I'd pick theoretically pure, but not
as practical as Spring or HiveMind.

Back to top

Programming model

Classification: GE Internal
Now I'll point you to programming examples prevalent in the community to help you
better understand how the authors of the containers would like you to use them. I use the
Kiss example from PicoContainer to showcase autowiring and Java technology-style
configuration, the HiveMind adder example to showcase the module capability, and the
Spring PetClinic application to showcase Hibernate integration.

The Kiss example (PicoContainer)

Of the three containers, PicoContainer has the simplest programming model. To see the
Kiss example, download it from PicoContainer.org. Install the example, browse to
docs\Two+minute+tutorial.htm, and you should see two components:

Listing 1. Two Kiss components

public class Boy {
public void kiss(Object kisser) {
System.out.println("I was kissed by " + kisser);
}
}
public class Girl {
Boy boy;

public Girl(Boy boy) {

this.boy = boy;
}

public void kissSomeone() {

boy.kiss(this);
}
}

These two classes are self-explanatory. Girl has a dependency on Boy. The dependency
will be injected through the constructor. You instantiate a container:

MutablePicoContainer pico = new DefaultPicoContainer();

Then you register the two components:

pico.registerComponentImplementation(Boy.class);
pico.registerComponentImplementation(Girl.class);

Later, you can ask PicoContainer for an object, then exercise it:

Girl girl = (Girl) pico.getComponentInstance(Girl.class);

girl.kissSomeone();

Classification: GE Internal
That's pretty much it. The programming model is elegant, and the constructor-based style
means you don't have to include a constructor without arguments. Calling such an
instructor on the Girl in this example would leave the object in an inconsistent state
because the kiss method would throw an exception.

The adder example (HiveMind)

Now, let's take a look at HiveMind's programming example. Download HiveMind from
The Apache Jakarta Project, then look at the adder example. You should see an interface
and an implementation. (Remember: HiveMind enforces interfaces.)

Listing 2. Adder example interface and implementation

public interface Adder
{
public double add(double arg0, double arg1);
}

public class AdderImpl implements Adder

{
public double add(double arg0, double arg1)
{
return arg0 + arg1;
}
}

You expose the service in an XML file, like this:

Listing 3. Expose the service in an XML file

<module id="examples" version="1.0.0">

<service-point id="Adder"
interface="org.apache.hivemind.examples.Adder">

<create-instance
class="org.apache.hivemind.examples.impl.AdderImpl"/>

</service-point>
</module>

Other applications could then use the service, like this:

Listing 4. Other applications can use the service

Registry registry = RegistryBuilder.constructDefaultRegistry();

Classification: GE Internal
Adder adder = (Adder) registry.getService("examples.Adder",
Adder.class);

... adder.add(arg0, arg1)

Notice that HiveMind's module lets you group together multiple services. If you needed
to add functionality to services in the container, you could use an interceptor:

Listing 5. Use an interceptor to add functionality

<module id="examples" version="1.0.0">
<service-point id="Adder"
interface="org.apache.hivemind.examples.Adder">

<create-instance
class="org.apache.hivemind.examples.impl.AdderImpl"/>

<interceptor service-id="hivemind.LoggingInterceptor"/>
</service-point>
</module>

The PetClinic application (Spring)

Spring approaches things just a little differently. Because the Spring framework doesn't
come with a simple application, I'm choosing one from my book, Spring: A Developer's
Notebook. You can get the sample code from O'Reilly Media. Crack open example 4,
which shows a CommandLineView object with a property for a RentaBike store, which
eventually becomes the data access object for this application.

Listing 6. CommandLineView object

public class CommandLineView {
private RentABike rentaBike;
public CommandLineView() {}
public void setRentABike(RentABike rentaBike) {this.rentaBike =
rentaBike;}
public RentABike getRentaBike() { return this.rentaBike; }
...
}

RentaBike is an interface with the types of methods you'd expect to see on a bike store
object:

Classification: GE Internal
Listing 7. Interface methods
public interface RentABike {
List getBikes();
Bike getBike(String serialNo);
void setStoreName(String name);
String getStoreName();
}

Not shown is ArrayListBikeStore, which is a stub implementation of the BikeStore

interface. Note that Spring allows interfaces, but doesn't enforce them. Here's the XML
configuration file, describing the beans in the application:

Listing 8. XML configuration file describing application beans

<beans>
<bean id="rentaBike" class="com.springbook.ArrayListRentABike">
<property name="storeName"><value>Bruce's Bikes</value></property>
</bean>
<bean id="commandLineView" class="com.springbook.CommandLineView">
<property name="rentaBike">
<ref bean="rentaBike" />
</property>
</bean>
</beans>

This context has two beans in it. The commandLineView bean depends on the rentaBike
bean. This application resolves the dependency explicitly by specifying the rentaBike
name for the rentaBike property. Note that PicoContainer automatically wires obvious
relationships like these, and Spring can, too, but most users don't use the autowire option.
Spring can also let you add services to any method of the façade through interceptors or
AOP.

Back to top

Comparisons

Now that you have seen the overall philosophies for each container, here's a more
detailed comparison of the intangibles of each environment, such as market share, fit and
finish, and the overall feature list. After all, even if the programming model is perfect, it's
not going to be a good container with no documentation or you have to support it yourself
because of a lack of community.

Active community

Classification: GE Internal
Spring has a vibrant community, as well as a professional services company called
Interface21 that supports the framework. That's important because you know you can get
excellent support, and the company is motivated to support the Spring framework. My
experience with the community has been nothing short of sensational. Spring
contributors, authors, and users alike pack the message board with outstanding content.

The HiveMind framework is an Apache Jakarta project, so it's on firm footing. It has a
budding community growing in activity. The framework's founder, Howard Lewis Ship,
is an independent consultant, an excellent instructor, and a tireless promoter. However,
it's still much more difficult to hire quality help for HiveMind or find content beyond a
few articles and what's on the Web site. Still, the online support seems good, and the
community seems to be growing. Hibernate scored an interesting victory when it was
chosen -- or, more likely, Ship was chosen -- to form the foundation of the new
infrastructure for TheServerSide.com, one of the most important online Java technology
communities.

PicoContainer, also an Apache Jakarta project, seems to be winding down. As of this

writing, the last major code drop for PicoContainer was in November 2004. You don't see
many new articles about PicoContainer, which is a shame because I like some of
PicoContainer's philosophies. In fact, I'm not sure that there's room for three open source
lightweight containers, especially since a fourth lightweight container project called
Avalon recently shut down.

As far as the activity generated in each community, Spring is far and away the winner.
The support of Interface21, fantastic forums, active mailing lists, and the track record of
the community are unrivaled.

Fit and finish

The size and strength of a community often drives fit and finish within open source
projects. Vibrant communities demand better documentation and examples, and they lend
more hands to do the finishing details.

The Spring team writes documentation that rivals some of the better commercial products
I've seen. If that's not enough, you can find at least five major Spring books and many
other publications with some Spring content. (I've written two books with some Spring
myself, including one chapter of the Jolt-winning Better, Faster, Lighter Java and the
quick start book called Spring: A Developer's Notebook.) The error messages are
professional and descriptive. The integration with third-party frameworks and APIs is
among the best of any Java technology framework. The packaging is thoughtful, if a bit
on the excessive side. (It makes sense to me to begin breaking out some of the more
minor projects as modules.) The examples are good and instructive.

Like Tapestry, HiveMind also has good fit and finish. Ship prides himself on the features
that make HiveMind easy to use, like line-precise error reporting; a friendly, concise
XML syntax; and an excellent documentation tool called HiveDoc. In combination with

Classification: GE Internal
JavaDoc documentation for low-level details, you have the excellent capability to
describe the high-level features of your application (HiveMind modules), complete with
the dependencies between them.

The PicoContainer programming model feels natural, but the documentation is

incomplete in places (with many to-do markers that look many months old), and there
aren't many real-world examples of what you can do with the container. At times, I felt
like I was walking alone through an abandoned haunted house.

You do get one major advantage with PicoContainer, though. Because you're configuring
real-world objects, you get some compile time error checking. In reality, the container is
so small and light that there's not much that can go wrong, other than basic configuration.
PicoContainer does a reasonable job.

Features

I don't need to talk about features much. Spring wins hands down if you're looking for a
lot of glue code to ease the integration of your open source favorites or that certain J2EE
API. HiveMind doesn't try to compete. Instead, it's compatible with Spring's services.
PicoContainer doesn't build the extras and doesn't try, preferring to let open source
projects provide the services for them. So far, it's not working very well.

Back to top

Which one is best?

Right now, there's only one real solution. HiveMind has interesting innovations, and
PicoContainer has an easy-to-use model (in theory), but the community seems to have
voted on Spring Framework. Over time, a new container may develop, or HiveMind
could continue to garner market share, but right now, Spring's your best bet.

If you're willing to take on some risk and use a container with less popularity or maturity,
you may decide to implement HiveMind (if you need the module-level configuration) or
PicoContainer (if you want a tiny container). If you need a lot of glue code to integrate
aspects such as persistence engines, transaction strategies, and security, Spring has the
most complete component stack. Remember, though: You can use Spring components in
the HiveMind container.

Classification: GE Internal