Writing Custom Modules
Adding special annotations to a standard Java class will expose it as a Mule extension, making it possible to use it within Mule ESB. These annotations will be processed by the DevKit’s annotations processing tool that will generate all the necessary Mule specific code. The DevKit provides a special class level annotation that tells the Annotation Processor to export the POJO functionality as a Mule Module.
The @Module annotation
The class level annotation @Module indicates that a Java class needs to be processed by the DevKit Annotation Processing Tool and considered as a Mule Module.
The @Module annotation defines the following annotation type element declarations:
| Annotation type element | Description | Required/Optional | Default value |
|---|---|---|---|
name |
defines the name of this Mule Module |
REQUIRED |
|
schemaVersion |
the version of the schema that will be generated by the DevKit |
OPTIONAL |
1.0 |
namespace |
the namespace of this Mule Module |
OPTIONAL |
http://www.mulesoft.org/schema/mule/name |
schemaLocation |
the location of the schema file that will be written to the spring.schemas file |
OPTIONAL |
http://www.mulesoft.org/schema/mule/name/schemaVersion/mule-name.xsd |
minMuleVersion |
the minimum Mule version for which this Mule Module is to be used. This will be checked in runtime during the initialise phase of the lifecycle. |
OPTIONAL |
3.2 |
poolable |
whether this module is poolable |
OPTIONAL. |
false |
Mule version verification
The minMuleVersion annotation parameter value is compared at runtime against the version of Mule where it is deployed. This check is done during the Initialisation phase and in case the version of the Mule instance is older than minMuleVersion the extension will fail to initialise and a proper error message will be logged.
The goal of this verification is to prevent possible runtime errors when the extension is executed in an older Mule version than the one the extension was originally developed for.