Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DTP » ClassCastException on JDBCView.createSupertableLoader() and JDBCTable.createSupertableLoader()
ClassCastException on JDBCView.createSupertableLoader() and JDBCTable.createSupertableLoader() [message #630974] Tue, 05 October 2010 16:37 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
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 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 495
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 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
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.
>>
>>
Previous Topic:'Can not issue data manipulation statements with executeQuery()' on Execution Plan window
Next Topic:SQL Builder to produce "As"-less alias?
Goto Forum:
  


Current Time: Thu Nov 27 00:46:23 GMT 2014

Powered by FUDForum. Page generated in 0.04739 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software