Yes, it looks like the classes are loaded from test.classes, here is a
piece of jtr file
CLASSPATH=/home/artem/tools/jtreg/4.1/lib/javatest.jar:/home/artem/tools/jtreg/4.1/lib/jtreg.jar:/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs:/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs
\\
/home/artem/jdk/jdk1.9.0b51/bin/java \\
-Dtest.vm.opts= \\
-Dtest.jdk=/home/artem/jdk/jdk1.9.0b51 \\
-Dtest.timeout.factor=1.0 \\
-Dtest.src.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs
\\
-Dtest.compiler.opts= \\
-Dcompile.jdk=/home/artem/jdk/jdk1.9.0b51 \\
-Dtest.classes=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs
\\
-Dtest.class.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs
\\
-Dtest.java.opts= \\
-Dtest.src=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs
\\
-Dtest.tool.vm.opts= \\
-Djava.security.policy==/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/scratch/policy.expect.ace_new
\\
-Djava.security.manager=default \\
com.sun.javatest.regtest.MainWrapper
/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs/NestedActions.jta
expectACE
I am not sure that it is possible to modify classpath for othervm tests.
http://openjdk.java.net/jtreg/faq.html#question4.2
...
4.2. How do I set the CLASSPATH environment variable for my test?
The harness sets the CLASSPATH for the compile, main, and applet actions
to be the system class path plus the test's source and classes directory.
It is possible to set the classpath for the main/othervm action via the
-classpath option to java. Any other modification of the CLASSPATH must
be done using the shell action.
...
"@run main/othervm -classpath ..." doesn't seem to work because it can't
find com.sun.javatest.regtest.MainWrapper
The tests can be updated to start a new process with ProcessTools, or
use a script.
Artem
On 03/18/2015 12:43 PM, Wang Weijun wrote:
Honestly, writing a shell script test would be much cleaner, although it does
not have the same performance as a Java test.
Copying Jon, there should be cases where a script should be preferred.
--Max
On Mar 18, 2015, at 17:39, Wang Weijun <weijun.w...@oracle.com> wrote:
It looks like the classes are loaded from test.classes since there is nowhere setting
classpath to those jars. Maybe you cannot rely on "@run main".
--Max
On Mar 18, 2015, at 17:21, Artem Smotrakov <artem.smotra...@oracle.com> wrote:
Hi Max,
Thank you for the review, it really helped to simplify the tests. I combined
your suggestions, please take a look:
http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/
Artem
On 03/17/2015 12:39 PM, Wang Weijun wrote:
Hi Artem
The tests are good but I am thinking if we can simplify them.
There are too many duplicate actions here, for example, packing the same
classes again and again to the same jar file, and the 4 ***Test.java files are
quite similar. Is it possible to create a single Test.java to do everything in
a single main()?
Is it possible to convert javac calls to @compile or @build? Is it possible to
convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of
using jar files is it possible to put the classes into different
sub-directories and point classpath to them? Is it possible to convert java
calls to @run?
Finally, you create a new nested directory. Is it because there is already a
"doAs" there? I'd rather see a doAs2 containing these new tests. The new
Utils.java can also be put inside this directory.
BTW, the auth.policy file was so old and I wonder if we still need to test it.
Thanks
Max
On Mar 16, 2015, at 18:47, Artem Smotrakov <artem.smotra...@oracle.com> wrote:
Hello,
Please review a couple of new tests for privilege checks on Subject.doAs().
https://bugs.openjdk.java.net/browse/JDK-8048147
http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/
Artem
