NotWritablePropertyException when attempting to declaratively configure ClassLoader properties

[szwlhd]

Till now my application is running fine with 5.2.19.RELEASE version but as soon as I update spring framework to 5.2.20.RELEASE I get error NotWritablePropertyException : Bean property 'classLoader' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?

Could you please look into this.

[jhoeller]

We have a very defensive check against ClassLoader access in place now, for declarative references to ClassLoader properties specifically. In common application setup, there should never be a need to set a ClassLoader property declaratively. Could you provide some insight into what it is being configured there and where the value to the ClassLoader property is coming from?

Generally speaking, any such ClassLoader configuration should be left up to the container (BeanClassLoaderAware.setBeanClassLoader is handled automatically for any beans running in an ApplicationContext) or only to be found in programmatic setup code (programmatic setClassLoader(...) calls rather than declarative "classLoader" property references). If you got an XML bean definition declaratively specifying a "classLoader" property value, try relying on BeanClassLoaderAware instead (which many Spring-provided components support out of the box) or replace your custom ClassLoader setup with a programmatic setClassLoader call (equivalent to the original declarative declaration).

Last but not least, we are aware that this is technically a regression for isolated declarative configuration cases, as a side effect of a defensive security measure. If there are common scenarios where this regression remains unresolvable, we might specifically enable certain ClassLoader configuration scenarios again in a follow-up Spring Framework release. We aim to understand every such scenario first, considering alternatives before re-enabling declarative ClassLoader access for them.

[szwlhd]

@jhoeller but what has changed from 5.2.19 to 5.2.20 everything was working fine in 5.2.19 but breaking with 5.2.20.
yes we are using XML bean.

[jhoeller]

This was a change in response to the current CVE which uses an attack vector via accidentally exposed ClassLoaders. As a consequence, ClassLoader access via declarative bindings has been severely restricted. Sorry for the inconvenience...

We'd like to understand which specific kind of bean you are configuring that needs to accept a declarative "classLoader" property. This is not commonly done, ClassLoaders are usually configured programmatically. If you could show the bean definition affected, we could evaluate alternatives or whether this suggests re-enabling as per my final paragraph above.

[kennymacleod]

Following on from the discussion started in #28261.

The Eclipse Gemini Blueprints project uses the BeanClassLoaderAware interface. I don't pretend to understand the why's, I'm not affiliated with Gemini in any way, but our own application uses it as a core part of its OSGi layer.

https://github.com/eclipse/gemini.blueprint/blob/master/core/src/main/java/org/eclipse/gemini/blueprint/service/importer/support/AbstractOsgiServiceImportFactoryBean.java

It appears that Gemini has had no updates since 2018, so the odds of them redesigning their stuff seems remote, but this leaves us in the unpleasant position of being unable to upgrade to 5.3.18

[szwlhd]

This is snippet of my code the way I using. bean is configured through XML

public class HazelcastClassLoaderSetter implements BeanPostProcessor
{
  private ClassLoader classLoader;

  public void setClassLoader(ClassLoader classLoader)
  {
    this.classLoader = classLoader;
  }

  @Override
  public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException
  {
    if (bean instanceof Config)
    {
      ((Config) bean).setClassLoader(classLoader);
    }
    return bean;
  }

}

[jhoeller]

@szwlhd alright, and where does the ClassLoader reference come from? Some XML reference to another bean?

If all you need to do there is pass the Spring-managed bean ClassLoader along to Hazelcast, the proper way to do this is to make HazelcastClassLoaderSetter implement BeanClassLoaderAware and accept the Spring application context ClassLoader via the setBeanClassLoader method in that interface. There is no need to do custom ClassLoader injection in such a scenario.

[jhoeller]

To all affected here, we recommend revisiting each such rare case of custom ClassLoader injection since there is usually a preferable official mechanism to use instead. That said, we intend to relax this new ClassLoader defensiveness check to re-enable ClassLoader configuration properties in general, as far as possible without sacrificing the original defensiveness against accidental ClassLoader exposure. For that reason, I'm scheduling this ticket for 5.3.19, along with a backport to 5.2.21.