Component Lifestyle

Transient Lifestyles

The example presented here focusses on the uniquness of transient instances and the implied weak collection policy. The example includes a demo component that contains a nested gizmo component with a transient lifestyle. The demo component if configured (via an inner Context) to request n gizmo instances. The resulting test-case log demonstrates that each request is resolved to a unique instance.

Component Example

tutorial/components/transient:

Demo.java	A component that that makes multiple requests for an internal part. The number of request is controlled by a context value and the assigned part has a transient lifestyle.
Gizmo.java	A test component we will use as the solution to the demo context criteria.
DemoTestCase.java	The testcase.

Component Example

To demonstrate the impact of the lifestyle policy we can update our project defintition and declare an explicit lifestyle. In this case we assign the TRANSIENT lifestyle policy to the widget component.

component definition::

<component xmlns="dpml:metro" class="org.acme.Demo" name="demo">
  <context>
    <entry key="count" value="5"/>
  </context>
  <parts>
    <component key="gizmo" type="org.acme.Gizmo" lifestyle="transient"/>
  </parts>
</component>

Testing the component

The following debug level logging reflects the request for multiple transient instances where each request is resolved to a new gizmo instance.

test:
    [junit] Executing forked test.
    [junit] Running org.acme.test.DemoTestCase
    [junit] [19582] [INFO   ] (demo):  gizmo [1] 23886295
    [junit] [19582] [INFO   ] (demo):  gizmo [2] 17547166
    [junit] [19582] [INFO   ] (demo):  gizmo [3] 26530674
    [junit] [19582] [INFO   ] (demo):  gizmo [4] 27165481
    [junit] [19582] [INFO   ] (demo):  gizmo [5] 23860799
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.89 sec

Summary

Components assiated with a transient lifestyle are not shared. Each request will be resolved by instantiation of a new instance. In addition, transient instances are maintained via weak references and as such instances will be automatically finalized by the JVM following instance reference release by the consuming application.