I have written a (physics) modeling system that manages datasets, dataflow
and visualization dynamically. Third parties can write their own
data-processing and visualization classes and have them included in the
workflows. The external classes are loaded via reflection (i.e.
ClassForName and then classe.getConstructor(types).newInstance(args).
This all works fine as long as the class is within the jars that make up the
modeling system. But if the class is in some third party jar that the
modeling system has never seen before, then of course the classloader can't
find the class.
Is there a way to update the classpaths the classloader searches WITHOUT
recompiling or otherwise change the host modeling system?
Paul Webster Messages: 6813 Registered: July 2009 Location: Ottawa
Senior Member
Are you talking about a java app? Then adding the 3rd party jars to the classpath is enough to make them visible to Class.forName(*).
Is this an RCP application?
If you are talking about turning your modeling engine into a plugin and then having other plugins contribute to it, then that's done via extension points and extensions.
Otherwise you have to use Buddy classloading (that's still 2 plugins).
If you are talking about having your modeling engine in a plugin and then loading extra classes from jars on the system ... well, that's another story entirely
Well, it is "another story entirely". The modeling engine is implemented as
a group of plugins that form a perspective. The engine needs to be able to
instantiate objects that are present in 3rd party jars that are not known to
the engine at compile time for the engine. The classes in the third party
jar implement interfaces or abstract classes that are defined in the engine.
All this works now as long as the "3rd party jar" is known to the engine
when the engine is compiled (so the classpaths are known). But that isn't a
palatable requirement down the road.
I have done a little spelunking and it looks like I can achieve what I want
either using URLLoader classloader or writing my own classloader. The
former may sandbox the class causing grief. I don't know a lot about
classloaders so I probably have some learning ahead. :-)
> Are you talking about a java app? Then adding the 3rd party jars to the
> classpath is enough to make them visible to Class.forName(*).
>
> Is this an RCP application?
>
> If you are talking about turning your modeling engine into a plugin and then
> having other plugins contribute to it, then that's done via extension points
> and extensions.
>
> Otherwise you have to use Buddy classloading (that's still 2 plugins).
>
> If you are talking about having your modeling engine in a plugin and then
> loading extra classes from jars on the system ... well, that's another story
> entirely :)
>
> PW
Since your modeling engine was developed as a plugin, can you instead
require the "3rd party jars" to be plugins instead and they would use
extension points? That would simplify your whole problem. You would use
the extension points instead of looking up classes.
But if you require to also run outside of Eclipse plugins then you will
need to do classloader gunk.
Ah, that is an interesting idea. I was thinking more in terms of generic
Java. Requiring the third party jars to be plugins is eminently doable. I
have little experience of defining extension points - only implementing
them. More learning ahead. But that sounds better than learning more about
the black art of classloaders - about which I know only a little but more
than I want.
> Since your modeling engine was developed as a plugin, can you instead
> require the "3rd party jars" to be plugins instead and they would use
> extension points? That would simplify your whole problem. You would use
> the extension points instead of looking up classes.
>
> But if you require to also run outside of Eclipse plugins then you will
> need to do classloader gunk.
Ric Wright wrote:
> Ah, that is an interesting idea. I was thinking more in terms of generic
....
> them. More learning ahead. But that sounds better than learning more about
> the black art of classloaders - about which I know only a little but more
> than I want.
>
> Thanks,
> Ric
> Hi,
>
> Here's an article on the plugin architecture including extensions.
>
> http://www.eclipse.org/articles/Article-Plug-in-architecture /plugin_architectu
> re.html
>
>
> Ric Wright wrote:
>> Ah, that is an interesting idea. I was thinking more in terms of generic
> ...
>
>> them. More learning ahead. But that sounds better than learning more about
>> the black art of classloaders - about which I know only a little but more
>> than I want.
>>
>> Thanks,
>> Ric