Re: [8]: help on PKCS#11 tests build
On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
IIRC, and in case it wasn't clear from reading the responses, the permission changes are done by the Makefiles (e.g. jdk/test/Makefile:193), and not by JTREG itself. I agree with Jon's comment, perhaps a .dll copy to the temporary working directory is in order. That would save people trying to figure out why their tests are failing when running under a .hg directory with the makefiles, or when using JTREG directly. I'm not sure how many .dlls there are in the test dirs (including closed where most probably live), but should probably be done all together instead of by functional area. Brad On 12/4/2013 10:40 AM, Jonathan Gibbons wrote: It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
There are 6 dlls in the test directory ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll Francis Le 05/12/2013 03:16, Bradford Wetmore a écrit : IIRC, and in case it wasn't clear from reading the responses, the permission changes are done by the Makefiles (e.g. jdk/test/Makefile:193), and not by JTREG itself. I agree with Jon's comment, perhaps a .dll copy to the temporary working directory is in order. That would save people trying to figure out why their tests are failing when running under a .hg directory with the makefiles, or when using JTREG directly. I'm not sure how many .dlls there are in the test dirs (including closed where most probably live), but should probably be done all together instead of by functional area. Brad On 12/4/2013 10:40 AM, Jonathan Gibbons wrote: It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
[8]: help on PKCS#11 tests build
Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
