Bugzilla – Full Text Bug Listing
| Summary: | NPE for stateless multiple setting delegate | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> | ||||
| Status: | RESOLVED INVALID | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | erdal.karaca.de | ||||
| Version: | 2.7.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 405065 | ||||||
| Attachments: |
|
||||||
The null argument seems to be a glaring error, but it is circumvented by installing a SettingDelegateFactory that creates BasicSettingDelegate.Stateless instance which ignores the settings/index arguments. The problem arises either through no initialization or late initialization. SettingDelegateFactory registration must occur before the static initialization of the EMF generated classes. Hi Ed, I am not familiar with the OCL integration of EMF and experiencing the same problem. Could you please provide a link to your solution (within the EMF OCL repo) to that NPE? Does the OCL integration need the dynamic feature delegation? Using the reflective option (in genmodel settings) the NPE does not occur but then OCL does not seem to work properly. Thanks! (In reply to Ed Willink from comment #1) > The null argument seems to be a glaring error, but it is circumvented by > installing a SettingDelegateFactory that creates > BasicSettingDelegate.Stateless instance which ignores the settings/index > arguments. > > The problem arises either through no initialization or late initialization. > SettingDelegateFactory registration must occur before the static > initialization of the EMF generated classes. The problem is one of populating the EMF invocation/setting/validation registries as required and in time. The OCL problem arose when an execution path bypassed the initialization. It was fixed by doing the initialization consistently. This Bugzilla and its minimal stack trace is therefore 'interesting' as an example of what goes wrong with bad initialization. If you are not using OCL then the OCL fix is not very interesting to you. You need to understand how you got to org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicGet because something three or four calls earlier should have taken you in a different direction avoiding the setting delegate path. |
Created attachment 236814 [details] Demonstration project Running OCLTest as Java application in the attached project gives Exception in thread "main" java.lang.NullPointerException at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicGet(EStructuralFeatureImpl.java:1710) at lib.impl.BookImpl.getLoans(BookImpl.java:448) at ocl.library.test.OCLTest.main(OCLTest.java:14) Because property loans : Loan[*] { derived volatile } { derivation: library.loans->select(book=self); } is generated as public EList<Loan> getLoans() { return (EList<Loan>)LOANS__ESETTING_DELEGATE.dynamicGet(this, null, 0, true, false); } passing a null where non-null is required. (This long-standing bug has gone undetected because nested OCL delegate activations bypass the setting delegate.)