Options
plugin class loaders
Contributor II
Hi,
do plugins in RM5 have own class loaders or do they use a shared one (e.g. the default one)? I'm asking, because in the former case, plugins could have differently versioned dependencies (ie. conflicting dependency trees).
Is there already a draft describing the plugin-development for RM5? Maybe I should simply build the tutorial from the svn-sources or is it not yet updated?
Best, Holger
do plugins in RM5 have own class loaders or do they use a shared one (e.g. the default one)? I'm asking, because in the former case, plugins could have differently versioned dependencies (ie. conflicting dependency trees).
Is there already a draft describing the plugin-development for RM5? Maybe I should simply build the tutorial from the svn-sources or is it not yet updated?
Best, Holger
Tagged:
0
Answers
extensions have their own class loader, adding the class loaders of the dependent extensions to it's search list. This very well makes the dependencies a tree, but this hasn't been tackled yet, it simply was too complicated for such unprobable cases where this is needed. Might be we come up with this later, as soon as it is needed somewhere.
I started writing a white paper regarding the extension development, this is especially important, because a great number of new configuration files is present, giving more options, but making life a little bit more complex. And last but not least the buildfile mechanism has been completely revised, which should be mentioned, too. Unfortunately I'm attending the PMML standardization group meeting next week in the US, so that I cannot go on with that work. I don't know if any of my colleges will find the time.
Greetings,
Sebastian
IMHO version conflicts in dependencies are an often occuring problem in large apps. That's why things like OSGi have emerged. OSGi for extension management would probably solve many problems here and could save a lot of dev-efforts. We(the plugin developers) would have better IDE support (testing, autocompletion, service descriptors), and anyone familiar with osgi could write extensions without reading much documentation. E.g. by comparing knime plugin development with the rm-approach, this becomes quite clear imho. Are there any plans to go into such a direction?
here's a nice description of the differences between different class loading approaches:
http://shylendrabhat.com/blog/2009/11/21/class-loader-architecture-comparison-java-j2ee-and-osgi/
Anyway, if something works I'm the last to complain about it. :-) Would it be possible for you to make the draft of the white paper available (however incomplete it may be)? So far it's rather a reverse engineering problem for me to write a rm5-plugin than actual coding.
Best, Holger