Groovy Error: Unable to resolve class internal.GlobalVariable

Tested 5.11.0-beta. Exactly the same result as 5.10x :sob:

@Russ_Thomas I’m still pretty convinced that there’s some discrepancy between your particular project code and the later versions of the studio. If you create a brand new project in 5.10.1 (or the 5.11.0 beta), and write a quick test case that somehow uses the GlobalVariable class, I’m almost positive you will not have a problem. Maybe this would test it?:

1.) Add a test url in the default profile:

2.) Simple test case that uses this var:

import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import internal.GlobalVariable as GlobalVariable

WebUI.openBrowser(GlobalVariable.url);

If that works, then in my mind the best path forward would be to generate a brand new project using 5.10.1, then bring all of your current project code into the new project. Tedious for sure, but it might be the best option.

Thanks.

Yes, me too, Brandon. But…

1 - It’s legal groovy (we think)
2 - Katalon (@YoungNgo and @devalex88) have my GlobalVariable stuff to dissect.

Plus they’re welcome to log on to my box anytime (as Dung has done before).

Dung was hopeful that .11 might inch them closer to finding the cause but on the face of it (the results anyway) I don’t see any change.

For now, I’m content and in favor of letting them debug it while longer.

If I had the time (because I’m a crazy person) I’d consider loading old versions one-by-one to do a proper “which version killed me” test. That way they might get closer to a series of suspect commits. But I don’t have that time, right now.

Having said all of that, I’m slowly removing ALL GVs (only about half dozen to go). Then we’ll see if the GV complaint is real or just a symptom of something else (obviously, that would be the worst scenario).

Thanks again.

@Russ_Thomas I hope you kept a copy of your project so that new version can be tested against that :blush:.

Of course. I have more backups than lines of test code :nerd_face:

@YoungNgo, @devalex88, @Brandon_Hein

I’ve solved the issue. :sunglasses: I also can see the cause of the bug in Katalon, too. :nerd_face:

I’ll be back with more information once I’ve made the bug details clear to @devalex88.

Hopefully, this is the cause and/or a pointer to other similar issues as to why only some people get this problem and can’t upgrade in a timely manner.

4 Likes

Thought I’d never see the day!!! Congrats! :tada:

1 Like

So. For whatever reason (too busy at the time; fog of war; sheer laziness) I didn’t bother looking in great detail at my globalvariables.groovy file when I sent it along to @devalex88 and the team to investigate. I certainly should have. Kicking myself now…

But let’s not get ahead of the story… here’s how it all went down, this morning…

I thought I’d give the KS 5.11 beta another try. Same issue as before. And the annoying thing, the Problems pane shows (showed) nothing.

Ah, but… it DID have something in it, but Katalon shows it as hidden on first heading in there. Click the header and all was revealed. Problem in GlobalVariables (surprise, surprise).

I double-clicked the entry and up popped the GV groovy file automagically produced by KS at startup of a test. It highlighted one particular variable:

"$WE_ACTIVE"

You’re ahead of me, now, right? :sunglasses:

In 5.4x (at least) that variable says:

'$WE_ACTIVE'

So, new mantra (to be adopted by the Katalon Devs, hopefully)

“Thou shalt not use double-quotes unless you can predict (or otherwise control) the content therein”

I sincerely hope this is the cause of many other failed upgrades.


UPDATE:

6 Likes

Hi, I am using Version: 5.10.1 (Build: 1) but still have the same issue. Does anyone know how to resolve it please…

19 Groovy:unable to resolve class internal.GlobalVar
21 Groovy:unable to resolve class internal.GlobalVariable
35 Groovy:unable to resolve class internal.GlobalVariable
19 Groovy:unable to resolve class internal.GlobalVar
21 Groovy:unable to resolve class internal.GlobalVariable
35 Groovy:unable to resolve class internal.GlobalVariable

Vik

No, sorry! :tired_face:
Why would the double-quotes be the problem? Is it a Groovy thing?

Sorry, I didn’t mean to be so obtuse…

GStrings are the problem. Groovy thinks it’s bumping into "${placeholder}… but when it doesn’t see { following $ it expects $ to be escaped. You (we, users) can’t escape strings in files over which you have no control…

Someone switched the quotes from to " in a template used by Katalon. Hence the mantra… :sunglasses:

Ok :+1:

I think I got it.

Any progress on this issue?

I’m on 5.10.1 Build 1 on a windows 10 machines and seeing this error when running from command line only. Have tried the various suggestions (deleting bin, libs, etc… checking to make sure that the gitignore is set up correctly) but it’s still persisting.

I tried the suggestion from @Russ_Thomas changing " to ’ and @Brandon_Hein deleting some folders but I still get the same issue… and it was random… The only thing I remember doing beforehand is removing one of an obsolete Global variable (Profile) file and hitting the “Clean up” function :frowning:
I am using 5.10.1

Ok, I got the UI scripts working by doing the following sequence:

  1. Removing the bin, Libs, .classpath and .project as suggested by @Brandon_Hein
  2. Modifying GlobalVariable.groovy from " to as suggested by @Russ_Thomas

So now it works for UI scripts. However, my API (services) scripts are still not working with error below:

javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: **Unable to resolve imported document at 'http://${url}/FTACTR/services?wsdl'.: java.net.UnknownHostException: ${url}**
	at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
	at com.kms.katalon.core.webservice.common.SoapClient.parseWsdl(SoapClient.java:83)
	at com.kms.katalon.core.webservice.common.SoapClient.send(SoapClient.java:142)
	at com.kms.katalon.controller.WebServiceController.sendRequest(WebServiceController.java:107)
	at com.kms.katalon.composer.webservice.parts.SoapServicePart$4.run(SoapServicePart.java:232)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
Caused by: java.net.UnknownHostException: ${url}
	at com.ibm.wsdl.util.StringUtils.getContentAsInputStream(Unknown Source)
	... 6 more

My ${url} is set from the GlobalVariable and gives the error as per attached.

However, if I put the actual WSDL URL, it works.

Groovy string interpolation works with “${ }” but not with ‘${ }’. Can you work around that?

I don’t think it’s “off topic”. The error above is when I click “Test Request and Verify” on the actual “Web Service” which I believe would help the katalon developers find the root cause better. To prove this, when I run the same API script under a “test case”, I get EXACTLY the same error as the OP posted:

Reason:
java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable
	at CUBNK - Transfer Funds via Web Service.run(CUBNK - Transfer Funds via Web Service:30)
	at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
	at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
	at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:328)
	at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:319)
	at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:298)
	at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:290)
	at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:224)
	at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:106)
	at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:97)
	at com.kms.katalon.core.main.TestCaseMain$runTestCase$0.call(Unknown Source)

I am happy to create a new topic if that is the rule here but I’m sure it will lead me back to the same thread.

Still?!?!?
I can run the console in any environment but the docker container. How is this still a problem since katalon 5.4.

None of the solutions above even make any sense??

@Russ_Thomas says there is something like “$WE_ACTIVE” in my GlobalVariables.groovy, but I have no idea what that is about.

I also noticed in the logs the global variables are loaded after the keywords. See my logs:

Delete folder: bin
Delete folder: Libs
Opening project file: /Users/me/Katalon Studio/katalon-ci/katalon-ci.prj
Request sent successfully.
Parsing custom keywords...
/%Users%me%Katalon Studio%katalon-ci%katalon-ci.prj/Keywords/com/example/util/FileReader.groovy: 19 
Groovy:unable to resolve class internal.GlobalVariable
Generating global variables...
/%Users%me%Katalon Studio%katalon-ci%katalon-ci.prj/Test Listeners/ExampleListener.groovy: 16 
Groovy:unable to resolve class internal.GlobalVariable
Project 'katalon-ci' opened

Afraid so.

  1. None of the solutions above work for me, except my own but Katalon then breaks itself again.
  2. They all make sense.

I never said you had a copy of my global variable inside your global variables file. You “have no idea what that is about” because you do not understand the problem, nor, it seems, what a global variable is.

Crickets.

Why? What’s your point? What is your question? What are you suggesting as a fix?

I really don’t know what is wrong, I just panicked a bit, I have learned some things though. I’ve spent entirely too much time just trying to figure out what is causing the problem. All I know is when I run a test in docker, I get an error which says my internal.GlobalVariables can’t be resolved. Starting to think this error is about as specific as a NullPointerException.

About my logs I posted before, just started thinking, maybe its the order of operations. It clearly shows the CustomKeywords are parsed and compiled before the GlobalVariables. Probably not the issue though because the same command works on dev machines. Maybe it works on local machine because the ./bin is already made and therefore the globals would exist prior to the CustomKeywords, whereas a Docker container builds it all from scratch.

The only solution I can think of that I have not tried is; maybe the CustomKeywords should simply not use the internal.GlobalVariables. In my case at least, only CustomKeywords using the GlobalVariables implemented in the Listeners before and after methods fail with can’t resolve the Globals. Oddly enough, the test cases I ran all passed and they are all using the global variables. It’s just the Listeners do not run our before and after scripts because of the issue.

Here are a few things I found out in the course of battle. No solutions here but things to watch out for which may or may not cause can't resolve the internal.GlobalVariables.

  • When I import a katalon project to eclipse, the .project file is modifed. Then when you run through terminal you will get a whole bunch of weird and non fatal errors before everything runs fine. Katalon can regenerate the .project file if you delete it.

  • If you were to delete and recreate any of the directories which come with a new katalon project, running through terminal will cause bad errors. For example, I deleted the Test Listeners directory and copied it back from another project. From then on I get even more instances of internal.GlobalVariable can't be resolved, even in the Test Cases.

  • I’m very suspicious of adding Groovy files outside of Katalon, i.e. from eclipse. It’s hard to confirm this causes issues though. Seems like a similar issue to the directory issue above.

  • Back to the deleting and recreating the default dirs, we do not commit our configs from the Profiles dir. In our CI build we mkdir Profiles and curl in a snippet containing the profile/config. Then the CI build simply uses default.glbl as the profile which can be different values depending on which one we injected with curl.

  • You can get issues sometimes when upgrading katalon to new version. I tried copying code from a project which was originally created in a previous version to a brand new project made by the new version. All of a sudden the console output was cleaner. Probably nothing to do with this issue though.

As mentioned earlier, I have no solutions yet, however I’m getting closer. Hopefully my story can help someone get closer to the real problem.

1 Like