Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321931 - assert error in JDBCSchemaLoader opening Database Connection while in debug
Summary: assert error in JDBCSchemaLoader opening Database Connection while in debug
Status: RESOLVED FIXED
Alias: None
Product: Data Tools
Classification: Tools
Component: Apache Derby Conn Profile (show other bugs)
Version: 1.8   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 1.8.1   Edit
Assignee: Brian Fitzpatrick CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-05 18:10 EDT by Barry LaFond CLA
Modified: 2010-08-11 13:13 EDT (History)
2 users (show)

See Also:

Attachments
stack trace (3.21 KB, text/plain)
2010-08-05 18:12 EDT, Barry LaFond CLA 		no flags Details
Patch (12.19 KB, patch)
2010-08-05 18:37 EDT, Brian Fitzpatrick CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Barry LaFond CLA 2010-08-05 18:10:29 EDT 
Build Identifier: 3.6.0.v20100427

With the Installed JRE's VM arg set to "-ae" and running in debug, I received consistent errors connecting to DTP database connections and trying to open the DB and view catalogs and other details.

Reproducible: Always

Steps to Reproduce:
1. Set Installed JRE's VM arg set to "-ae"
2. Create DTP connection
3. Try expanding DB connection tree
Comment 1 Barry LaFond CLA 2010-08-05 18:12:00 EDT 
Created attachment 175987 [details]
stack trace
Comment 2 Brian Fitzpatrick CLA 2010-08-05 18:18:44 EDT 
Quick correction - it's actually "-ea" not "-ae"
Comment 3 Brian Fitzpatrick CLA 2010-08-05 18:24:08 EDT 
Discovered some weird stuff while trying to help Barry with this...

With that flag on, it chokes big time on asserts. The one that it's barfing on here is:

assert (catalogObject instanceof Catalog);

And in the case of many of the loader overrides, we're passing a null through to the constructor - and that in turn is causing the breakage. 

If I change the assert to:

assert (catalogObject != null && catalogObject instanceof Catalog);

I get the same thing.

So the best I can figure, we'd need to add an if:

if (catalogObject != null) {
     assert (catalogObject instanceof Catalog);
}

When I do that, the assert error cascades to... the Ingres Table loader... So I'm guessing we'd need to search for any/all overrides to see where we're passing the null object and secure it.
Comment 4 Brian Fitzpatrick CLA 2010-08-05 18:37:55 EDT 
Created attachment 175990 [details]
Patch

This patch seems to do the trick - basically it inserts a "check for null" in before it asserts that the object is an ICatalogObject. It seems to happen in every overloadable catalog loader, so the patch addresses it in each loader.
Comment 5 Brian Fitzpatrick CLA 2010-08-05 18:38:56 EDT 
Brian P and/or Linda, can you guys check to make sure that this works ok? Seems to work fine with Derby, but I don't have any other databases available here at RH...
Comment 6 Brian Payton CLA 2010-08-10 21:59:30 EDT 
Hi Fitz, I applied the patch and connected to DB2 for LUW, DB2 for zOS, and Oracle databases, and I didn't see any problems when I expanded the DSE tree for those DBs.
Comment 7 Brian Fitzpatrick CLA 2010-08-11 09:51:13 EDT 
Thanks Brian P! I'll go ahead and deliver the fix for the next go-round of 1.8.1 builds.
Comment 8 Brian Fitzpatrick CLA 2010-08-11 13:13:58 EDT 
Delivered to o.e.d.c.sqm.core as tag v201008120113