Find this tutorial in:
Try the Tutorial
The Dependency Injection pattern simplifies application code, and increases configuration flexibility by deferring component configuration and assembly to the container. Resin calls setters on the configured objects to assemble the resource dependencies.
Dependency injection is a term used to describe a separation between the implementation of an object and the construction of an object it depends on, and the ability for a container like Resin to resolve the dependency.
Since the container instantiates and assembles the dependencies, the code is simpler and the configuration is more flexible. It's easy to substitute test implementations as the dependent resources, for example.
The MovieFinder example for this tutorial comes from Martin Fowler's Dependency Injection article.
More details on Resin's configuration is available at the bean-style configuration page.
The Dependency Injector pattern could also be called the Assembly pattern because it resembles an assembly line making cars.
Some important points:
Because the Assembler is independent of the code, a project could change the Assembler from Spring to Resin with no code changes. So using the Assembler/Dependency Injection pattern reduces dependencies on the framework. Only the configuration changes when changing Assemblers, not the code.
While testing, the test case or the harness plays the Assembler role, simplifying the test suite and ensuring that the code under test is the production code. A test can create a test implementation of the Part, e.g. TestMovieFinder, for testing.
In some cases, the application code can provide its own assemble() method for situations where the container is incapabile of assembling the components. For example, the MovieServlet could create an assemble() method that grabbed the MovieLocator from JNDI.
The only code specific to the setter-based injection pattern is the addition of a setter method for the dependent resource. In many application, that setter will already be written, so no additional code would be required.
Either an interface or a class can be used for the dependent resource, depending on the application's architecture. This example uses both: the MovieListener uses a dependent MovieFinder interface, and the MovieServlet uses the dependent MovieListener class.
Resin can use JMX as the registry instead of JNDI. In this example, only the configuration needs to be changed. JMX uses the mbean-name instead of the jndi-name, and the jndi:lookup uses the "mbean:" schema.
Using JMX as the registry has some restrictions over JNDI. JMX requires an interface class. So the servlet's <movie-lister> setting can't be stored in JMX. JMX also can't support object references. All JMX getters and method values are value objects, never references. This limits the kinds of structures you can use easily with JMX.
The Dependency Injection pattern is just as useful for servlet configuration as it is for resources. This example makes the MovieLister a parameter of the servlet. The web.xml will configure the servlet with the appropriate MovieLister
The advantages of using dependency injection for the servlet are the same as for the resource:
For compatibility, Servlets will generally add an assemble() method to cover cases where the container cannot assemble the Servlet. The assemble() method will call JNDI with appropriate names from the <init-param> values to assemble the dependencies.