 The Java component enables the developer to package custom Java code
that executes when the component receives a message
 Mule provides two JavaComponent implementations:
 DefaultJavaComponent, which configured with the `component `element
<component class="org.my.CustomComponent"/>
 PooledJavaComponent, which adds pooling functionality when configured
with the pooled-component element.
<pooled-component class="org.my.CustomComponent"/>
 To configure the Java component, selecting a class is the only required
entry.
 The class name can be specified either through the “Class Name”
attribute or the “Object” attribute.
 Using the “Class Name” attribute is equivalent to using the prototype
object factory
J a v a C o m p o n e n t s i n M u l e .
 Object factories manage both object creation in case of Mule instantiated
instance or object look up from another container such as Spring.
 The following object factories are included with Mule and can be configured
using Mule’s core schema.
Type 1:<prototype-object class=…"/> :Creates a new instance of the object on
each call.
Example: <component class="org.my.CustomComponent"/>
or
<component ><prototype-object class="org.my.CustomComponent">
</component>
Type2:<singleton-object class=…"/> :Creates an instance of the object once and
then always returns the same instance .
Example:<component>
<singleton-object class="org.my.CustomComponent"/>
</component>
Type 3: <spring-object bean=…"/> :This is an implementation of the ObjectFactory
interface which simply delegates to the Spring ApplicationContext. Since the
delegation happens each time a call to getOrCreate() is made, this will correctly
handle Spring beans which are non-singletons (factory beans, etc.)
Example:
<component>
<spring-object bean="myCustomComponentBean"/>
</component>
Interceptors:
 Interceptors let us provide additional services to the component
Example: the ability to log transactions and the ability to log the time for each
transaction.
 An interceptor contains the business logic that is applied to the message payload
before being sent to the next building block.
 The following types of interceptors can be added to the Java component:
a)Custom Interceptor
b)Logging Interceptor
c)Timer Interceptor
Entry Point Resolvers:
 The entry point is the method in our component that is invoked by Mule
when a message is received.
 Entry point resolver determine how our component is invoked when a
message is received by the flow
 helps us to determine which method of a Java component will be called.
 Each entry point resolver is tried in turn until one succeeds in delivering the
message to the component.
Reflection Entry point resolver:
 Determines the message to be invoked based on number and type of
arguments.
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<reflection-entry-point-resolver/>
</component>
Entry Point Resolvers:
Property Entry point resolver:
 Uses a mule message property to select the component method to be called.
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<property-entry-point-resolver property="propertyName"/>
</component>
The property-entry-point-resolver lets you choose a method to invoke at run-
time by adding this property name to the MuleMessage.
Method entry point resolver:
 Delivers the message to a named method.
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<method-entry-point-resolver>
<include-entry-point method="methodString" />
</method-entry-point-resolver>
</component>
Entry Point Resolvers:
Custom Entry point resolver:
 Allows user-supplied code to determine how a message is passed to a
component in Java. .
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<custom-entry-point-resolver
class="org.mule.test.integration.resolvers.CustomEntryPointResolver"
/>
</component>
Callable Entry point resolver:
 An entry point resolver for the components that implement the Callable
interface.
 This passes a MuleEventContext to the component.
 This entry point resolver is implicitly configured only if the component
implements the Callable interface.
<component class="org.my.PrototypeObjectWithMyLifecycle">
<callable-entry-point-resolver/>
</component>
Entry Point Resolvers:
Array Entry point resolver:
 Delivers the message to a method that takes a single array as
argument.
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<array-entry-point-resolver/>
</component>
No Arguments Entry point resolver:
 Calls a method without any arguments.
<component class=”org.my.PrototypeObjectWithMyLifecycle”>
<no-arguments-entry-point-resolver/>
</component>
Include Entry point:
 Includes a particular method to be invoked.
Can be used in combination with any other entry point resolver when
there is ambiguity
Component Life-Cycle Interfaces
A custom LifecycleAdaptor can be configured to customize
the way in which the component implementation is initialized
and disposed

Java Components and their applicability in Mule Anypoint Studio

  • 2.
     The Javacomponent enables the developer to package custom Java code that executes when the component receives a message  Mule provides two JavaComponent implementations:  DefaultJavaComponent, which configured with the `component `element <component class="org.my.CustomComponent"/>  PooledJavaComponent, which adds pooling functionality when configured with the pooled-component element. <pooled-component class="org.my.CustomComponent"/>  To configure the Java component, selecting a class is the only required entry.  The class name can be specified either through the “Class Name” attribute or the “Object” attribute.  Using the “Class Name” attribute is equivalent to using the prototype object factory J a v a C o m p o n e n t s i n M u l e .
  • 3.
     Object factoriesmanage both object creation in case of Mule instantiated instance or object look up from another container such as Spring.  The following object factories are included with Mule and can be configured using Mule’s core schema. Type 1:<prototype-object class=…"/> :Creates a new instance of the object on each call. Example: <component class="org.my.CustomComponent"/> or <component ><prototype-object class="org.my.CustomComponent"> </component> Type2:<singleton-object class=…"/> :Creates an instance of the object once and then always returns the same instance . Example:<component> <singleton-object class="org.my.CustomComponent"/> </component>
  • 4.
    Type 3: <spring-objectbean=…"/> :This is an implementation of the ObjectFactory interface which simply delegates to the Spring ApplicationContext. Since the delegation happens each time a call to getOrCreate() is made, this will correctly handle Spring beans which are non-singletons (factory beans, etc.) Example: <component> <spring-object bean="myCustomComponentBean"/> </component> Interceptors:  Interceptors let us provide additional services to the component Example: the ability to log transactions and the ability to log the time for each transaction.  An interceptor contains the business logic that is applied to the message payload before being sent to the next building block.  The following types of interceptors can be added to the Java component: a)Custom Interceptor b)Logging Interceptor c)Timer Interceptor
  • 5.
    Entry Point Resolvers: The entry point is the method in our component that is invoked by Mule when a message is received.  Entry point resolver determine how our component is invoked when a message is received by the flow  helps us to determine which method of a Java component will be called.  Each entry point resolver is tried in turn until one succeeds in delivering the message to the component. Reflection Entry point resolver:  Determines the message to be invoked based on number and type of arguments. <component class=”org.my.PrototypeObjectWithMyLifecycle”> <reflection-entry-point-resolver/> </component>
  • 6.
    Entry Point Resolvers: PropertyEntry point resolver:  Uses a mule message property to select the component method to be called. <component class=”org.my.PrototypeObjectWithMyLifecycle”> <property-entry-point-resolver property="propertyName"/> </component> The property-entry-point-resolver lets you choose a method to invoke at run- time by adding this property name to the MuleMessage. Method entry point resolver:  Delivers the message to a named method. <component class=”org.my.PrototypeObjectWithMyLifecycle”> <method-entry-point-resolver> <include-entry-point method="methodString" /> </method-entry-point-resolver> </component>
  • 7.
    Entry Point Resolvers: CustomEntry point resolver:  Allows user-supplied code to determine how a message is passed to a component in Java. . <component class=”org.my.PrototypeObjectWithMyLifecycle”> <custom-entry-point-resolver class="org.mule.test.integration.resolvers.CustomEntryPointResolver" /> </component> Callable Entry point resolver:  An entry point resolver for the components that implement the Callable interface.  This passes a MuleEventContext to the component.  This entry point resolver is implicitly configured only if the component implements the Callable interface. <component class="org.my.PrototypeObjectWithMyLifecycle"> <callable-entry-point-resolver/> </component>
  • 8.
    Entry Point Resolvers: ArrayEntry point resolver:  Delivers the message to a method that takes a single array as argument. <component class=”org.my.PrototypeObjectWithMyLifecycle”> <array-entry-point-resolver/> </component> No Arguments Entry point resolver:  Calls a method without any arguments. <component class=”org.my.PrototypeObjectWithMyLifecycle”> <no-arguments-entry-point-resolver/> </component> Include Entry point:  Includes a particular method to be invoked. Can be used in combination with any other entry point resolver when there is ambiguity
  • 9.
    Component Life-Cycle Interfaces Acustom LifecycleAdaptor can be configured to customize the way in which the component implementation is initialized and disposed