Community
Participate
Working Groups
Build Identifier: 20110218-0911 any ocl evaluation against the object which extends EObject is failing. problem is in EcoreEvaluationEnvironment.java method : protected Exception checkOperationReflectionConsistency(Object source) { try { source.getClass().getDeclaredMethod( "eInvoke", int.class, EList.class); return null; } catch (NoSuchMethodException e) { return e; } catch (SecurityException e) { throw new IllegalArgumentException(e); } } getDeclaredMethod(..) should be replaced with getMethod(..), overwise every child of EObject will fail here unless it overrides the eInvoke method Reproducible: Always
checkOperationReflectionConsistency is a workaround to give fallback functionality for users who neglect to set OperationReflection true in their genmodel. You can therefore 'workaround' this by setting OperationReflection true. Did you not see the "Override of eInvoke(int,EList) not found for ''{0}'': set ''Operation Reflection'' true and re-genmodel." message? If the code was modified as suggested, no diagnostic for the inappropriate genmodel setting would be issued. (In 3.0.0 you would just have got an unhelpful crash.)
ok, sounds good. but this is not my Object which extends EObject it is from teneo. below is an exception i got. I am not using the genmodel but only ecore. i thought that if you fix the root of the issue then nobody would have it anymore. but i guess if you said it is by design then i have to contact teneo team and remember about this issue next time i extend EObject myself. !MESSAGE Override of eInvoke(int,EList) not found for 'lookup::MyTable': set 'Operation Reflection' true and re-genmodel. !STACK 0 java.lang.NoSuchMethodException: org.eclipse.emf.teneo.hibernate.mapping.SerializableDynamicEObjectImpl.eInvoke(int, org.eclipse.emf.common.util.EList) at java.lang.Class.getDeclaredMethod(Class.java:1937)
The 'root' of the problem is perhaps that GenModel could have a validation rule that if there are any invocation delegates, Operation Reflection could beneficially be true. checkOperationReflectionConsistency was the best we could come up with within the confines of OCL 3.0.1 to warn users what their problem was. 3.0.0 just crashed. It would appear that Teneo has a faulty genModel; raise a Bugzilla. If you can contrive to call EcoreEvaluationEnvironment.setOperationReflectionCheckDisabled(true) you can silence the message, but you will continue to get less efficient fallback dynamic dispatch when direct dispatch could have been genmodelled.
ok, thanks the other work around is just to use custom EcoreEvaluationEnvironment and override the method mentioned before
CLOSED after a year in the RESOLVED state.
