Forum Discussion

joostdgfed's avatar
joostdgfed
Occasional Contributor
27 days ago

As of v3.60.0 preloading groovy file from script library breaks cross referencing

My situation: I have a big script library with multiple groovy files. I have for instance "groovyScriptA.groovy" which has methods "ScriptA1()", "ScriptA2()" and "ScriptA3()'. Another script library file is "groovyScriptB.groovy" which has methods "ScriptB1()" and "ScriptB2()".

In method "scriptA3()" I make use of the method "scriptB2()". This was never a problem...until ReadyApi released version 3.60.0. There I've noticed there is a new feature, which does some preloading of the script library. 

In logs from 3.60.0 & 3.61.0 I can see:

13:14:34,777 INFO  [SoapUIProGroovyScriptEngineFactory] Adding Script Library at [/var/jenkins_agent_home/workspace/ci-jobs/abc/xyz/abc-readyapi-project/scripts]

13:14:34,777 INFO  [SoapUIProGroovyScriptEngineFactory] Preloading groovy file: groovyScriptA.groovy

13:14:34,790 ERROR: Error preloading groovy file: /var/jenkins_agent_home/workspace/ci-jobs/abc/xyz/abc-readyapi-project/scripts/groovyScriptA.groovy

ReadyAPI logs a compilation error during this preloading:: "unable to resolve class scriptB2". When I have it locally, I can refresh the project and then the error no longer shows, all script library files are properly loaded. But in the build pipeline the error is encountered and all my tests relying on the script library groovyScriptA.groovy will fail. From what I can tell, it's also intermittently. I guess sometimes the sequence of preloading changes, so when "groovyScriptB.groovy" is preloaded before "groovyScriptA.groovy" then the error does not show. 

What I tried: 

  • an "import groovyScriptB" in "groovyScriptA.groovy"
  • an "import groovyScriptB" in "groovyScriptA.groovy" together with defining package
  • renaming the class names to best practice upper casing
  • making sure I have "groovyScriptB.groovy" saved as last so that the it would preload the most recent first

Unfortunately, nothing makes cross-referencing methods work again. We had to revert back to v3.59.0. I hoped this breaking change was detect by SmartBear and fixed in v3.61.0, but I can confirm it's still there. I will also log a SmartBear customer care support ticket = Case #00737901.

Note that in the logs from v3.59.0 there is no sign of this "Preloading groovy file". There it consistently works fine.

Example v3.59.0 logs:

17:30:23,763 WARN [SoapUIProGroovyScriptEngineFactory] Missing scripts folder [/home/jenkins/scripts]

17:30:23,763 INFO [SoapUIProGroovyScriptEngineFactory] Resetting groovy class cache due to 11 modified files

17:30:23,764 INFO [SoapUIProGroovyScriptEngineFactory] Adding Script Library at [/var/jenkins_agent_home/workspace/ci-jobs/abc/xyz/abc-readyapi-project/scripts]

11 Replies

  • sdeevers_starz's avatar
    sdeevers_starz
    Occasional Contributor
    20 days ago

    I'm not sure if this might be the issue people are having, but I thought I would drop a note as all our script libraries are working as expected with R-API Release 3.61.0.

    In order for the script libraries to load, I checked the preferences, Other, ReadyAPI "Script Library" setting to ensure the path was correct.

    I also checked the "ReadyAPI Log" info after I updated the setting and did see all of our script libraries were being preloaded.

    I then ran one of our tests which has several script libraries associated (as well as some script libraries called within a script library) and was able to see the script libraries were executed as expected.

    Hope this helps!

    • joostdgfed's avatar
      joostdgfed
      Occasional Contributor
      20 days ago

      Hi sdeevers_starz​ . To me it looks like an intermittent issues, so sometimes it's fine, but a subsequent opening of the project results in the error. If that would be the workaround, it's not going to fit our case neither: We specify our script library through a relative path. See example below project property = pah is in our composite readyAPI project folder subfolder "scripts". 

      We need this as we want other testers that check out the readyAPI project to also be able to retrieve the scripts. Your script library points to an absolute path on your c: drive, which might not be present for other testers. Furthermore, we run the test through CI pipeline on Jenkins, which runs on a linux system, so there the path is totally different.

       

  • DinaE's avatar
    DinaE
    Occasional Contributor
    20 days ago

    I have a similar issue in v3.59.0 & 3.60.0. in Jenkins execution, when executing a groovy step that has a reference in the script library, it keeps trying to reload readyapi-settings.xml and the execution finally hangs.

    09:57:46,508 INFO [SoapUIProTestCaseRunner] running step [Groovy Script] 09:57:55,426 INFO [DefaultSoapUICore] Reloading updated settings file 09:57:55,428 INFO [DefaultSoapUICore] ReadyAPI settings were initialized from [************\.readyapi\readyapi-settings.xml] 09:57:57,329 INFO [DefaultSoapUICore] Reloading updated settings file 09:57:57,332 INFO [DefaultSoapUICore] ReadyAPI settings were initialized from [************\.readyapi\readyapi-settings.xml]

     

  • sdeevers_starz's avatar
    sdeevers_starz
    Occasional Contributor
    20 days ago

    joostdgfed​  - This would be a problem for a lot of us who are using script libraries if Release 3.60.0 and Release 3.61.0 do not consistently load them.
    I was hoping I could upgrade to Release 3.61.0 which does resolve the failed test steps issue, but if loading script libraries is broken, then I guess I will stay at 3.59.0 and deal with the steps failing and reviewing the test case / test suite transaction log for failures after they have ran till this is resolved.

  • joostdgfed's avatar
    joostdgfed
    Occasional Contributor
    21 days ago

    Hi cbui​ ,

    Your issue has nothing to do with your scripts itself, but with the way SmartBear loads the script library. As same projects with same scripts were working fine on 3.59, it is clearly a breaking change they apparently were unaware of. My support case is (luckily) still open and their dev team will investigate further. I do hope on a quick fix on their side. I told them reverting to 3.59 was also not an option as that version still has the other incorrect status reporting issue (see https://community.smartbear.com/discussions/readyapi-questions/r-api-3-59-0-shows-test-case-passed-although-there-are-failed-test-steps/275754 ). So we actually should then move back to 3.58. Not a real good evolution if you need to tell your paying customers to ignore the last 3 releases of your tool...

    • cbui's avatar
      cbui
      New Contributor
      20 days ago

      Thanks joostdgfed​ for your comment.

      Yes, I believe there is something wrong with SoapUIProGroovyScriptEngineFactory

      Hopefully, this issue can be addressed soon by ReadyAPI team.

  • cbui's avatar
    cbui
    New Contributor
    23 days ago

    I am having the same issue, I tried with both ReadyAPI 3.60 and 3.61.

    The issue occurred after putting our groovy scripts under <ReadyAPI Install Dir>/bin/scripts . This is new change from ReadyAPI

    It was working fine using ReadyAPI 3.56.0 and the groovy script can be anywhere in our local machine.

    I opened this case number Case #00737670. However, the customer care engineer said "We do not provide support for scripting"

    So I am stuck. I need to upgrade to 3.60 but I don't have the solution for this issue yet.

    2025-06-27 10:16:40,498 ERROR [SoapUIProGroovyScriptEngineFactory] Error preloading groovy file: /Applications/ReadyAPI-3.60.0.app/Contents/java/app/bin/scripts/ProjectHook.groovy
    org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:

  • HansSteenblok1's avatar
    HansSteenblok1
    New Member
    26 days ago

    Since version 3.60 we get similar errors when executing groovy scripts. We get the following error message

    No signature of method: xxx.yyy.zzz.functionname() is applicable for argument types: (xxx.yyy.zzz.class1) values: [xxx.yyy.zzz.class1@31ea1923]
    Possible solutions: functionname(xxx.yyy.zzz.class1)

    It seems like readyapi doesn't recognize classes of the same type as the same type anymore. We also get errors like

    Cannot cast object 'xxx.yyy.zzz.Class1@79016ff4' with class 'xxx.yyy.zzz.Class1' to class 'xxx.yyy.zzz.Class1'

     

    • HansSteenblok's avatar
      HansSteenblok
      New Contributor
      17 days ago

      I solved the problem for us by transforming lots of .groovy files into .java files. With those .java files I created a .jar and added that jar to readyapi as 'Custom java library'. 

      • cbui's avatar
        cbui
        New Contributor
        13 days ago

        Thanks HansSteenblok​ for your input. I will try it later.

        All of our test cases setup/teardown steps heavily depend on our groovy scripts. btw, the effort to transform them all is high. 

        Hopefully, Smartbear team can help to resolve this issue.