Calling a method on a ReferenceConfig changes the current thread's context classloader and doesn't reset it back

[jfaryad]

The following change introduced switching the current thread's classloader when decoding the result of a call over Dubbo:
https://github.com/apache/dubbo/pull/8737/files#diff-d86267b6e1a01363575f5353debcb5c7fd6ad017afd2adb75e914bc4102d592e

However, after the deserialization is done, the classloader is not switched back to what it was before. Not only is it considered bad practice not to reset the thread context classloader (for example in a try-finally block), it seems like this is an unintended side effect of calling a method of a remote service which in our case breaks the functionality when we migrated from Dubbo 2.x to 3.x.

I have searched the issues of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 3.1.3
• Operating System version: Linux
• Java version: 11

Steps to reproduce this issue

1. Create a ReferenceConfig with one classloader (for example in a Tomcat Resource specified in server.xml, using the common or system classloader (most probably AppClassLoader))
2. Call a method on the reference from a different classloader (for example from a webapp deployed to Tomcat, which uses the ParallelWebappClassLoader)
3. The call will switch the thread context classloader from ParallelWebappClassLoader to AppClassLoader and leave it that way without resetting it.

Expected Behavior

After the call to a Dubbo reference the classloader of the current thread should be the same as before the call.

Actual Behavior

The classloader of the current thread is changed and isn't reset.

[xitep]

hello, many thanks for this fix. is there any chance to release it promptly? at least, is there any timeline for the 3.1.5 release?

[AlbumenJ]

hello, many thanks for this fix. is there any chance to release it promptly? at least, is there any timeline for the 3.1.5 release?

3.1.5 will be release next week.