Tapestry's Inversion of Control

...

{float:right}
{info:title=Related Article}
* [IoC FAQ|Tapestry Inversion of Control Container]
{info}
{float}

The inner construction of the Tapestry framework is container is a built-in Tapestry module based on inversion of control

An additional benefit of using IoC is that, by breaking a complex system into small pieces, it becomes easier to modify and extend the system, by overriding or replacing selected parts of the system.

...

Tapestry 4 introduced the use of the Apache HiveMind

Tapestry 5 extends on this, replacing HiveMind with a new container specifically build for Tapestry 5, designed for greater ease of use, expressiveness and performance. HiveMind itself has been subsequently shelved; T5 IoC can be considered a streamlined and improved HiveMind. And T5 IoC can be used separately from the rest of Tapestry!

Why Not Spring?

Spring

• Spring beans can be wired together by name (or id), but it is not possible to introduce additional naming abstractions. Tapestry 4's "infrastructure:" abstraction was the key to allowing easy spot overrides of internal Tapestry services without having to duplicate the large web of interrelated services (nearly 200 in Tapestry 4.0).
• Although Spring allows beans to be intercepted, it does so in the form of a new bean, leaving the un-intercepted bean visible (and subject to misuse). Tapestry IoC "wraps" the service inside interceptors, preventing un-intercepted access to the core service implementation.
• Spring's XML configuration files are quite verbose. This has improved with Spring 2.0, but still far more verbose that T5 IoC module classes.
• Spring has a simple map/list/value configuration scheme, but it is not distributed; it is part of a single bean definition. Tapestry 5 IoC allows a service configuration to be assembled from multiple modules. This is very important for seamless extensibility of the framework, with zero configuration (just drop the module into the classpath and everything hooks together).

Why Not HiveMind?

The difficulty of managing the release schedules of two complex frameworks has proven proved to be an issue. HiveMind's 2.0 release will incorporate ideas similar to those present in Tapestry 5 IoC, but will also maintain legacy support for the existing XML-driven approach.

The use of HiveMind is was also related to one of the common criticisms of Tapestry 4: startup time. The time it takes took to parse and organize all that XML shows showed up as several seconds of startup time. Creating a streamlined IoC container that is not driven by XML has alleviated those issues.

With the advent of new technologies (in particular, JDK 1.5 Annotations

Tapestry IoC also represents many simplifications of HiveMind, representing building on lessons learned while creating from both HiveMind and Tapestry 4. The HiveMind project itself has wound down (it is not no longer in active under development), with and most of the user base moving has moved to Tapestry 5.

Why not Guice?

Google Guice

Guice is still missing some core ideas needed in T5 IoC. There's no concept of configurations or anything similar. And there are limitations on injection based on scope (a request scoped value can't be injected into a global scope service; in T5 IoC, scope is internal to the proxy and never an issue).

Goals

As with Tapestry 5 in general, the goal of Tapestry IoC is greater simplicity, greater power, and an avoidance of XML.

...

The core concept of Tapestry IoC is that the Java language itself is the easiest and most succinct way to describe object creation and method invocation. Any approximation in XML is ultimately more verbose and unwieldy. As the Tapestry IOC examples show, a small amount of Java code and a handful of naming conventions and annotations is far simpler and easier than a big chunk of XML.

...

Another goal is "developer friendliness". This is a true cross-cutting concern, and one not likely to be packaged into an aspect any time soon. The Tapestry IoC framework is designed to be easy to use and easy to understand. Further, when things go wrong, it actively attempts to help you via comprehensive checks and carefully composed error messages. Further, all user-visible objects implement a reasonable toString() method

...

When building a registry of services, lightness refers to the proper division of responsibility, the separation of concerns, and the limiting of dependencies between different parts of the system. This style is often called Law of Demeter

...

• Small interfaces of two or three methods.
• Small methods, with two or three parameters (because dependencies are injected in behind the scenes, rather than passed into the method).
• Anonymous communication via events, rather than explicit method invocations. The service implementation can implement an event listener interface.

See The Pragmatic Programmer

Overview

The Tapestry IoC container takes over all the plumbing necessary for a highly scalable, extensible, thread-safe, testable application. Please see the main Tapestry IoC overview for more details.

Terminology

The basic unit in Tapestry IoC is a service. A service consists of a service interface and a service implementation. The service interface is an ordinary Java interface. The service implementation is a Java object that implements the service interface. Often there will only be a single service per service interface, but in some situations, there may be many different services and service implementations all sharing the same service interface.

Services are identified by a unique id. Typically, a service id matches the unqualified name of the service interface, but this is simply a convention.

...

The point of Injection is a field, method parameter, or constructor parameter that receives an injected value. The type of service (or other dependency) is determined by the type of the field or parameter. Often, annotations further identify what is to be injected, or in the case of field injection, that an injection is required.

IoC Subtopics