The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here
LOD extension fails to load in RapidMiner 6
Dear all,
We wanted to test our Linked Open Data extension if it is compatible with RapidMiner 6. The extension can be successfully installed from the marketplace, but after RapidMiner restarts the extension cannot be loaded. The log output is:
We are confused why is the class missing in RapidMiner 6, and how can we resolve this issue?
Any help or tips are appreciated,
Petar
We wanted to test our Linked Open Data extension if it is compatible with RapidMiner 6. The extension can be successfully installed from the marketplace, but after RapidMiner restarts the extension cannot be loaded. The log output is:
The output shows that the class com.rapidminer.tools.config.gui.ConfigurationPanel cannot be found, which is used in the extension for generating custom configurators ( see "How to Extend RapidMiner 5" - chapter 8.2). We checked the rapidminer.jar of RapidMiner 6, and indeed the class com.rapidminer.tools.config.gui.ConfigurationPanel is missing.
WARNING: Plugin initializer com.rapidminer.PluginInitTemplate.initPlugin of Plugin LOD caused an error: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.rapidminer.tools.plugin.Plugin.callInitMethod(Plugin.java:897)
at com.rapidminer.tools.plugin.Plugin.callPluginInitMethods(Plugin.java:868)
at com.rapidminer.tools.plugin.Plugin.initPlugins(Plugin.java:847)
at com.rapidminer.tools.plugin.Plugin.initAll(Plugin.java:988)
at com.rapidminer.RapidMiner.init(RapidMiner.java:636)
at com.rapidminer.RapidMiner.init(RapidMiner.java:584)
at com.rapidminer.gui.RapidMinerGUI.run(RapidMinerGUI.java:304)
at com.rapidminer.gui.RapidMinerGUI.launch(RapidMinerGUI.java:792)
at com.rapidminer.gui.RapidMinerGUI.main(RapidMinerGUI.java:773)
Caused by: java.lang.NoClassDefFoundError: com/rapidminer/tools/config/gui/ConfigurationPanel
at com.rapidminer.PluginInitTemplate.initPlugin(PluginInitTemplate.java:27)
... 13 more
Caused by: java.lang.ClassNotFoundException: com.rapidminer.tools.config.gui.ConfigurationPanel
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.rapidminer.tools.plugin.PluginClassLoader.loadClass(PluginClassLoader.java:90)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 14 more
We are confused why is the class missing in RapidMiner 6, and how can we resolve this issue?
Any help or tips are appreciated,
Petar
Tagged:
0
Answers
unfortunately the how to extend RapidMiner whitepaper is not yet up to date for RapidMiner Studio 6 (we will update this in the future).
We have reworked the Configurable mechanism to be more flexible, offer increased functionality (like a test button and even support for arbitrary custom actions you may want to offer during creation) and to actually work in a reliable and non-frustrating manner.
That being said, the framework did indeed change a bit, but the actual API should still work. For example the AbstractConfigurable class got some new methods which have default implementations but can be extended to make use of the new GUI.
To register your configurable, all you need to do is call this as before:
I don't know what you tried to do when accessing the ConfigurationPanel, but it should no longer be necessary.
While the whitepaper is outdated, I will try to provide you the information you may need here. A word of warning though: The marketplace currently has no mechanism to limit an extension version to a specific Studio version. So if you just update and release your extension, you will break backwards compatibility.
Let's say you want to make use of the new "Test" button: Extend AbstractConfigurable in your Configurable implementation and override the getTestAction() method in your and introduce your own test code. Below is the JavaDoc of said method: If you need custom actions, you can do so by provoding a collection of ConfigurableActions to the new getActions() method in the same class. JavaDoc: The actual ConfigurableAction interface looks like this: and that is the ActionResult interface: Regards,
Marco
Thank you for you quick response!
Thanks for the explanation for using ConfigurableAction, but actually the problem is that I want to generate completely custom ConfigurationPanel. In my custom Configurator I am overriding the function createonfigurationPanel like this: where SPARQLConfigurationPanel is: that results into a configuration panel which can be accessed under the Tools menu, or as a ParameterTypeConfigurable inside an Operator. And it looks something like this:
I hope this clarifies the problem.
Also, you said "The marketplace currently has no mechanism to limit an extension version to a specific Studio version. So if you just update and release your extension, you will break backwards compatibility. ".
What would be the best practice to provide support for both RapidMiner 5 and 6 versions? What if we just push another version of the extension that is compatible with RapidMiner 6 under a different name.
Thanks a lot,
Petar
because there is now a single Configuration Manager which should have the same style for all existing configurables, you can no longer deliver a custom GUI. Instead, the getParameterTypes() method of the Configurator implementation should return a list of ParameterTypes that should be displayed. By doing so you have the same possibilities as for the operator parameters. If the vast list of ParameterTypes does not contain what you need, you can still register your own ParameterType and PropertyValueCellEditor.
As for the marketplace, we will add a mechanism for that in the future, however I cannot give any dates for that. The current way would be to release the extension for Studio 6 under a different name.
Regards,
Marco
Thanks for the explanation!
That probably means that I cannot register dependencies for the parameters? For example, I want to hide/show some of the input fields when different option in a combo box is selected: But that is not possible because the configurator doesn't implement ParameterHandler.
Do you have any suggestions?
One option would be to create different configurables for all options that I have in the combo box, but that would be confusing for the users, and it might not be simple to maintain all those configurables in the future.
Regards,
Petar
you currently cannot register dependencies for your parameters, correct. However, that is about to change with Studio 6.0.9. From that version on dependencies will be supported in the same way as for operators.
We actually thought nobody would use Configurables yet, which is why we did change them quite drastically, sorry for the inconvenience!
Quick RapidMiner Studio 6 version timeline for Configurables:
6.0.0 = initial version for Studio 6, the one you have been using until now
6.0.3 = major overhaul of the whole framework (e.g. extend AbstractConfigurable instead of implementing the Configurable interface now), complete revamp of GUI
6.0.9 = parameter dependencies support with same functionality as operator parameters (added #getParameterHandler() to abstract Configurator class)
Regards,
Marco