Add new jar file to execute tools/network server with java -jar

• Key: DERBY-1063
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Andrew McIntyre
• Reporter: Andrew McIntyre
• Component/s: Tools
• Affects Version/s: 10.2.1.6
• Fix Version/s: 10.2.1.6

Description

Support execution of the tools with java-jar using the manifest Class-Path attribute. Originally added as part of DERBY-1019, this seeks to reinstate thee functonality that was removed as a result of DERBY-1045. Create a new jar file to execute the tools, along with an improvement to sysinfo to report the location of the jars from which the info properties files are loaded. Note that this does not attempt to mitigate the current problems running sysinfo under a security manager, but to improve the reporting of the locations of the loaded files if they are not loaded from the classpath.

Comments

[Andrew McIntyre]

Attaching patch which combines reinstituting of derbytools.jar's Class-Path attribute, along with an improvement to sysinfo's reporting of the locations of the jar files from which the info properties files have been loaded. Related to DERBY-668, this patch aims to improve the 'regular' output of sysinfo, as opposed to the classpath tester output, or -cp output.

[Daniel John Debrunner]

I'm confused by the description of this issue, auto-loading a driver to me means that the application no longer needs to have this line in their code:

Class.forName(driverName);

Adding a Class-path entry does not auto-load a driver, or load the jar file, it just adds the jar file to the class path.

JDBC 4.0 is adding an auto-load of the JDBC driver which is entered as DERBY-930

[Andrew McIntyre]

Updated summary. Removed 'autoloading' from the summary, since adding the named jars to the classpath doesn't actually load the driver.

[Andrew McIntyre]

Updated patch that moves the java -jar functionality to a new jar called derbycmd.jar, and now includes NetworkServerControl as well.

[Andrew McIntyre]

fixing desciption/summary

[Andrew McIntyre]

Committed revision 384101.

[Andrew McIntyre]

I've committed just the jar creation part of this patch. The sysinfo part of the patch attached as derby1063_v2.diff I intend to refine and submit as a fix for DERBY-826.

[Daniel John Debrunner]

Is there a writeup of the supported syntax for derbyrun.jar?

[Andrew McIntyre]

The javadoc has a list of supported commands, but it looks like I need to tweak the formatting a bit:

http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/tools/run.html

And the usage message you get when you call it with no arguments is better. Just do 'java -jar derbyrun.jar'. I'll add the improved usage from the usage message to run's javadoc as well.

[Daniel John Debrunner]

Thanks, here it is.

java -jar derbyrun.jar ij [-p propertiesfile] [sql script]
java -jar derbyrun.jar sysinfo [-cp ...] [-cp help]
java -jar derbyrun.jar dblook [args] (or no arguments for usage)
java -jar derbyrun.jar NetworkServerControl [args] (or no arguments for usage)

The last one, NetworkServerControl, looks out of place to me, e.g.

java -jar derbyrun.jar NetworkServerControl start

I wonder if it would be more usable if we replaced 'NetworkServerControl' with 'server'.

java -jar derbyrun.jar server start

There is a simpler alternative to starting the network server, already in 10.1 (thanks to Andrew reminding me)

java -jar derbynet.jar start

I think having both is fine, but the purpose of derbyrun is to make it easy, seems 'server' is easier to type than NetworkServerControl .

[Andrew McIntyre]

That's definitely a good idea, less typing is always good, and "server" fits with the other names much better. Another alternative would be "net". That would be sort of similar to the Windows net command and hey, even less typing. That might be a little too abbreviated, though. "servers start" is very descriptive, "net start" not so much.

I'm curious to hear if there are any other suggestions. I'll be glad to make the change when I fix up the javadoc.

[Knut Anders Hatlen]

I think it would be a good idea to add a test case to derbyall, so that we know that jar we are shipping really works.

[Andrew McIntyre]

I've thought a bit about how to test this. It would involve getting the location of the derbyrun.jar by using getResource for org.apache.derby.iapi.tools.run, then forking a JVM to run java -jar for each of the tools launched by the run class, and then capturing the output of the corresponding usage messages. One problem is that, unlike the other tools, ij doesn't have a usage message. We could Process.destroy() the ij instance after creating it, but there's two problems with that: Process.destroy() isn't (or at least, historically hasn't been) very reliable and the version string is included in ij's startup text. The version could be filtered out, I suppose, but the reliability of Process.destroy() is more problematic. I'd rather not leave zombie processes in test environments due to using Runtime.exec(). If ij had a usage message, then it wouldn't be a problem. I could add a usage message to ij, in conjunction with writing such a test.

I'm certainly open to any other good ideas for how to test the run class. Let me know if you have any.

[Knut Anders Hatlen]

You could pass a script with some simple queries to ij. I think ij exits after processing a script.

[Kathey Marsden]

The test derbynet/testij.java does this with the old fashioned ij invocation.

[Andrew McIntyre]

Committed revision 395434 to address comments above. Added a test, but haven't hooked it into a suite yet, because I haven't decided whether to just skip the test if running with jars (in which case I need to make a harness change) or to just make the equivalent calls directly to org.apache.derby.iapi.tools.run.

[Andrew McIntyre]

Committed another patch with revision 395453. Modifies the test to work with both classes and jars, and hooks the test into the derbytools suite. I think this should wrap it up, so closing issue.