-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Jenkins LTS v2.73.1, Pipeline: Groovy 2.40, Pipeline: Shared Groovy Libraries 2.9
With the following three classes in a shared library (in the package 'com.cloudgine.notify' in my case, as seen in the exception):
class BaseClass implements Serializable { BaseClass() { this.testVar = '' } String testVar public testMethod() {} }
class ChildClassA extends BaseClass { public testMethod() { def x = testVar } }
class ChildClassB extends BaseClass { public testMethod() { def x = testVar } }
And the following code in a pipeline script using that shared library:
def childA = new ChildClassA() childA.testMethod() def childB = new ChildClassB() childB.testMethod()
The following exception will be seen:
groovy.lang.MissingFieldException: No such field: testVar for class: com.cloudgine.notify.ChildClassB at groovy.lang.MetaClassImpl.getAttribute(MetaClassImpl.java:2846) at groovy.lang.MetaClassImpl.getAttribute(MetaClassImpl.java:3782) at org.codehaus.groovy.runtime.InvokerHelper.getAttribute(InvokerHelper.java:147) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getField(ScriptBytecodeAdapter.java:306) at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.getAttribute(DefaultInvoker.java:43) at com.cloudbees.groovy.cps.impl.AttributeAccessBlock.rawGet(AttributeAccessBlock.java:20) at com.cloudgine.notify.ChildClassB.testMethod(/var/lib/jenkins/jobs/Experiments/jobs/Test_ChildClassMissingFieldException/builds/24/libs/pipeline-common/src/com/cloudgine/notify/ChildClassB.groovy:7) at WorkflowScript.run(WorkflowScript:11) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74) at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66) at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:83) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163) at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748)
This does not occur if all of this code is ran within a single pipeline script.
I can workaround it by calling getTestVar() instead of testVar
If I don't instance childClassA, childClassB will work fine. Instancing two of any one class on their own also works fine.
I found this originally in a more complex case in which BaseClass was an abstract class and testMethod() was an abstract method, if the code looks odd at first, but simplified the repro for the report.
- duplicates
-
-
- Open
-
[JENKINS-47355] groovy.lang.MissingFieldException when accessing a property in the second instanced child class, where both classes inherit from the same base class, only in shared libraries
Yeah, inheritance of a CPS-transformed class, i.e., one from a shared library, doesn't work right in a bunch of ways. I'm not sure we can actually fix it, to be honest, but I'll dig into it.
roel postelmans
added a comment - Changing
String testVar
to
public String testVar
Fixes the problem 
roel postelmans
added a comment - Changing
String testVar
to
public String testVar
Fixes the problem 
I've had the same issue. I notice that a parent class and child class, from sharedlibraries, also cannot exist in the same pipeline. To be more specific about the problem, the object will not be able to access the properties it inherited from the parent class. You can not work around this issue by choosing to not 'import' the classes and by separating them by scope. In other words you can't simply declare them each in their own methods on the pipeline script. The issue occurs if you import both child and parent classes and never declare an object of the parent class. If you declare an object whose class in turn imports the parent class, the child or sibling object will have the issue in the pipeline, after the pipeline script executes the line that declares and uses that object.
I observe that the issue is not triggered if you are declaring sibling objects within a sharedlibraries class. Therefore, as a work around, I have created an 'accessor' class that has the different sibling objects I need as properties of the accessor class. This is a bad workaround; if I ever need multiple instances of an object and have sibling objects in the same pipeline, I will need to declare multiple instances of the accessor class, which can be wasteful.