Fix inconsistent ClassLoader usage between class presence check and actual class loading
Fix inconsistent ClassLoader usage between class presence check and actual class loading
Background
LettuceClassUtils#getDefaultClassLoader() currently returns the Thread Context ClassLoader (TCCL) when available. However, LettuceClassUtils#isPresent(...) relies on this method to check class existence, while the actual class loading is later performed using the ClassLoader of LettuceClassUtils itself. This leads to an inconsistent ClassLoader strategy:
- Presence check: uses Thread Context ClassLoader
- Actual loading: uses LettuceClassUtils.class.getClassLoader() In environments with multiple ClassLoaders (e.g. OSGi, Servlet containers, shaded applications, plugin systems), this can cause:
- isPresent(...) returning true
- Followed by a ClassNotFoundException during actual class loading This is a classic false-positive detection issue caused by mismatched ClassLoaders.
Root Cause
The root problem is that:
- getDefaultClassLoader() returns TCCL
- But Class.forName(...) and direct loading later use a different ClassLoader So the class existence check is not aligned with the loader that actually loads the class.
Solution
This PR makes the ClassLoader strategy consistent by:
- Ensuring that both class presence checks and real class loading use the same ClassLoader
- Preferring LettuceClassUtils.class.getClassLoader() as the primary loader
Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.
In case there are security findings, they will be communicated to you as a comment inside the PR.
Hope you’ll enjoy using Jit.
Questions? Comments? Want to learn more? Get in touch with us.
Hello @linw-bai You need to make PR against the main branch first and then the fix will be backported to earlier versions if needed. I am closing this PR for now. Feel free to open it against main and we will review it.