At the first start up, Saddle asks the user for the installation directory of Mule 2.x and/or Mule 3.x. The installation path has to be simply selected in the dialog that pops up.
Saddle provides a subfolder called “libraries”. This folder contains in turn three folders that contain java libraries that are handled differently:
| • | custom all libraries that are located in this folder are known to the mappings that are created in the Message Mapper Module. Libraries that are contained in this folder will also be deployed to the referenced Mule instance when the user deploys a mapping. Therefore, all custom libraries that should be referenced in a mapping have to be placed in this folder. |
 |
| • | mule libraries that are native to Saddle but not shipped with Mule. Those libraries are needed by the Saddle extension to work in the Mule environment. They are automatically dep-loyed to the referenced Mule instances. Usually, a user do not need to change anything in this folder. |
|
| • | saddle this folder contains all libraries that are native to Mule but are needed by Saddle. They are used for the mappings that are created with Saddle but are not deployed to the referenced Mule instances. |
|
The libraries of all three subfolders of the “library” folder are checked when the Saddle GUI is started. Saddle validates the libraries that are currently used by the Mule instances and also the one that are currently used by Saddle. If any library contained in these folders is newer than the ones currently used by Saddle or Mule, the currently used ones will be replaced by the ones of the library folder. Saddle checks the modification date of the files for checking if the libraries are up to date. If a library of the library subfolders has not yet been deployed, Saddle also deploys it.
Please do not remove any library that has been shipped with Saddle from any of those folders. Otherwise you might risk that Saddle itself or the Saddle extensions of the Mule system are not working correctly anymore.
 |
previous | next |  |