Community
Participate
Working Groups
An adopter product is getting a class cast exception on a few scenarios where the wrong EMF2DOM Adapter is retrieved.. Exception follows: !ENTRY org.eclipse.wst.sse.core 4 4 2010-06-17 09:17:44.500 !MESSAGE A structured model client, EMF2DOMSSEAdapter(web-app,WebAppImpl) threw following exception during adapter notification (STRUCTURE_CHANGED ) !STACK 0 java.lang.ClassCastException: org.eclipse.jst.javaee.web.internal.impl. ServletImpl incompatible with org.eclipse.jst.j2ee.webapplication.WebTy pe at org.eclipse.jst.j2ee.webapplication.internal. impl.ServletImpl.eSet(ServletImpl.java:49 6) at org.eclipse.emf.ecore.impl.BasicEObjectImpl. eSet(BasicEObjectImpl.java:1081) ; at org.eclipse.wst.common.internal.emf.utilities. ExtendedEcoreUtil.eSetOrAdd(ExtendedEcoreUtil. java:79) at org.eclipse.wst.common.internal.emf.resource. Translator.setMOFValue(Translator.java:62 0) at org.eclipse.wst.common.internal.emf.resource. Translator.setMOFValue(Translator.java:63 5) at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.primUpdateMOFFeature(E MF2DOMAdapterImpl.java:1497) &nb sp; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.updateMOFFeature(EMF2D OMAdapterImpl.java:1840) & nbsp; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.primUpdateMOF(EMF2DOMAdapterImpl. java:993) at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.updateMOF(EMF2DOMAdapterImpl. java:973) at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.primUpdateMOFMultiFeat ure(EMF2DOMAdapterImpl.java:482) ; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.primUpdateMOFMultiFeat ure(EMF2DOMAdapterImpl.java:1553) &nbs p; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.updateMOFMultiFeature( EMF2DOMAdapterImpl.java:1767) &n bsp; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.updateMOFFeature(EMF2D OMAdapterImpl.java:1822) & nbsp; at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.primUpdateMOF(EMF2DOMAdapterImpl. java:993) at org.eclipse.wst.common.internal.emf.resource. EMF2DOMAdapterImpl.updateMOF(EMF2DOMAdapterImpl. java:973) at org.eclipse.wst.xml.core.internal.emf2xml. EMF2DOMSSEAdapter.notifyChanged(EMF2DOMSSEAdapter. java:230) at org.eclipse.wst.sse.core.internal.provisional. AbstractNotifier.notify(AbstractNotifier. java:202) at org.eclipse.wst.xml.core.internal.document. XMLModelNotifierImpl.notifyStructureChang
Created attachment 174368 [details] patch In rare cases the wrong adapter was being chosen from the list of adapters. I found a way to pass the correct translator instance that ensures the right translator is used. a new method was needed to pass the translator
Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Exceptions thrown when two models are listening to the same xml model. And a series of events cause adapters to be in wrong order. Algorithm in place didn't have enough information in hand to make correct decision. Is there a work-around? If so, why do you believe the work-around is insufficient? No - exception will be thrown How has the fix been tested? Junits run Give a brief technical overview. Who has reviewed this fix? The case where this is failing.. the adapters "translator" instance is known, and now passed, and an equality check ensures the right adapter is chosen. Carl reviewed the patch What is the risk associated with this fix? Low risk - Only rare path has been altered, and now can intelligently make decision.
I approve of this patch.
changing this code sounds risky, since "deep" code, used indirectly all the time ... so please test well ... but I'm assuming the only thing that's changed from previous method is the last if-clause that uses 'childMap' ... so should be rare that the new code path is executed. (right?) Thanks,
Wow - I just moved this to Source Editing (once I realized that this was in EMF2DOMSSEAdapter and not Common's EMF2DOMAdapter), and it did weird things with the flags. I am clearing them all out.
David Williams and Tim deBoer had approved this at a PMC level... but we need the proper project lead's review, so I am marking this for Nitin's review.
I am restoring my review flag.
Approving, since there's nothing new obviously wrong. I'd still like to understand why there are multiple adapters that respond to the same adapter key on Nodes.
Released to 3.2.1.
