benken_parasoft ✭✭✭


Last Active
Members, Staff
  • Re: Succesfull test in SOATest fails with SOATestcli.exe

    soatestcli gets preference settings from a java property file you pass for the command line argument "-localsettings path_to_property_file". In your property file, you'll want to set the property "datasources.jdbc.classpath".

    For detail, please see Configuring Localsettings.

  • Re: Does SOATest support Thumbprint SHA1?

    That type of ClassCastException should not happen anymore in the next release. For now, you can remove the javax folder from the XMLSecurity.jar located under "{soatest_install}/eclipse/plugins\com.parasoft.xtest.libs.web_{ver}/root/lib-java-mod". For example, you could rename the jar to "", delete "javax" from zip file, then rename back to "XMLSecurity.jar" again. Don't forget to close SOAtest before modifying the jar.

  • Re: Does SOATest support Thumbprint SHA1?

    Just about anything is possible using scripting, provided you are able to write the code you need. In this particular case, it is possible to chain an Extension tool to the outgoing Request output to transform the message, like how you would chain an XML Signer tool. So, instead of chaining an XML Signer you could chain an Extension tool that would invoke WSS4J APIs to sign the SOAP message your script receives as input and then return the signed version. I don't know if you care to attempt this. You would effectively be coding your own custom version of the XML Signer.

    If you want to attempt to code this, you would create an instance of then invoke a bunch of methods on it. I don't have any code to share with you. However, in case this helps, WSS4J has some unit tests that can be helpful to get an understanding for how to user their API, such as SignatureTest.testX509SignatureThumb().

    Again, I don't know if you care to attempt this. I just want to highlight that you can do just about anything with scripting. Scripting always enables you to do something in SOAtest that is not otherwise available out-of-box.

  • Re: SOATEST: Not able to connect to database while using Oracle 12.2 JDBC drivers

    I installed JDK 8 yesterday on my machine and SOATEST was still running fine after and before, until I changed the driver to

    You must also pass the -Zjava_home argument I mentioned earlier. By default, SOAtest has its own private java installation for launching itself. To use a different java installation, like one you installed under C:\Program Files\Java\jdk1.8.0_xxx. you must specify -Zjava_home and then the path to the Java 8 installation.

    So I am a little confused here why SOATEST is complaining about Java version while using the new driver and works fine while using the old driver.

    The older Oracle JDBC driver was probably compiled for Java 7 or earlier. The newer Oracle JDBC Driver you started using is compiled for Java 8.

  • Re: SOATEST: Not able to connect to database while using Oracle 12.2 JDBC drivers

    java.lang.UnsupportedClassVersionError: oracle/jdbc/OracleDriver : Unsupported major.minor version 52.0

    Java class file version 52 means java 8 is required. You must start SOAtest with Java 8 in order for Java to be able to load classes built with java 8, like those from the Oracle JDBC driver.

    The current SOAtest release ships with Java 8. Otherwise, if you must use an older SOAtest release, you can install your own Java 8 then start SOAtest with a -Zjava_home command line argument as follows:
    soatest.exe -Zjava_home path_to_your_java_8_installation