|
|
|
|
Default Setting
By default, components defined in the global scope are singleton, unless explicitly specified otherwise. This default global setting can be changed by changing the "singleton" attribute on the <module> tag.
Components defined within a local scope (inside <local>, <sequence>, <binder> or any other tags) are not singleton by default. This default behavior can only be changed on each individual component definition using the "singleton" attribute. For example:
... <local> <ctor id="acct" class="BankAccount" singleton="true"/> </local> ...
Mix singleton and non-singleton
Sometimes, we may want to have a bean such that, the instance itself is singleton in the sense that the same instance is returned every time it is instantiated; one or more properties are not singleton, in the sense that different property values are set every time this component is instantiated.
Writing it in Java, it will look like:
private BankAccount singleton; private BankAccount getSingletonInstance(){ if(singleton==null){ this.singleton = new BankAccount(); } return singleton; } public synchronized BankAccoun getInstance(){ final BankAccount instance = getSingletonInstance(); instance.setJoint(new BankAccount()); }
Every time getInstance() is invoked, the same instance is returned, but a different BankAccount object is created for the "joint" property.
The Spring framework has a solution for it, but pretty heavy and requires bytecode generation. This is the Spring note for this issue:
 |
There is however a problem when the bean lifecycles are different. Consider a singleton bean A which needs to use a non-singleton (prototype) bean B, perhaps on each method invocation on A. The container will only create the singleton bean A once, and thus only get the opportunity to set its properties once. There is no opportunity for the container to provide bean A with a new instance of bean B every time one is needed. One solution to this problem is to forgo some inversion of control. Bean A can be aware of the container (as described here) by implementing BeanFactoryAware, and use programmatic means (as described here) to ask the container via a getBean("B") call for (a new) bean B every time it needs it. This is generally not a desirable solution since the bean code is then aware of and coupled to Spring. Method Injection, an advanced feature of the BeanFactory, allows this use case to be handled in a clean fashion, along with some other scenarios. Lookup method injection refers to the ability of the container to override abstract or concrete methods on managed beans in the container, to return the result of looking up another named bean in the container. The lookup will typically be of a non-singleton bean as per the scenario described above (although it can also be a singleton). Spring implements this through a dynamically generated subclass overriding the method, using bytecode generation via the CGLIB library. ... |
In Nuts, this is no harder than a "singleton uses singleton", "non-singleton uses non-singleton" or "non-singleton uses singleton" senario. Nuts handles quite complex component combinations. The "singleton uses non-singleton" case is among the easiest ones.
All we have to do is to create the singleton base component and the non-singleton bean component that injects the non-singleton properties to the singleton base:
<bean id="acct" singleton="false" synchronized="true"> <bean class="BankAccount" args="" singleton="true"/> <prop key="joint"> <ctor class="BankAccount"/> </prop> </bean>
The "synchronized" attribute is used to indicate that a "synchronized" block should enclose the instantiation process.
Created by benyu
On Sun Nov 27 00:36:00 CST 2005
Using TimTam
[ edit ]