Groovy Error: Unable to resolve class internal.GlobalVariable

Ah, certainly your case seems to be a bit more complexed as the Exception you got was

java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable
	at com.xxxxxx.basePage.<init>(basePage.groovy:50)
	at com.xxxxxx.home.<init>(home.groovy)
	at Test Access The Big Four.run(Test Access The Big Four:110)
	at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
        ...

This is not a simple compilation error. There seems to be more factors to investigate.

What is com.xxxxxx.basePage? Is it a custom Page Object class you made, Russ?

Could you please let us have a look at the lines around basePage.groovy:50?

Is it in a static method or a static block? I am asking this because jar - java.lang.NoClassDefFoundError: Could not initialize class XXX - Stack Overflow tells me that java.lang.NoClassDefFoundError: Could not initialize class xxxx is related to something about ClassLoader.

You are getting a java.lang.NoClassDefFoundError which does NOT mean that your class is missing (in that case you’d get a java.lang.ClassNotFoundException ). The ClassLoader ran into an error while reading the class definition when trying to read the class.

My thought: if you Libs/internal/GlobalVariable.grooy has the following code:

      $WE_ACTIVE = selectedVariables["$WE_ACTIVE"]

then, Groovy lang will try to find a property named WE_ACTIVE somewhere in the internal.GlobalVariable class. Groovy lang will try to find WE_ACTIVE as an instance property as well as an static property. If com.xxxxxx.basePage.&lt;init&gt;(basePage.groovy:50) tries to load the internal.GlobalVarialbe class in a static block, then I presume that the ClassLoader may fail to load it and throw NoClassDefFoundError, because the classloader can not find an instance property named WE_ACTIVE.

I do not see what you mean by saying this. Could you elaborate it?


@Russ_Thomas,

Could you try one thing for me?

Your ./Libs/internal/GlobalVariable.groovy file has a line of

$WE_ACTIVE = selectedVariables["$WE_ACTIVE"]

as the following screenshot shows, which you previously attached.

Please edit the file with your favorite text editor as follows:

$WE_ACTIVE = selectedVariables['$WE_ACTIVE']

I mean, enclose $WE_ACTIVE with a pair of single quotes, rather than double quites. Save the change, then try running your test. I guess it would run successful. I want to see if this is the case or not.

I meant, in 5.4 Katalon produces that reference (single quotes) and it works fine. In 5.10+ it generates the same line with double-quotes and shoots itself in the foot.

But that’s the point, Kaz, if I edit the file, once it’s edited and I run a test, Katalon will overwrite it and break it again (at least, I’m assuming it would, I’ve never actually tried).

Yes. In Katalon parlance, it’s a “keyword class”, so public class basePage. My Test Cases extend a specific page class, the page class extends basePage.

Line 50 is literally the basePage constructor:

basePage() { ...

The lines before it are field definitions for the class. IOW, nothing weird.

No, it’s not a static block.

Kaz, I really appreciate your forensic analysis – it’s quite extraordinary. However, you don’t need to look further than the error as depicted in the screenshot. When I double-click the error in the Problems panel, Katalon takes me to the GlobalVariable.groovy file and highlights the $WE_ACTIVE just like the screenshot shows (IOW, I didn’t make it blue, that’s Katalon doing that!) And notice it does not include the $ in the highlight… because it thinks $ is the placeholder marker and the problem is the reference it cannot resolve. Well it’s not a reference, it’s the damn name!

To cut this short, there is an alternative to editing the GV file and changing the quotes - I could change the name to be WE_ACTIVE (i.e. get rid of the $). And guess what - that works. No issues. While @devalex88 and I were looking at it, that worked just fine.

The unfortunate thing is, I have good reason to need the $ in the name (it’s meaningful in the AUT and meaningful to reflect it correctly in the Tests).

However, pragmatism will rule the day - if this cannot be fixed in the next “proper” release of Katalon (6.0.4 is not proper in my view) I will alter the name and remove the $.

Thanks for the research, Kaz. It’s much appreciated! :sunglasses:

No. Once I have ever tried it in my “$FOO” sample project. Katalon did not overwrite the GlobalVariable.groovy source file which I manually edited "$FOO" to '$FOO' when I run my tests. My test once failed but after edit the GlobalVariable.groovy source it turned to succeed. In order to let it fail again, I had to edit it back to "$FOO" and delete the <projectDir>/bin directory so that Katalon Studio compiles the GlobalVariable.groovy source file.

Yes, I understand it.

The point is clear now to everyone who read this thread.

Wow. That’s really surprising.

Not surprising to me.

In <projectDir>/Profiles directory, you will find default.glbl and other *.glbl files. For example, let me show a default.glbl of an example project.

<?xml version="1.0" encoding="UTF-8"?>
<GlobalVariableEntities>
   <description></description>
   <name>default</name>
   <tag></tag>
   <defaultProfile>true</defaultProfile>
   <GlobalVariableEntity>
      <description></description>
      <initValue>'bar'</initValue>
      <name>$FOO</name>
   </GlobalVariableEntity>
</GlobalVariableEntities>

When you edit a Execution Profile ‘default’ using Katalon Studio’s GUI, the edit result will be saved into this ‘global.glbl’ file in XML format.

After then, when a test runs, Katalon Studio reads all of the <projectDir>/Profiles/*.glbl files and generates a single <projectDir>/bin/internal/GlobalVariable.grooy source file, and compiles it into an executable *.class file.

GUI -> XML -> *.groovy -> *.class

This is the way Katalon Studio works, I suppose.

You have a chance to edit manually the GlobalVariable.groovy file which will not be overwritten by Katalon Studio as far as *.glbl XML files stay the same.

4 Likes

Perfect explanation, Kaz. Thank you very much.

The root cause of our problem ('$WE_ACTIVE' or "$WE_ACTIVE") resides in this code generation processing, I believe.

Yes. And hopefully @YoungNgo has already addressed this in the main branch (hopefully destined for master and therefore 5.11+)

1 Like

I got this error as i edited the file default.glbl directly in file system. Then i noticed its not listing the variable on typying GlobalVariable. under script.

I opened the same file in Katalon, and removed the variables and added again. It started working.

So I don’t think the Unable to resolve class internal.GlobalVariable error is anything more than a non fatal warning if you see the error right before the lines below in the console output like so:

katalon    | /%tmp%katalon_execute%project%your-katalon-project.prj/Include/scripts/groovy/Steps.groovy: 21 Groovy:unable to resolve class internal.GlobalVariable
katalon    | Generating global variables...
katalon    | Project 'your-katalon-project' opened

However if you get an error complaining about resolving global variables during a test case, then your project has been corrupted somehow and the global variables are not compiling correctly. Dunno what your issue is. I have had this happen and the error prints out like a normal Java stack trace during the execution of a test case.

For many people, including me, the error is probably something else and it seems like the warning about Unable to resolve class internal.GlobalVariable is an actual error causing us pain, probably not.

Reading through this thread you will realize a whole lot of people having issues with specifically running tests through the console and especially Docker. This thread, in my eyes, has become the default thread for, "I don’t know what happened but I saw Unable to resolve class internal.GlobalVariable in the terminal output.

If by chance you are git-ignoring your Profiles/ dir and/or editing your *.glbl files outside of katalon, I’m pretty sure this is your actual issue. If so, here is another topic I created to discuss profiles and console mode issues.

Good luck!

Everyone, please let us know if this issue has been fixed.

1 Like

@devalex88 @YoungNgo

Works!

:clap: :star_struck: :nerd_face: :sparkler: :man_dancing: :dancing_women: :hearts::hearts::hearts:

4 Likes

I sincerely hope we can close this dreadful thread…

1 Like

Hmm… still doesn’t work…

P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Parser.groovy: 12 Groovy:unable to resolve class groovy.json.JsonSlurper
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Test Listeners/DefaultTS.groovy: 6 Groovy:unable to resolve class internal.GlobalVariable
Parsing custom keywords…
P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Auth.groovy: 8 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Test Listeners/DefaultTS.groovy: 6 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/Project.groovy: 3 Groovy:unable to resolve class internal.GlobalVariable
P.prj/Keywords/api/RestMethods.groovy: 11 Groovy:unable to resolve class internal.GlobalVariable

See my post here. That is not an error, it is a warning. You get that because in your keywords there are imports for the GlobalVariables class which is not parsed till after the keywords. I get the same and everything works fine, it’s just annoying to see in the console. Could be “fixed” by simply removing those imports and not using GlobalVariables in your keywords or listeners.

Thank you. We will look for a way to eliminate these warnings.

1 Like