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
How can I prevent Rapidminer from initializing multiple times?
Contributor II
Hello everyone,
First of all, thank you very much for this awesome software. I am working on my diploma thesis and I am integrating rapidminer into my application to validate my findings. So far I have been able to integrate the application just fine and I have to say the GUI works very well for designing the processes.
Here is my problem however. The project I am working on requires the software to be built with Maven. I have written test cases for each of my process wrappers for jUnit and they work great when I run them separately. However when I run the tests in chain during the maven build process I get a ton of AssertionErrors that, as far as I can tell, originate from the fact that jUnit creates a new instance of my wrapper in each test and as such tries to initialise rapidminer more than once.
I can not work around the limitation that jUnit tries to create new instances with each test. My question thus is: Is there a way to find out if rapidminer has already been initialized? I do keep track of it in my application but since each tests starts a new instance I would require a way to ask the RapidMiner process if it has already been initialized.
Below is the stack trace I get when the tests are run automatically.
Thanks in advance for your help,
Daniel
First of all, thank you very much for this awesome software. I am working on my diploma thesis and I am integrating rapidminer into my application to validate my findings. So far I have been able to integrate the application just fine and I have to say the GUI works very well for designing the processes.
Here is my problem however. The project I am working on requires the software to be built with Maven. I have written test cases for each of my process wrappers for jUnit and they work great when I run them separately. However when I run the tests in chain during the maven build process I get a ton of AssertionErrors that, as far as I can tell, originate from the fact that jUnit creates a new instance of my wrapper in each test and as such tries to initialise rapidminer more than once.
I can not work around the limitation that jUnit tries to create new instances with each test. My question thus is: Is there a way to find out if rapidminer has already been initialized? I do keep track of it in my application but since each tests starts a new instance I would require a way to ask the RapidMiner process if it has already been initialized.
Below is the stack trace I get when the tests are run automatically.
Thanks in advance for your help,
Daniel
java.lang.AssertionError
at com.rapidminer.io.process.rules.ChangeParameterValueRule.<init>(ChangeParameterValueRule.java:47)
at com.rapidminer.io.process.XMLImporter.constructRuleFromElement(XMLImporter.java:198)
at com.rapidminer.io.process.XMLImporter.importParseRules(XMLImporter.java:169)
at com.rapidminer.io.process.XMLImporter.init(XMLImporter.java:125)
at com.rapidminer.RapidMiner.init(RapidMiner.java:513)
at my.application.processing.wrappers.rapidminer.AbstractRapidMinerWrapper.init(AbstractRapidMinerWrapper.java:213)
at my.application.processing.wrappers.rapidminer.AbstractRapidMinerWrapper.runProcess(AbstractRapidMinerWrapper.java:253)
at my.application.processing.wrappers.rapidminer.AbstractRapidMinerClusteringWrapper.apply(AbstractRapidMinerClusteringWrapper.java:88)
at my.application.processing.wrappers.rapidminer.AbstractRapidMinerClusteringWrapper.apply(AbstractRapidMinerClusteringWrapper.java:68)
at my.application.processing.wrappers.rapidminer.RMHACCompleteWrapper.process(RMHACCompleteWrapper.java:56)
at my.application.processing.wrappers.rapidminer.RMHACCompleteWrapperTest.testClustering(RMHACCompleteWrapperTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Tagged:
0
Answers
TestContext is a singleton class with some convenience functions for testing.
There is also a class called RapidAssert which allows convinient comparison of ExampleSet and other IOObjects.
Please note that the test api is not stable and might change in the future (there are no changes planned currently, but you never know :-) )
Best, Marius
Thank you for your reply. I am currently using rapidminer 5.2.2. The rapidminer.jar does not seem to contain the package com.rapidminer.test for that release, only the package com.rapidminer.test_utils. Do I have to switch to another release or am I missing a jar?
Thanks,
Daniel
you are right, the tests are not included in the jar file. You could of course check out the source code of RapidMiner. But the mechanism is simple: create a singleton class with a member variable which indicates if RapidMiner has been initialized. If the initRapidMiner() method of the singleton is called, the first time it initializes RapidMiner. Afterwards all subsequent calls will be ignored.
Best, Marius
Thanks again. I did find the source and created the jar in the meantime. Unfortunately I keep getting the same error, just that the TestContext appears in the stack trace as well now.
Right before the errors appear the rapidminer logging output is the following. I though it was caused by multiple initializations but apparently it wasn't.
Any ideas about what might be going wrong here?