Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <613898260.1220636324372.JavaMail.jira@brutus>
Date: Fri, 5 Sep 2008 10:38:44 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3840) The test code executes java processes
 by just executing java instead of using a full path. This may cause the
 wrong java to be picked up.
In-Reply-To: <1019721108.1218727906207.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-3840:
----------------------------------

    Attachment: DERBY-3840_diff2.txt

Thanks for looking at the patch.

Here is an updated patch with the javadoc.  It does not appear that the  com.ibm.oti.vm.exe property is read only. I can set it to something else on the command line and it will change.


> The test code executes java processes by just executing java instead of using a full path. This may cause the wrong java to be picked up.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3840
>                 URL: https://issues.apache.org/jira/browse/DERBY-3840
>             Project: Derby
>          Issue Type: Bug
>          Components: Newcomer, Test
>    Affects Versions: 10.5.0.0
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>         Attachments: DERBY-3840_diff.txt, DERBY-3840_diff2.txt
>
>
> There are places in the code where we execute a java process. e.g.  BaseTestCase.assertExecJavaCmdAsExpected where we execcute a java process and just call "java".  In windows at least the new shell created for the exec'ed process does not share the parent process path but rather picks up the path from the Windows System variables.  This can cause the wrong java to be picked up.  Also the method does not work for j9 because it calls "java" instead of the actual executable name.  Perhaps we should have a method:
>     public static final String getJavaExecutableName() {
> 	    String vmname = getSystemProperty("com.ibm.oti.vm.exe");
> 	    if (vmname == null)
> 	        vmname = getSystemProperty("java.home") + File.pathSeparator + "java";
> 	    return vmname;
> 	}
> There are also issues with this in NetworkServerControlApiTest.  NetworkServerTestSetup and the replication tests and maybe others as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.