BeanFactory can't find classes when used by Eclipse plugin

[Alex322]

I'm writing an Eclipse plugin that uses Spring.
spring.jar is configured as one of the runtime libraries in my plugin.
Spring fails to load my classes, because it relies on Thread.currentThread().getContextClassLoader() to find them. What it should do is to use the Eclipse classloader.
Of course it doesn't know anything about it, so my workround was this:
Before instantiating the factory I set the context classloader.
Thread.currentThread().setContextClassLoader(MyPlu gin.class.getClassLoader());
I'm not sure but I think it has some sideeffects so I was wondering if this can be fixed in Spring or maybe there is a better solution already.
The easiest fix I can think of is to fallback to the classloader used by Spring itself, something like
Class.forName(..., true, BeanFactory.class.getClassLoader())
An even better solution would be to allow any custom classloading code to be plugged in.

Thanks,
Alex

[Colin Sampaleanu]

You may want to pose this question in the Spring-IDE forum. Torsten would have run into similar issues...

Regards,

[Alex322]

Well I'm in good company :)
The problem however is not really related to the Spring-IDE plugin, it's in the core container, in the way it tries to locate classes. The container implements the default behavior, as it should.
There are cases when this is not enough and Eclipse is only one example that I happen to stumble upon.
If the framework allowed delegating class loading to the client code it would be a big help, I think.

Alex

[Colin Sampaleanu]

Well, the whole point of using the context classloader is to be able to use the right classloader for the environment. Using the classloader which loaded Spring has its own potential issues, since as Spring gets more popular, it has a pretty high probability of being used in the actual enviroment running an app, along with just in the app itself. In most environments, if it's desireable to fall back to the classloader that loaded spring itself, the context classloader hierarchy itself will reflect that fallback...

Regards,