5.8. Factory and manager components
It is often necessary to work with objects that are not Seam components, but we still prefer to be able to inject them into our components with
@In, use them in value- and method-binding expressions, and tie them into the Seam context lifecycle (@Destroy, for example). Therefore, Seam contexts can hold objects that are not Seam components, and Seam provides several features that simplify working with non-component objects bound to contexts.
The factory component pattern lets a Seam component act as the instantiator for a non-component object. A factory method will be called when a context variable is referenced but has no value bound to it. Factory methods are defined with the
@Factory annotation. The factory method binds a value to the context variable, and determines the scope of the bound value. There are two styles of factory method. The first style returns a value, which is bound to the context by Seam:
@Factory(scope=CONVERSATION)
public List<Customer> getCustomerList() {
return ... ;
}
The second style is a method of type
void, which binds the value to the context variable itself:
@DataModel List<Customer> customerList;
@Factory("customerList")
public void initCustomerList() {
customerList = ... ;
}
In either case, the factory method is called when the
customerList context variable is referenced, and its value is null. The factory method then has no further part in the lifecycle of the value. The manager component pattern is an even more powerful pattern. In this case, a Seam component bound to a context variable manages the value of the context variable while remaining invisible to clients.
A manager component is any component with an
@Unwrap method. This method returns the value that will be visible to clients, and is called every time a context variable is referenced.
@Name("customerList")
@Scope(CONVERSATION)
public class CustomerListManager {
...
@Unwrap
public List<Customer> getCustomerList() {
return ... ;
}
}
The manager component pattern is especially useful where more control is required over component lifecycle. For example, if you have a heavyweight object that needs a cleanup operation when the context ends, you could
@Unwrap the object, and perform cleanup in the @Destroy method of the manager component.
@Name("hens")
@Scope(APPLICATION)
public class HenHouse {
Set<Hen> hens;
@In(required=false) Hen hen;
@Unwrap
public List<Hen> getHens()
{
if (hens == null) {
// Setup our hens }
return hens;
}
@Observer({"chickBorn", "chickenBoughtAtMarket"})
public addHen() {
hens.add(hen);
}
@Observer("chickenSoldAtMarket")
public removeHen() {
hens.remove(hen);
}
@Observer("foxGetsIn")
public removeAllHens() {
hens.clear();
}
...
}
Here, the managed component observes many events that change the underlying object. The component manages these actions itself, and because the object is unwrapped each time it is accessed, a consistent view is provided.
