"Using XStream in RapidMiner Extensions"

janvanrijn

Hi,

It's been a while since we presented this concept onRCOMM2013, but finally I found some time to work on the OpenML extention for RapidMiner. Earlier this year I created theOpenML ApiConnectorfor Java, which makes it very convenient to communicate with the OpenML server from a Java environment. The OpenML ApiConnector uses XStream to convert an object from the webbased API into a Java Object.

However, I encountered two problems.

First, the version of XStream that we use is 1.4.7 (in fact, any version beyond 1.4.5 should be fine). However, RapidMiner (5.3.x) uses an older version of XStream, I can't exactly figure out which version, but it clearly lacks the function xstream.ignoreUnknownElements() (I really shouldn't go into details here). Although my extension also includes the version of XStream it relies on, RapidMiner apparently (and obviously) gives precedence to its own version. I can't be the first encountering a problem like this, is there any way around it?(Found the answer to this in an older thread)

Second, (after upgrading the XStream library for my local version of RapidMiner, I know this is ugly) get the following error: com.thoughtworks.xstream.mapper.CannotResolveClassException: org.openml.apiconnector.xml.Task
显然,XStream org.openm找不到类l.apiconnector.xml.Task, which does exist in the extension jar. This function has been tested extensively stand alone. My best guess is that this is a classpath problem, and that XStream is not instructed to look in the extension jar.

I shouldn't burden you with the stacktrace of the program, since I think this would not add much information, but I can attach it if you think otherwise. The main question is, have you ever tried using XStream in extensions, if yes, did you encounter the same problems, and if yes again, how did you overcome those? Especially the second problem is one that keeps me stuck.

Thanks in advance.
Jan

janvanrijn

So, I was finally able to figure out the second problem as well.

As it appears, RapidMiner does not add the plugin JARs to the classpath. When I execute RapidMiner with the following command it works:
java -cp lib/rapidminer.jar:lib/plugins/* com.rapidminer.gui.RapidMinerGUI

Otherwise, it doesn't.

Some questions remain, hopefully someone will be able to pick up on these. Is there any reason for not adding these plugins to the classpath? Does it imply any security risk if I run RapidMiner this way myself? And what would be the most convenient way to make users in the future use this plugin? Adding an installation description does not seem optimal, as this will throw many unexpected errors to users not familiar with the cli. I can't be the first person having a problem like this. Maybe you know a solution?

Best regards,
Jan

Marco_Boeck

Hi,

Classloading for extensions is done via the plugin classloader. Have a look at the package com.rapidminer.tools.plugin. Everything related to classloading for extensions can be found in there. I don't know what causes your problem though as I never had to bother myself with extension classloading yet.

Btw, RapidMiner Studio 6 ships with XStream 1.4.7

Regards,
Marco

janvanrijn

Although it has been a while since I posted this question, yesterday I finally got into it again and figured out the solution. Hopefully this is useful to other people as well.

In order to use XStream in a RapidMiner setting, the following XStream Constructor can be used in combination with an appropriate classloader:

XStream xs = new XStream(null,
new DomDriver("UFT-8", new NoNameCoder()),
new ClassLoaderReference(Plugin.getMajorClassLoader()));

Also the XStream version problem has been solved by indeed building against RM Studio.

马可,感谢指出我在the right direction on both issues. I consider this issue solved.