LDEV-6226 fix cross-classloader method resolution#2772
Open
LDEV-6226 fix cross-classloader method resolution#2772
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes intermittent
NoSuchMethodExceptionwhen calling Java methods from CFML after OSGi bundle refresh.Root Cause
Clazz.getMethod()andClazz.getConstructor()Phase 1 matching usesClass.isAssignableFrom()which does strict class identity comparison. When a Java object is persisted in a long-lived scope (e.g.variables.sfnClient) and an OSGi bundle refreshes overnight, the persisted object's class is from the old classloader while newly created arguments are from the new classloader. Same class name, different classloader =isAssignableFromreturns false = method not found.ClazzDynamiccaches byClassobject (not name), so a new classloader gets a fresh cache entry — the cache itself is not the problem. The issue is purely in the type comparison during method resolution.Fix
In
Clazz.java, bothgetMethod()andgetConstructor()Phase 1: tryisAssignableFromfirst (zero cost for the common same-classloader case), fall back toReflector.isInstaneOf(argClass, paramClass, false)which does name-based comparison with superclass/interface hierarchy walking. This method already exists and is used elsewhere in Lucee.Known Limitation
Method resolution is fixed, but the invocation path still has issues for this scenario:
CHECKCASTusing old classloader types →ClassCastExceptionMethodInstancecatches this and falls back toMethod.invoke(), which also rejects cross-classloader args →IllegalArgumentExceptionUser-level mitigation: don't persist Java objects across bundle refreshes (recreate clients periodically or on error).
Test plan
LDEV6226.cfc— compiles a Java class to two separate dirs, loads each from an isolated URLClassLoader, verifies:isAssignableFromfails across classloaders butReflector.isInstaneOfwithexactMatch=falseworksClazz.getMethod()finds methods despite cross-classloader argument types