Cannot revise JDBC driver Jar version

[ChrisWolf]

I am working with an experimental JDBC driver. At first, it was cause
lots of exceptions, so I downloaded the source for Power Architect and
Sqlpower Library and built from scratch (in Eclipse). After doing
this, I fixed the bugs in the driver I'm working on a was able to
reverse engineer and diagram the db objects.

The problem is when I then invoke the distribution version of Power
Architect (the exe version for Windows), and re-configure the JDBC
driver to use the new Jar file - it acts as though it's using the
original driver code (before the many changes I made). I tried
uninstalling and re-installing - same issue. Meanwhile, if I use my
dev build of Power Architect - it seems to pick up the latest jar,
unlike the installer version of Power Architect.

Is there some sort of persistent class file caching of the driver
classes? I am totally baffled by this issue.

[thomas]

Hi Chris,

SQL Power Architect does make use of a file stored in your home
directory named pl.ini. The pl.ini file stores all of your connection
information and configuration of the drivers. In the past we have had
issues where the pl.ini file was not updating when the user changed
the file in the UI. (There is a bug number for this but our bug
tracker is currently down.) The file location can be checked by
starting up SQL Power Architect and opening the preferences, it is in
the general tab. If you delete the pl.ini file and start SQL Power
Architect it will ask to make a new pl.ini file for you and it will
only have the default drivers configured as when it was first
installed.

If you don't mind me asking what database is the driver you are
working on for? It's always interesting to find a new database that
SQL Power Architect can work with without needing any changes to the
code.

Thomas

[Chris Wolf]

Thomas,

Thanks for the reply.  I am aware of this file and have verified that it is updating properly, as well as the fact that the new jar file name appears when I look in the JDBC Driver manager. 

So can you tell me that JDBC driver class files are not being cached in some kind of persistent store?  That's what it's acting like.

I am trying to be able to reverse-engineer saleforce.com objects via a metadata driver which represents the salesforce data model as JDBC metadata:

http://code.google.com/p/force-metadata-jdbc-driver/

(the code on this site definitely won't work in Power Architect - I have working code)

It actually totally works when I run it from within my developer build of Power Architect, but the installer version keeps functioning as if it still has the original, unfixed version of force-metadata.  The original, buggy, jar was named:

"file:/D:/jlib/force-metadata-jdbc-driver-2.1.p1.jar", but I got rid of that and now it's:
"file:/D:/jlib/force-metadata-jdbc-driver-2.1.p2.jar" - which the attached log file shows is being used, however, the displayed results are only possible as it was using the first (old) jar file - that's why I keep thinking that somehow the driver classes are being persistently cached.


Currently, there are not many, if any, options for creating ERD diagrams for Salesforce, so this would be a great tool for this community.

Thanks,

Chris Wolf

--
You received this message because you are subscribed to the Google Groups "Architect Developers" group.
To post to this group, send email to architect-...@googlegroups.com.
To unsubscribe from this group, send email to architect-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/architect-developers?hl=en.

[thomas]

Hi Chris,

I took a quick look at the log file and it does seem to only be
reading the new jar file. The only place we are storing the driver
locations is in the pl.ini file so I am not sure why it would not be
using your new driver code.

From the logs I can see the "JDBC JAR Count" as 1 and the "JDBC
JAR_0" value set to your driver. If this was the old bug of the pl.ini
not updating correctly I would expect a higher jar count.

Another thought is are both the installed version and the version
running out of Eclipse pointing to the same pl.ini file? If they
aren't you could check if there is a difference in the JDBC
specification in the files. (The pl.ini files are just text files so
you can open them with your text editor of choice.)

Thomas O'Brien

>  pa.log.zip
> 352KViewDownload

[Chris Wolf]

They both use the default location - I'll try configuring separate init files.  On a slightly different topic - how difficult would it be to enhance the JDBC Drivers panel to accept directories in addition to just Jar files?

Thanks again,


Chris Wolf

[Chris Wolf]

Thomas,

I tried reconfiguring an alternative pl.ini location and then uninstalled Power Architect and re-installed on a different partition - same results it's using the old driver code even after I deleted the old Jar file.  On the other hand, I gave the new driver jar to another end-user and they successfully updated the driver and can make ER diagrams for Salesforce.

I guess it's something in my environment.  I wish you would be able to positively confirm that there is no driver class file persistence going on; and I'm not referring to the pl.ini file - I'm referring to the actual driver byte code.

Thanks,

Chris

P.S. I guess, for me, I'll have to just run Power Architect from Eclipse until I somehow resolve the issue.

[thomas]

Hi Chris,

If you want to dig into how the driver gets loaded there are a few
things you can check out. All of the following files are in the
library. The first file is the PlDotIni file which reads the pl.ini
file. When reading the file, with read(InputStream), it will make a
bunch of JDBCDataSourceType files. In the constructor it calls
getClassLoaderFromCache() which makes a new JDBCClassLoader object.
The JDBCClassLoader object is what does the loading of the JDBC driver
for the different connections.

Hope that helps,

Thomas O'Brien

[Chris Wolf]

Thanks - I started to see those classes by debugging and looking at the log.  As for my suspicions about stuff getting persisted - I was partly correct.  On Windows, some preferences are persisted to the registry.  Thus, I tried deleting the whole "ca.sqlpower" registry key and re-started - it STILL is finding the old driver classes somewhere...

0        [AWT-EventQueue-0] INFO  ca.sqlpower.architect.ArchitectUtils  - Log4J configured successfully
16       [AWT-EventQueue-0] DEBUG ca.sqlpower.architect.CoreUserSettings  - loading UserSettings from java.util.prefs.
18       [AWT-EventQueue-0] DEBUG ca.sqlpower.architect.CoreUserSettings  - Preferences class = class java.util.prefs.WindowsPreferences
439      [AWT-EventQueue-0] INFO  ca.sqlpower.sql.PlDotIni  - Beginning to read/merge new pl.ini data
585      [AWT-EventQueue-0] INFO  ca.sqlpower.sql.PlDotIni  - Finished reading file.
587      [AWT-EventQueue-0] INFO  ca.sqlpower.sql.PlDotIni  - Beginning to read/merge new pl.ini data
709      [AWT-EventQueue-0] INFO  ca.sqlpower.sql.PlDotIni  - Finished reading file.
6952     [PokeDB: dev3] INFO  ca.sqlpower.sql.JDBCDataSource  - Driver Class com.claimvantage.force.jdbc.ForceMetaDataDriver loaded without exception
21385    [AWT-EventQueue-0] DEBUG ca.sqlpower.architect.CoreUserSettings  - Saving user settings to java.util.prefs

[Jonathan Fuerth]

Hi Chris,

I'll bet that your force-metadata-jdbc-driver-2.1.p2.jar file was inadvertently overwritten with the contents of the original salesforce jar.

I can confirm that the class files themselves don't get cached by the JDBC classloader in SQL Power Library. To prove that to yourself, try deleting or renaming both force-metadata-jdbc-driver-2.1.p1.jar and force-metadata-jdbc-driver-2.1.p2.jar. You should find that your data source stops working in the packaged version of Power Architect that you downloaded (I'd expect a ClassNotFoundException).

BUT I bet you will continue to see it working inside eclipse. My guess is that you added the Salesforce JDBC driver project as a project dependency on either power-architect or sqlpower-library early on while setting everything up in eclipse. If you diff the .classpath files in each project versus what's in the upstream repository, you should find the culprit there.

Hope that helps!

Jonathan