[
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.
