Script behavior differs between command line & maven plugin

[calandale]

I'm seeing significantly different behavior between the way the testrunner.bat (and the UI) process scripts in relation to loading Keystores and how the maven plugin does. With 4.0.1 and (pro)4.0.2-SNAPSHOT (the 'stable' version returns other errors) the "load script" clearly runs, but it does not change the keystore used to run the script - seeing following errors:


11:29:23,921 ERROR [SoapUI] An error occured [Probably bad PKCS12 password: java.io.IOException: failed to decrypt safe contents entry: java.lang.ArithmeticException: / by zero], see error log for details

along with rather expected:

11:29:24,483 ERROR [WsdlSubmit] Exception in request: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
11:29:24,483 ERROR [SoapUI] An error occured [peer not authenticated], see error log for details


These tests run fine off the testrunner.bat, or the UI


The load script does the following:

import com.eviware.soapui.settings.SSLSettings;
import com.eviware.soapui.SoapUI;


def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
SoapUI.settings.setString( SSLSettings.KEYSTORE, groovyUtils.projectPath + "mystore.p12" )
SoapUI.settings.setString( SSLSettings.KEYSTORE_PASSWORD, "myPassword" )

This is a work-around attempt, to make the settings dynamic on a bamboo server - a necessary matter for our organization.
The UI entered data also does not get loaded by the plugin (haven't tested that on the testrunner.bat)

[calandale]

Behavioral difference that I'm seeing is that the plugin does not appear to have a context


def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
SoapUI.settings.setString( SSLSettings.KEYSTORE, groovyUtils.projectPath + "/PT_mystore.p12" )
SoapUI.settings.setString( SSLSettings.KEYSTORE_PASSWORD, "myPass" )

log.info("path to keystore: " + SoapUI.settings.getString(SSLSettings.KEYSTORE,"missing"))

is logging JUST /PT_mystore.p12

From the command line, it is able to determine context.

[calandale]

This behavior seems tied to launching from maven itself.

Ran under the exec plugin and seeing same behavior.

Appears to be no documentation on these interactions - and as this thread shows, no support.

[calandale]

Behavior surrounds the population of the 'context' as used here:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)

Somehow, maven (both under plugin AND running straight through the exec plugin) is interfering with SOAPUI's ability to populate this value with a path.

Of course, without IDE support, it's not apparent how to debug this behavior.

[terrip]

FWIW, I see the same behavior when executing from ant. For reasons other than just this one, I downloaded a nightly snapshot build, including the source code. There's nothing like the source code! I opened up the GroovyUtils.java class in a text editor and found this:

Code: Select all

   public final String getProjectPath()
   {
      Project project = ModelSupport.getModelItemProject( context.getModelItem() );

      String path = project.getPath();
      int ix = path.lastIndexOf( File.separatorChar );
      return ix == -1 ? "" : path.substring( 0, ix );
   }


Notice the line

Code: Select all

int ix = path.lastIndexOf( File.separatorChar );


So, it turns out that you *have* to specify the project file name using a platform-specific separator character, even if you are using ant/maven. I was sending this: ../projects/<projectFileName>.xml When I changed it to this: ..\\projects\\<projectFileName>.xml, all worked as it should have.

[terrip]

Slight correction to my previous post...

Here is how I construct the path to my project file for the ant java task:

Code: Select all

<arg value="${soapui.project.folder}\${soapui.project.name}"/>


Notice that I don't have to specify \\ in the path name -- a single \ is sufficient. Similarly, when I run testrunner.bat from a DOS shell, I do the following:

Code: Select all

testrunner.bat ..\projects\DirectoryMessaging.xml


Again, a single backslash is sufficient.