Community
Participate
Working Groups
Created attachment 204030 [details] Testcase. Import the attached EGL file. Do a clean build on the project that contains this file. NOTE: If you do an incremental build of this file, you will get a different error regarding an invocation target exception, where the stack trace indicates that a ProxyEObject is being used. I believe this error will go away once we resolve the NPE, but we probably have another issue where an exception is being caught when it should not be, and the IR cache is becoming corrupted. The following stack trace is thrown: Caused by: java.lang.NullPointerException at org.eclipse.edt.mof.egl.utils.IRUtils.makeExprCompatibleToType(IRUtils.java:437) at org.eclipse.edt.mof.egl.utils.IRUtils.makeCompatible(IRUtils.java:371) at org.eclipse.edt.gen.javascript.templates.AssignmentTemplate.genExpression(AssignmentTemplate.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.edt.mof.codegen.api.TemplateContext.doInvoke(TemplateContext.java:357) ... 147 more
I have fixed this with an update to EGL2MofBase The reason a CCE was thrown when doing an incremental build is because we clear the Part cache on incremental builds. So the testcase is read back from disk. The deserializer creates ProxyObjects for things that it doesnt understand, so the code was blowing up much sooner than on a clean build. On a clean build, the cache is not cleared, so the part created directly by EGL2Mof is used. This contained ProxyElement parts (which implment Member), so it got a bit further and blew up because the type of a ProxyElement is null. The code is fixed so that no proxy element/part will get to the generators for this case now.
This high severity defect was fixed several weeks ago, so I am closing.
