My Transfer Decorator Bean Injector Observer Is Now Available

I'm finally releasing my Bean Injector Observer, which will allow you to automatically inject ColdSpring-managed beans into your Transfer Decorator objects. I've found that this makes it much easier to create decorators that act as rich business objects.

I had been holding off on releasing this because it will probably be included in the near future in either the ColdSpring or Transfer bleeding edge releases. However, a lot of people have contacted me privately or on the Transfer list about wanting to use this, so I'm going to make it available on my site until we see it appear in one of the framework downloads.

The content of the release notes follows, which should explain what it is and how it works. I hope people find this useful! Thanks to Sean Corfield and Mark Mandel for their input and review of the code to help me make sure it works as well as possible.

File Name:

TDOBeanInjectorObserver.cfc (Transfer Decorator Object Bean Injector Observer)

Description:

This is a Transfer Observer that will autowire your Transfer Decorators with matching beans from ColdSpring when the Decorator is created. This makes it much easier to create "rich" Decorators that can handle much more business logic than standard Transfer Objects. The dependencies are cached by this Observer for performance. After the first instance of a Decorator is created, all subsequent Decorators of that type will have their dependencies injected using cached information. The component is thread-safe.

Usage:

Usage of the Observer is fairly straightforward. The ColdSpring XML file might look like this:

Your ColdSpring configuration must be set to inject the Transfer object into the Observer as a constructor argument.

The Observer will register itself with Transfer using the transfer.addAfterNewObserver() method. To ensure that this happens at application startup, you have two options:

1. Use the latest version of ColdSpring that supports lazy-init. What this means is that ColdSpring will automatically construct all beans that have lazy-init="false" defined in the ColdSpring XML (as the TDOBeanInjectorObserver bean is in the above config snippet). You tell ColdSpring to construct all non-lazy beans when you create the BeanFactory:

Using this approach, the TDOBeanInjectorObserver will be registerd with Transfer without you have to do anything else.

2. On older versions of ColdSpring, or if you do not wish to use the lazy-init capability, the only additional step required is to create an instance of the Observer after you initialize ColdSpring, like this:

This ensures that the Observer is constructed and registers itself with Transfer.

Your Transfer Decorator would have public setter method(s) for the bean(s) you want to inject, for example:

Once the Observer is registered with Transfer, any time you create a Transfer Decorator, the Observer will automatically inject any dependent beans into it at creation time. So in the above example, as soon as the Decorator is created, it will automatically have the ValidatorFactory injected into it via the setValidatorFactory() method. The end result is that any setters in your Decorators that have matching bean IDs in ColdSpring will have those beans injected automatically. As an additional example, a bean with an ID of "productService" would be autowired into a Decorator that had a public setter method named setProductService(), and so on.

There is an optional constructor argument called "suffixList" that can be supplied. This is a comma-delimited list of propery name suffixes that will be allowed. If you specify a suffixList, the Observer will only inject beans which end in one of the suffixes in the list. For example, if you specify a suffixList of "service", setter methods for setUserService() and setLoginService() would be called, but setter methods for setValidatorFactory() or setContext() would NOT be called. This can be useful in rare situations where your Transfer Object may have database-driven properties that conflict with the names of ColdSpring beans. Most people probably won't need to worry about this, but the option is here in case the issue arises.

In case you have problems determining whether beans are being properly injected into your Decorators, there is an optional init() method argument called "debugMode". By default, this is false. If you set it to true via the ColdSpring XML config file, the component will trace successful dependency injections to the debugging output. It will also rethrow any errors that occur while trying to inject beans into your Decorators. Obviously, ensure that this is remains off in production.