Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.3)
  3. Essentials of Using Mule ESB 3
  4. Configuring Components

  5. Configuring Java Components

Configuring Java Components

Java is the default component type in Mule. Mule provides two JavaComponent implementations:

  • DefaultJavaComponent, which you configure with the `component `element

  • PooledJavaComponent, which adds pooling functionality and which you configure with the pooled-component element.

These two implementations provide the following functionality and configuration options:

  • An ObjectFactory is used to obtain the Java component implementation.

  • EntryPointResolvers can be configured to define how Mule flows should invoke the component methods when processing a message.

  • A custom LifecycleAdaptor can be configured to customize the way in which the component implementation is initialized and disposed.

  • Bindings can be configured to bind component interface methods to endpoints. These endpoints are then invoked synchronously when the method is called.

When you specify the class directly on the component or pooled-component element, the PrototypeObjectFactory is used by default, and a new instance is created for each invocation, or a new pooled component is created in the case of the PooledJavaComponent.

Example:

<component class="org.my.CustomComponent"/>
..
<pooled-component class="org.my.CustomComponent"/>

Alternatively, you can specify the implementation using an object factory.

Example:

<component>
    <singleton-object class="org.my.CustomComponent"/>
</component>
...
<component>
    <spring-object bean="myCustomComponentBean"/>
</component>

All other component configuration elements are configured as children of the component or pooled-component element.

Note: In Mule 2.0, Java component pooling is used only if the <pooled-component> element is used. In previous versions of Mule, pooling was the default.

Object Factories

Object factories manage both object creation in the case of a Mule instantiated instance or object look-up from another container such as Spring via a single API. The following object factories are included with Mule and can be configured using Mule’s core schema.

<prototype-object class=…​"/>

PrototypeObjectFactory

<singleton-object class=…​"/>

SingletonObjectFactory

<spring-object bean=…​"/>

SpringBeanLookup

Object factories also allow you to set properties, which are injected when a new object instance is created.

Example:

<component>
    <singleton-object class="org.my.SingletonObject">
        <property key="myKey" value="theValue"/>
        <property key="myKey2" value="theValue2"/>
    </singleton-object>
</component>

For a real-world example of using <spring-object/>, see Using Spring Beans as Flow Components.

You can easily implement additional object factories to integrate with other containers or simply to create object instances in a different way.

Note: Object factories replace ContainerContexts in previous versions of Mule.

Entry Point Resolvers

You can configure entry point resolvers that determine how your component is invoked when a message is received by the flow. See Developing Components for a more detailed description of their functionality.

To configure entry point resolvers, you can either configure an entry point resolver set or configure a single entry point resolver independently. When using an entry point resolver set, the order in which the resolvers are configured is the order of of precedence they are given in run-time.

Example:

<component class="org.my.PrototypeObjectWithMyLifecycle">
    <entry-point-resolver-set>
        <array-entry-point-resolver/>
        <callable-entry-point-resolver/>
    </entry-point-resolver-set>
</component>
<component class="org.my.PrototypeObjectWithMyLifecycle">
    <reflection-entry-point-resolver/>
</component>

Lifecycle Adapter Factory

You can configure your Java component to use a custom lifecycle adaptor. If you do not configure a custom implementation, the default implementation will be used, which allows the optional propagation of Mule’s lifecycle to your component depending on the Mule lifecycle interfaces that are implemented.

Example:

<component class="org.my.PrototypeObjectWithMyLifecycle">
    <custom-lifecycle-adapter-factory class="org.my.MyLifecycleMuleAdapterFactory"/>
</component>

See Developing Components for more information about lifecycles.

Bindings

Components can use bindings to call an external service during execution. The bindings used with a Java component bind a Java interface, or single interface method, to an outbound endpoint. The external service to be called should implement the same interface, and the component should encapsulate a reference to that interface, which is initialized during the bootstrap stage by the Mule configuration builder. The reference will be initialized using a reflective proxy class.

Binding can be used on Java components and script components. For more information see Component Bindings.

Configuring a Pooled Java Component

A pooled Java component will maintain a pool of object instances that will be reused, with a single instance being used by one thread at any one time. The configuration of component pooling is independent of the object factory, allowing you to use whichever object factory you need.

You configure the pool using the nested pooling-profile element as shown below:

<pooled-component class="org.my.PrototypeObject">
    <pooling-profile exhaustedAction="WHEN_EXHAUSTED_FAIL" initialisationPolicy="INITIALISE_ALL" maxActive="1" maxIdle="2" maxWait="3" />
</pooled-component>

For more information about pooling and reference documentation for pooling configuration options, see Tuning Performance.