Known limitations of custom groovy classes packaged in a JAR file
- 8 years ago
Hi,
Thanks for the questions here and on the blog:
http://rupertanderson.com/blog/1-how-to-develop-add-and-use-a-custom-groovy-library-in-soapui/
On the first question about the exception handing behaviour, an example would help as nmrao said.
The second question about how to log from the extension is a good one, ideally I'd like to add that to the blog, but will try to reply here first for time reasons. So, perhaps the easiest way is to just get hold of SoapUI's script log tab using Log4J. Following on from the blog, please consider the following simple extension library class:
package custom import org.apache.log4j.Logger public class SequentialIdGenerator { public static final Logger soapuiLogFileLogger = Logger.getLogger(getClass()) public static final Logger scriptLogger = Logger.getLogger("groovy.log") public static void logSomething(){ scriptLogger.info "Hello scriptlog from extension!" } }
To compile this with Gradle, we need to add the Log4J dependency:
apply plugin: 'groovy' version = '1.0' jar { classifier = 'sample' manifest { attributes 'Implementation-Title': 'SoapUI Sample Groovy Library', 'Implementation-Version': version } } repositories { mavenCentral() } dependencies { compile 'org.codehaus.groovy:groovy:2.1.7' compile group: 'log4j', name: 'log4j', version: '1.2.17' }
Once, build i.e. gradle clean build jar, the jar added to SoapUI /ext folder and SoapUI restarted, we can call the class and see logging in the standard SoapUI 'script log' tab:
Is this what you wanted?
As for other imitations, we would need to discuss them in turn. I am not sure that there are specific limitations as such, more things we need to provide extra code for, but it does depend on exactly what you need to do. For example, this approach is probably not a good way to extend/override the core SoapUI functionality e.g. better to do it directly in the product source or possibly via a plugin.
Regards,
Rupert