Page History

...

• 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 and runtime class generation via Javassist) some of the precepts of HiveMind have been were undermined. That is to say, in HiveMind (and as in Spring), all that XML is was an awkward way to describe a few basic Java operations: instantiating classes and invoking methods on those classes (to inject dependencies into the instantiated instances). The central concept in Tapestry IoC is to eliminate XML and build an equivalent system around simple objects and methods.

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 is a relative newcomer to the IoC landscape. Guice and T5 IoC are very close and, in fact, T5 IoC expressly borrows many great and innovative ideas from Guice. Guice abandons not only XML but even any concept of a service id ... for injection, services are matched by type and perhaps filtered based on annotations.

...

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.

...