Due to recent updates, all users are required to create an Altair One account to login to the RapidMiner community. Click the Register button to create your account using the same email that you have previously used to login to the RapidMiner community. This will ensure that any previously created content will be synced to your Altair One account. Once you login, you will be asked to provide a username that identifies you to other Community users. Email us at Community with questions.

LOD extension fails to load in RapidMiner 6

petar_rpetar_r Member Posts: 6 Contributor II
edited July 2019 in Help
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:

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
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.

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

Answers

  • Marco_BoeckMarco_Boeck Administrator, Moderator, Employee, Member, University Professor Posts: 1,996 RM Engineering
    Hi,

    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:

    ConfigurationManager.getInstance().register(new MyConnectionConfigurator());

    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:

    /**
    * Returns a {@link TestConfigurableAction} which tests the settings for the
    * {@link Configurable}, e.g. a connection.
    * <p>
    * If no test action is required, returns <code>null</code>.
    * </p>
    * These actions can be defined per {@link Configurable} instance, so two {@link Configurable}s
    * of the same {@link Configurator} type can have different actions. </p>
    * <p>
    * Also the actions can be changed dynamically, as they are retrieved each time they are
    * required.
    * </p>
    *
    * @return
    */
    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:

    /**
    * Returns a list of {@link ConfigurableAction}s. They can be used to perform various tasks
    * associated with this configuration type, e.g. clearing a cache.
    * <p>
    * If no actions are required for this configuration type, returns <code>null</code>.
    * </p>
    * These actions can be defined per {@link Configurable} instance, so two {@link Configurable}s
    * of the same {@link Configurator} type can have different actions. </p>
    * <p>
    * Also the actions can be changed dynamically, as they are retrieved each time they are
    * required.
    * </p>
    *
    * @return
    */
    The actual ConfigurableAction interface looks like this:

    /**
    * <p>
    * Actions which can be performed for a {@link Configurable} must implement this interface. An
    * example would be to clear some kind of cache. These actions can be defined per
    * {@link Configurable} instance, so two {@link Configurable}s of the same {@link Configurator} type
    * can have different actions.
    * </p>
    *
    * @author Marco Boeck
    *
    */
    public interface ConfigurableAction {

    /**
    * Returns <code>true</code> if this action makes use of GUI components, e.g. Swing dialogs,
    * etc. If not, returns <code>false</code>.
    *
    * @return
    */
    public boolean hasUI();

    /**
    * Executed when the action is performed. The {@link ActionResult} indicates
    * success/failure/neither and an optional message which can be diplayed to the user.
    *
    * This method is called in a separate thread.
    *
    * @return
    */
    public ActionResult doWork();

    /**
    * Returns the name of the action which is displayed to the user.
    *
    * @return
    */
    public String getName();

    /**
    * Returns the tooltip of the action which is displayed to the user.
    *
    * @return
    */
    public String getTooltip();

    /**
    * Returns the name of the icon for this action. If this is <code>null</code>, no icon will be
    * shown.
    *
    * @return
    */
    public String getIconName();
    }
    and that is the ActionResult interface:

    /**
    * Interface for the result of an action. This indicates if the result of the action as well as a
    * message for the user.
    *
    * @author Marco Boeck
    *
    */
    public interface ActionResult {

    /**
    * Outcome possiblities of an action. If the action has no clear success/failure state, use
    * {@link Result#NONE}.
    *
    */
    public enum Result {
    /** indicates that the action was successful */
    SUCCESS,

    /** indicates that the action has failed */
    FAILURE,

    /** indicates the action had no clear success/failure state */
    NONE
    }

    /**
    * Returns the {@link Result} of the action.
    *
    * @return
    */
    public Result getResult();

    /**
    * Returns a human readable message for the user which can be displayed once an action is
    * complete.
    * <p>
    * The message should be <strong>short</strong> and precise, otherwise it might not fit in the
    * UI.
    * </p>
    *
    * @return
    */
    public String getMessage();
    }
    Regards,
    Marco
  • petar_rpetar_r Member Posts: 6 Contributor II
    Hi 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:
    @Override
    public ConfigurationPanel<SPARQLConfigurable> createConfigurationPanel() {
    return new SPARQLConfigurationPanel();
    }
    where SPARQLConfigurationPanel is:

    public class SPARQLConfigurationPanel extends
    ConfigurationPanel<SPARQLConfigurable> {
    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:

    image

    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
  • Marco_BoeckMarco_Boeck Administrator, Moderator, Employee, Member, University Professor Posts: 1,996 RM Engineering
    Hi,

    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
  • petar_rpetar_r Member Posts: 6 Contributor II
    Hi 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:

    types.add(new ParameterTypeCategory(PARAMETER_READER_TYPE, "Reader type",
    PARAMETER_READER_TYPE_OPTIONS, 0, false));

    ParameterType type = new ParameterTypeString(PARAMETER_ENDPOINT,
    "The URL of the SPARQL endpoint to use.",
    "http://dbpedia.org/sparql/", false);

    type.registerDependencyCondition(new EqualTypeCondition(*null*,
    PARAMETER_READER_TYPE, PARAMETER_READER_TYPE_OPTIONS, true, 0));
    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
  • Marco_BoeckMarco_Boeck Administrator, Moderator, Employee, Member, University Professor Posts: 1,996 RM Engineering
    Hi,

    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
Sign In or Register to comment.