Configuring Java Components
Java is the default component type in Mule. Mule provides two JavaComponent implementations: DefaultJavaComponent, which you configure with the
component element, and 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 service component implementation.
EntryPointResolvers can be configured to define how Mule services 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
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
1 2 3 <component class="org.my.CustomComponent"/> .. <pooled-component class="org.my.CustomComponent"/>
Alternatively, you can specify the implementation using an object factory.
1 2 3 4 5 6 7 <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
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 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.
Object factories also allow you to set properties, which are injected when a new object instance is created.
1 2 3 4 5 6 <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 Service 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.
You can configure entry point resolvers that determine how your component is invoked when a message is received by the service. 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.
1 2 3 4 5 6 <component class="org.my.PrototypeObjectWithMyLifecycle"> <entry-point-resolver-set> <array-entry-point-resolver/> <callable-entry-point-resolver/> </entry-point-resolver-set> </component>
1 2 3 <component class="org.my.PrototypeObjectWithMyLifecycle"> <reflection-entry-point-resolver/> </component>
You can also configure entry point resolvers (single or sets) on models to apply them to all services defined in that model. You use the same configuration syntax as above but on the
<model> element instead of
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.
1 2 3 <component class="org.my.PrototypeObjectWithMyLifecycle"> <custom-lifecycle-adapter-factory class="org.my.MyLifecycleMuleAdapterFactory"/> </component>
See Developing Components for more information about lifecycles.
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.
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:
1 2 3 <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.