Fixing XSLT Import Issues in MuleSoft (Works in Local but Fails in RTF Runtime)

Fixing XSLT Import Issues in MuleSoft
(Works in Local but Fails in RTF Runtime)

Introduction
XSLT (Extensible Stylesheet Language Transformations) is used to transform XML data from one format into another during application integrations.
While working on a MuleSoft integration project, I faced a challenging issue where the XSLT transformation worked perfectly in Anypoint Studio (local environment) but failed after deployment to Runtime Fabric (RTF).
After trying multiple approaches and finding very limited documentation for this issue, I was able to identify the root cause and implement a working solution. In this article, I will explain the issue, failed approaches, and the final solution that resolved it successfully.

---

🔹 Scenario
I had:
• A parent XSLT file
• One or more child XSL files
• Requirement: Import child XSL inside the parent and perform transformation

🔹 Local Setup vs Runtime Issue
• Both the parent and child XSL files were stored under:
src/main/resources/xslt/

In the General section, I used:
• Content → Passed the payload to be transformed
• XSLT → Referenced the parent XSL file using:
${file::xslt/parent.xsl}

• Inside the parent XSL, I imported the child XSL using:

📸 (Refer to the screenshot above for the exact configuration)

👉 With this setup, the transformation worked perfectly in the local environment (Anypoint Studio).

🔴 Issue in Runtime Fabric (RTF)

However, when the same application was deployed to the RTF (Runtime Fabric) environment, the transformation failed with the following error:

[2026-04-21 17:50:36.966] ERROR DefaultExceptionListener [[MuleRuntime].uber.03: [test].test.CPU_INTENSIVE @65f712f4] [event: ]:

---

Message : I/O error reported by XML parser processing file:/apps/test/xslt/xsl/child.xsl: /apps/test/xslt/xsl/child.xsl (No such file or directory)

💡 Why This Happens

In Anypoint Studio (local):
• Mule can resolve ${file::} paths directly from the filesystem

In RTF (runtime):
• Resources are packaged inside the application JAR
• Mule uses classpath-based resolution, not filesystem paths

👉 That’s why the child XSL cannot be found in runtime

🔴 Failed Approaches
I tried multiple approaches, but none worked:

1. Using classpath inside parent XSL
   
   ❌ Error:

   ---

   Message : I/O error reported by XML parser processing classpath:/xslt.xsl/child.xsl: unknown protocol: classpath

2. Using relative path
   
   ❌ Error:

   ---

   Message : I/O error reported by XML parser processing file:/tmp/child.xsl: /tmp/child.xsl (No such file or directory)

3. Using absolute path
   
   *Both child and parent xsl are in same xslt folder unser src/main/resoucrces.
   ❌ Error:

   ---

   Message : I/O error reported by XML parser processing file:/xslt/child.xsl: /xslt/child.xsl (No such file or directory)

✅ Final Working Solution
The solution was a combination of correct XSLT reference + classpath usage + dependency alignment.
✔ Step 1: Change how parent XSL is referenced
Instead of using ${file::...}, declare XSL directly in the XSLT component:
xml-module:xslt
<![CDATA[]]>
/xml-module:xslt

✔ Step 2: Use classpath inside parent XSL

👉 This ensures Mule runtime correctly resolves resources from the classpath.

✔ Step 3: Ensure correct folder structure
src/main/resources/xslt/
└── child.xsl

✔ Step 4: Match Mule XML Module dependency with runtime

org.mule.modules
mule-xml-module
1.4.3
mule-plugin

👉 Important: Dependency version must align with your Mule runtime.
• Runtime used: 4.10.2
• Module version: 1.4.3

💡 Bonus Insight
This solution also works when:
• You have multiple child XSL files
• Complex transformations with nested imports
I tested this with multiple child XSLs, and it worked consistently in both:
• Local (Studio)
• RTF Runtime

🔹 Conclusion
This issue is not well documented, and it can be frustrating when something works locally but fails in runtime.
• By correctly using classpath-based imports and aligning dependencies, you can ensure consistent XSLT execution across environments.
• I hope this helps anyone facing similar issues and saves valuable debugging time.

✍️ Author
Sphurthi Edara
MuleSoft Developer
Connect with me on LinkedIn:
https://www.linkedin.com/in/sphurthi-edara/