You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2008/08/14 17:31:46 UTC
[jira] Created: (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.
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
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.
[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.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (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.
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629154#action_12629154 ]
Kristian Waagan commented on DERBY-3840:
----------------------------------------
Thank you, Kathey.
What I wanted to know about the method, is whether the path is included or not. Your example in the JavaDoc confirms this.
(Nit: Two of the lines have a different indentation than the rest of the JavaDoc).
I just wondered about the system variable for security reasons. Since this is testing code, it doesn't matter I suppose.
I also checked with the Sun VM, and you're allowed to change it there as well. I don't think the VM will use these values internally, but it will report the values set.
> 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.
[jira] Assigned: (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.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-3840:
-------------------------------------
Assignee: Kathey Marsden
> 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
>
> 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.
[jira] Closed: (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.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden closed DERBY-3840.
---------------------------------
Resolution: Fixed
Fix Version/s: 10.5.0.0
> 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
> Fix For: 10.5.0.0
>
> 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.
[jira] Commented: (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.
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628497#action_12628497 ]
Kristian Waagan commented on DERBY-3840:
----------------------------------------
Changes look good to me.
Suggestions for improvement;
- remove the line of blanks
- fix indentation and add JavaDoc for the new method in BaseTestCase
Out of curiosity, do you know if the "com.ibm.oti.vm.exe" property is read-only in the j9 VM?
> 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
>
>
> 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.
[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.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ 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_diff.txt
Attaching a patch for this issue. Added utility method to BaseTestCase to get the executable name and used that where java processes are spawned.
> 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
>
>
> 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.