| ClassCastException on JDBCView.createSupertableLoader() and JDBCTable.createSupertableLoader() [message #630974] |
Tue, 05 October 2010 16:37  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi everyone,
we've recently started using due to its capability to offer a EMF model
representation out of a Database. That allows us to extract that
information and transform it into our OMG KDM representation. It saved
us a lot of trouble, so kudos to the folks behind this great project :)
After some work I've experienced some issues I would like to share here,
just to understand if there is a bug going on here, or if we are messing
up with the code :P
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.loa ders.SQL2005TableLoader
cannot be cast to
org.eclipse.datatools.connectivity.sqm.loader.JDBCTableSuper TableLoader
at
org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.createSupertableLoader(JDBCView.java:200)
at
org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertableLoader(JDBCView.java:209)
at
org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.loadSupertable(JDBCView.java:216)
at
org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertable(JDBCView.java:186)
at
org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.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(XMLS aveImpl.java:1232)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XML SaveImpl.java:2667)
at
org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects(X MISaveImpl.java:90)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveI mpl.java:592)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl. java:256)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLRes ourceImpl.java:206)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.java:1406)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.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?
if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader)) {
Hope to be clear :P
Cheers,
Víctor.
|
|
|
| Re: ClassCastException on JDBCView.createSupertableLoader() and JDBCTable.createSupertableLoader() [message #631217 is a reply to message #630974] |
Wed, 06 October 2010 15:11  |
Brian Fitzpatrick
Messages: 500
Registered: July 2009 |
Senior Member |
|
|
Hey Victor...
I doubt that you're messing up with the code. The table loader framework
has had a few issues over the last few years in this area. I don't
recall seeing this particular issue with the super table loaders however.
Your suggestion however makes a lot of sense -
> if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader))
Please go ahead and create a BZ for this and we'll get this fixed in the
1.8.2 stream (which is also being built for Indigo).
--Fitz
Victor Roldan Betancort wrote:
> Hi everyone,
>
> we've recently started using due to its capability to offer a EMF model
> representation out of a Database. That allows us to extract that
> information and transform it into our OMG KDM representation. It saved
> us a lot of trouble, so kudos to the folks behind this great project :)
>
> After some work I've experienced some issues I would like to share here,
> just to understand if there is a bug going on here, or if we are messing
> up with the code :P
>
> 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.loa ders.SQL2005TableLoader
> cannot be cast to
> org.eclipse.datatools.connectivity.sqm.loader.JDBCTableSuper TableLoader
> at
> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.createSupertableLoader(JDBCView.java:200)
>
> at
> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertableLoader(JDBCView.java:209)
>
> at
> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.loadSupertable(JDBCView.java:216)
>
> at
> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertable(JDBCView.java:186)
>
> at
> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.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(XMLS aveImpl.java:1232)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XML SaveImpl.java:2667)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects(X MISaveImpl.java:90)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveI mpl.java:592)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl. java:256)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLRes ourceImpl.java:206)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.java:1406)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.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?
>
> if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader)) {
>
>
> Hope to be clear :P
>
> Cheers,
> Víctor.
>
>
|
|
|
| Re: ClassCastException on JDBCView.createSupertableLoader() and JDBCTable.createSupertableLoader() [message #631641 is a reply to message #631217] |
Fri, 08 October 2010 09:49 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Brian,
sorry for the late response, I've been a few days.
I created a bugzilla and provided the suggested patch.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327314
Thanks for your support,
Víctor.
On 06/10/10 16:11, Brian Fitzpatrick wrote:
> Hey Victor...
>
> I doubt that you're messing up with the code. The table loader framework
> has had a few issues over the last few years in this area. I don't
> recall seeing this particular issue with the super table loaders however.
>
> Your suggestion however makes a lot of sense -
>
> > if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader))
>
> Please go ahead and create a BZ for this and we'll get this fixed in the
> 1.8.2 stream (which is also being built for Indigo).
>
> --Fitz
>
> Victor Roldan Betancort wrote:
>> Hi everyone,
>>
>> we've recently started using due to its capability to offer a EMF
>> model representation out of a Database. That allows us to extract that
>> information and transform it into our OMG KDM representation. It saved
>> us a lot of trouble, so kudos to the folks behind this great project :)
>>
>> After some work I've experienced some issues I would like to share
>> here, just to understand if there is a bug going on here, or if we are
>> messing up with the code :P
>>
>> 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.loa ders.SQL2005TableLoader
>> cannot be cast to
>> org.eclipse.datatools.connectivity.sqm.loader.JDBCTableSuper TableLoader
>> at
>> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.createSupertableLoader(JDBCView.java:200)
>>
>> at
>> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertableLoader(JDBCView.java:209)
>>
>> at
>> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.loadSupertable(JDBCView.java:216)
>>
>> at
>> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.getSupertable(JDBCView.java:186)
>>
>> at
>> org.eclipse.datatools.connectivity.sqm.core.rte.jdbc.JDBCVie w.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(XMLS aveImpl.java:1232)
>>
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XML SaveImpl.java:2667)
>>
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects(X MISaveImpl.java:90)
>>
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveI mpl.java:592)
>> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl. java:256)
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLRes ourceImpl.java:206)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.java:1406)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(Resour ceImpl.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?
>>
>> if ((loader != null) && (loader instanceof JDBCTableSuperTableLoader)) {
>>
>>
>> Hope to be clear :P
>>
>> Cheers,
>> Víctor.
>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.02852 seconds
] 
Search
Help
Register
Login
Home
