ClassEditor hardwires current thread's context ClassLoader

[mkanaley@tibco.com]

The ClassEditor (PropertyEditor) does not support using the same ClassLoader that is set into any ApplicationContext (particularly RefreshableWebApplicationContext).
It calls ClassUtils.forName(String) instead of ClassUtils.forName(String, ClassLoader).

Long story short, I can't rely on the current thread's context ClassLoader to be set correctly.

Ideally this editor would be ApplicationContextAware and cast to AbstractApplicationContext and then call getClassLoader() to resolve the ClassLoader. In the meantime, I can create my own to do this and register it thru a CustomEditorConfigurer. When I do this, it does not seem to be getting called. Any ideas why?

Am I going to run into other areas of Spring that require current context ClassLoader?

[Costin Leau]

I think you should raise an issue on JIRA. If there is a classloader set on the appContext, the will be load with that particular classloader, however the rest of the Spring components will use the classloader that loaded them.
An easier solution to your case would be for the PropertyEditor to have the CL injected so there is no dependency between the editor and the appContext.
Out of curiosity, what scenario do you have that requires such CL 'magic' ?

[mkanaley@tibco.com]

Thanks Costin.

Filed with JIRA
http://opensource2.atlassian.com/pro...rowse/SPR-1461

For my information, how exactly does one inject a ClassLoader? There is no PropertyEditor for it. Is there some well-known singleton that is always set to the ClassLoader and should method injection be used for that?

[Costin Leau]

You misunderstood me. I was talking about the ClassPropertyEditor - inside of the editor to have a reference to the appContext, the appContext while registering the default editors (including ClassEditor) can inject the classloader inside it.
It was just an implementation detail - the final solution will be anyway provided by the resolver of the JIRA issue .