Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Advanced Mule Concepts
  4. Class-loading Isolation

  5. Export Resources

Export Resources

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Mule Applications, Mule Domains and Mule Policies contain a set of resources which may be properties files, DataWeave transformation files, Java classes, etc. By default, all of these files are internal to the artifact in which they are defined, and as a result, they are inaccessible from other artifacts. For instance, if a resource defined at the domain level is not explicitly exported, then it cannot be accessed from within any of the applications that belong to that shared domain. Another example is classes from an application that are meant to be used by the Java module. If those classes are not exported, then the Java module will not be able to access them.

How to Export Java Classes

To export Java classes, you have the export the complete package that contains them by using the exportedPackages field of the mule-artifact.json file of your artifact. Individual classes cannot be exported.

Use .api. when naming public packages and .internal. when naming your non-public packages to make them easier to identify.

{
    "name": "MyApp",
    "minMuleVersion": "4.0.0",
    "classLoaderModelLoaderDescriptor": {
        "id": "mule",
        "attributes": {
            "exportedPackages": [
                "org.mule.myapp.api.customer",
                "org.mule.myapp.api.account"
            ]
        }
    }
}

Any internal dependencies in your Java classes are automatically exported with this configuration.

Considerations

  • Export the minimum number of packages required for your application to work

    This reduces the likelihood of conflicts with other artifacts, such as modules or connectors, that you might be using within your application.

  • Configure shared libraries if any component in your Mule app needs to access the exported packages

    Due to the classloading isolation mechanism implemented in Mule, connectors and modules cannot access application dependencies unless these dependencies are configured as shared libraries.

How to Export Resource Files

To export resources, use the exportedResources field of the mule-artifact.json file for your artifact.

{
    "name": "MyApp",
    "minMuleVersion": "4.0.0",
    "classLoaderModelLoaderDescriptor": {
        "id": "mule",
        "attributes": {
            "exportedResources": [
                "/org/mule/myapp/customer-to-user.dwl",
                "/org/mule/myapp/beans.xml"
            ]
        }
    }
  }
}
This same mechanism applies to every artifact, including custom extensions developed with the Mule SDK.

See Also