DriverPath and LoadJDBCJars

[npetzall]

-dp takes a string, it can be either a single lib or list of libs separated by File.pathSeparator.

There is an option -loadjars which will load sibling libs, however this only works when -dp is set to a single lib.

I would propose that driver path (-dp) can be used with:

• Single library: just load that file
• List of paths to libraries: load only these files/directories
• Directory: load all libraries in that directory

and thus remove the -loadjars option from command-line

A tiny hack would be that -loadjars only operate on the first lib found in -dp

[aadrian]

http://www.jcommander.org/#_lists
or
http://www.jcommander.org/#list-value

[npetzall]

I updated the issue and jcommander doesnt solve the issue. But that might be because I was unclear about the issue.

[rafalkasa]

@npetzall -loadjars parameter was added to the SchemaSpy to resolve issue with Cloudera Impala JDBC driver. You cna read more here - Support for Impala #64

Now -loadjars is loading only additional drivers that are in the same folder where JDBC driver it is, nothing more nothing less.

Based on my understanding you would like to extend -dp functionality in a little different manner for other purposes to cover other JDBC cases similar to Cloudera Impala.

I will try to thnik about this change and maybe we can improve this a little

[npetzall]

Impala wouldn't actually need a loadjars since the jars could have been specified.
Jar1:Jar2:Jar3 etc etc.

So having -loadjars which is incompatible with the above seems complex.

I'll have another look at it tonight.

[npetzall]

-dp

Allows to specify driverjar and additional jars
format:
lib/one.jar
or
lib/one.jar:lib/two.jar:lib/three.jar

-loadjars

Allow to specify driverjar and it will load all jars in same folder (now it actually loads .?ar(jar,war,nar etc)
However it puts constraint on -dp path it can not be in de second form:
lib/one.jar:lib/two.jar,lib/three.jar

The proposed solution with a small twist.
-dp would allow specific jar, list of jars lib/one.jar:lib/two.jar:lib/three.jar:lib/anyOtherTypeOfFile
and even list of directories lib:ext-lib.

If -dp element is a directory it will include all .?ar file and even the directory to the classpath of driver loading.

So instead of listing jars or even a single jar and adding -loadjars true, it would load them.

Everything above would just be: -dp lib

[rafalkasa]

@npetzall thank you for detailed explanation and description. I fully agree with you that it will be much easier for SchemaSpy users to have only one parameter -dp and few specyfic option how to load the driver or additional files related to it.

I would like to start working on this enhancement after when I will merge changes made by @Riggs333 to the Config class with new JCommander added to the project.

[npetzall]

@rafalkasa this can be done right now, the change is local to DbDriverLoader. You can leave the -loadjars option and it can be removed after his PR. DbDriverLoader will just stop using loadjars flag.

[npetzall]

@rafalkasa Ok if i grab this one?

[rafalkasa]

Yes sure you can grab this one, I'm more than happy that you have energy and time to working on SchemaSpy

[npetzall]

I haven't verified order since it hasn't been an issue.
We need to talk about classloaders and not classpaths.

When the driver is loaded we create a new classloaders if -dp has resulted in existing path(s).
This classloaders uses the classloaders of schemaspy as it's parent classloaders so they are chained.

I did a quick look in Class.java and sadly it's a native call. But what I've heard about classloading is that it checks the parent first. Child first is normally found in applicationservers like tomcat to avoid static classes to be shared between applications.

So there is no requirement to use dp or that it needs to point at a file not on classpaths.

This fact is used in the docker image which doesn't use -dp but classpath.

So if order is truly important I can verify it.
Any change in order would require a use-case just so that we can implement it as a test, describing why we want that behavior.