Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1267770132.1141979685594.JavaMail.jira@ajax>
Date: Fri, 10 Mar 2006 08:34:45 +0000 (GMT)
From: "Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1063) Add new jar file to execute
 tools/network server with java -jar
In-Reply-To: <247311841.1141081238936.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1063?page=comments#action_12369823 ] 

Andrew McIntyre commented on DERBY-1063:
----------------------------------------

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.

> Add new jar file to execute tools/network server with java -jar
> ---------------------------------------------------------------
>
>          Key: DERBY-1063
>          URL: http://issues.apache.org/jira/browse/DERBY-1063
>      Project: Derby
>         Type: Improvement
>   Components: Tools
>     Versions: 10.2.0.0
>     Reporter: Andrew McIntyre
>     Assignee: Andrew McIntyre
>      Fix For: 10.2.0.0
>  Attachments: derby1063.diff, derby1063_v2.diff
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira