Forum Discussion
HP-Plano-TX-Soa
11 years agoOccasional Contributor
Ok - I have a work-around, if not a solution, for the problem. The error complains that "com.eviware....." is not a property of my teardownScripts class.
So, I created a reference to com.eviware.soapui.SoapUI.logMonitor and I pass that as a property to my custom teardownScripts class, like this (from inside the soapUI TestCase teardown):
Now, inside my teardownScripts class, I added the logMon Property (to both the class definition and to its constructor), and I use it to invoke desired methods on the com.eviware.soapui.SoapUI.logMonitor object, instead of trying to import com.eviware.soapui.SoapUI.logMonitor and trying to reference it directly, which produces the error that "com" is not a valid property of my class.
The JAR file I create for the SoapUI Free version to use, which contains my entire package of custom scripts, now works perfectly. And both the Pro and the Free version can use the same central groovy script library (albeit from different sources - Pro from the source library itself, and Free from the JAR file created from that selfsame source library). This is important, since we don't want to produce test automation that won't run on the Free version.
This is pretty silly, really. In the Free version you should be able to simply import com.eviware.soapui.SoapUI.logMonitor and use it from inside a groovy script that is JAR'ed up and placed in the ...\bin\ext\ directory. You shouldn't have to explicitly make it a Property of your class and pass it in, as I am having to do here.
If someone has a real solution, I'm sure plenty of people would appreciate knowing about it, since I can't be the only person trying to produce automation that will run seamlessly on both the Free and Pro versions of SoapUI.
So, I created a reference to com.eviware.soapui.SoapUI.logMonitor and I pass that as a property to my custom teardownScripts class, like this (from inside the soapUI TestCase teardown):
def [b]logMon[/b] = com.eviware.soapui.SoapUI.logMonitor
def tdscript = new customScripts.teardownScripts(log, context, testRunner, testCase, [b]logMon[/b])
tdscript.Teardown()
Now, inside my teardownScripts class, I added the logMon Property (to both the class definition and to its constructor), and I use it to invoke desired methods on the com.eviware.soapui.SoapUI.logMonitor object, instead of trying to import com.eviware.soapui.SoapUI.logMonitor and trying to reference it directly, which produces the error that "com" is not a valid property of my class.
The JAR file I create for the SoapUI Free version to use, which contains my entire package of custom scripts, now works perfectly. And both the Pro and the Free version can use the same central groovy script library (albeit from different sources - Pro from the source library itself, and Free from the JAR file created from that selfsame source library). This is important, since we don't want to produce test automation that won't run on the Free version.
This is pretty silly, really. In the Free version you should be able to simply import com.eviware.soapui.SoapUI.logMonitor and use it from inside a groovy script that is JAR'ed up and placed in the ...\bin\ext\ directory. You shouldn't have to explicitly make it a Property of your class and pass it in, as I am having to do here.
If someone has a real solution, I'm sure plenty of people would appreciate knowing about it, since I can't be the only person trying to produce automation that will run seamlessly on both the Free and Pro versions of SoapUI.
Related Content
- 5 years agohenil_shah
- 11 years agotestlc
Recent Discussions
- 8 days agoemoya