Bugzilla – Full Text Bug Listing
| Summary: | ClassCastException in JDBCView.createSupertableLoader() & JDBCTable.createSupertableLoader() | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Data Tools | Reporter: | Victor Roldan Betancort <vroldanbet> | ||||
| Component: | Connectivity | Assignee: | Brian Fitzpatrick <bfitzpat> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | vroldanbet | ||||
| Version: | 1.8.2 | ||||||
| Target Milestone: | 1.8.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 180480 [details]
patch v1
this adds a check to the if clause to avoid the ClassCastException:
if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader)) {
JDBCTableSuperTableLoader tableSuperTableLoader = (JDBCTableSuperTableLoader) loader;
tableSuperTableLoader.setCatalogObject(this);
return tableSuperTableLoader;
}
If the loader is not of type JDBCTableSuperTableLoader, a new instance will be created at the end of the method.
1) The number of lines that you changed is smaller than 250. confirmed. 2) You are the only author of these changed lines. confirmed. 3) You apply the EPL to these changed lines. confirmed. Thanks for the patch. We'll try and get this into the 1.8.2 (head) stream so it flows into 1.9 as well. Delivered to o.e.d.connectivity.sqm.core as tag v201010090204. Thanks for the assistance! |
Copied from the newsgroup: "Apparently, there seem some assumptions in the code responsible to create SuperTable loaders for both JDBCView and JDBCTable. There is a method in both classes, called "createSupertableLoader()", which assumes that database enablement contributors create TableLoaders extending JDBCTableSuperTableLoader. It leads to ClassCastException. I have only tested with SQL Server, but very likely would happen with other enablement contributions, as no other plugin overrides Table nor View using JDBCTableSuperTableLoader, but instead providing classes that extend JDBCTableLoader. java.lang.ClassCastException: org.eclipse.datatools.enablement.msft.internal.sqlserver.loaders.SQL2005TableLoader cannot be cast to org.eclipse.datatools.connectivity.sqm.loader.JDBCTableSuperTableLoader at org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCView.createSupertableLoader(JDBCView.java:200) at org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCView.getSupertableLoader(JDBCView.java:209) at org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCView.loadSupertable(JDBCView.java:216) at org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCView.getSupertable(JDBCView.java:186) at org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCView.eIsSet(JDBCView.java:233) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.shouldSaveFeature(XMLSaveImpl.java:1194) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1232) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2667) at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects(XMISaveImpl.java:90) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:592) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:256) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:206) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1406) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993) at ... The portion of code that leads to this exception: if (loader != null) { JDBCTableSuperTableLoader tableSuperTableLoader = (JDBCTableSuperTableLoader) loader; tableSuperTableLoader.setCatalogObject(this); return tableSuperTableLoader; } I managed to reproduce this exception when calling ResourceUtil.resolveDanglingReferences(), which is an internal method that seems to resolve the containment peculiarities of the SQL model for those interested on persisting the model in a Resource. So the framework expects enablement to contribute instances of JDBCTableSuperTableLoader, but extenders don't do that. Should there be at least a check in the if clause to avoid the ClassCastException?"