OSGi fix: Set thread context classloader so deserializer in shiro-lang can find classes in shiro-core to fix #2083

[steinarb]

Fixes #2083

The fix is that code in shiro-core (which has a classloader that "sees" all of the classes in shiro-core and shiro-lang) sets its classloader as the thread context classloader, so that the deserializer in shiro-lang (which on its own in OSGi has a classloader that does not see the classes in shiro-core) , can use the thread context classloader to find the deserialized classes.

The fix is one line, as well as one line of comment explaining why the line is there (I have filled in the contributing thing earlier, even though probably not needed for this).

[lprimak]

I would need to test this in my code, as I am doubtful this fix is sideffect-free

[steinarb]

(FWIW code that expect a flat classloader should have no side effect, since the thread context class loader would be the same as the regular class loader. And in OSGi the class loader set on the thread context will see everything the shiro-core classloader sees, which includes shiro-lang. Other than OSGi and flat/plain/normal classloaders I have no idea, because those two are the only ones I know)

And the reason setting the thread context classloader works is this code https://github.com/apache/shiro/blob/main/lang/src/main/java/org/apache/shiro/lang/util/ClassUtils.java#L153

(so that setting the thread context classloader has nothing actually to do with OSGi except that the default classloader when running in OSGi is the OSGi class loader of the shiro-lang bundle, which can only see packages in the runtime, in the bundle itself and packages found in import-packages in the MANIFEST.MF)

[lprimak]

Unfortunately this is too risky. Can you please check #2085 instead with your apps? Hopefully this will fix the problem in a safer way.
Thank you