The test can also report which providers it is testing and/or skipping,
so that anyone checking the .jtr file can verify the behavior.
Maybe it fails if expected modules or providers are not found.
-- Jon
On 06/29/2016 10:50 AM, Mandy Chung wrote:
Valerie’s suggestion is a good one. The test will require a minimum image with
cross-platform security providers to run the test while it can still verify
other platform-specific providers.
Mandy
On Jun 29, 2016, at 10:41 AM, Valerie Peng <valerie.p...@oracle.com> wrote:
It's not like the test silently passes as the test still covers the
cross-platform modules.
The way I view this is that the platform=specific modules are "optional" and we
update the expected result by detecting their presence (or the not). It's not a hack or
workaround, but rather an enhancement for the test to handle different images.
Just my .02,
Valerie
On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote:
On Jun 28, 2016, at 5:22 PM, Valerie Peng <valerie.p...@oracle.com> wrote:
One of the purpose of this test is to test the ordering (see the initial bug
which this test is for: JDK-6997010).
The original test already detects the OS and will skip certain providers
accordingly.
Instead of splitting the test into multiple platform-specific tests, maybe we
can keep the original test but add module-presence checking? Is there API
available to query if certain module are present?
ModuleFinder.ofSystem().find(String).
We can have only the cross-platform modules listed in @modules and make the
test to pass silently if the required platform-specific modules are not present.
So, for example, on windows, if the test would be executed against an image
which have no jdk.crypto.mscapi, the test will not run any checks and report
pass.
This would help to avoid the additional test creation, but it will add another
silently passing test, which is less clean.
Mandy?
Shura
If yes, then we can leave out the platform-specific providers from the @modules
line and skip the providers if either the OS does not match or the module is
not present.
If we can't query what modules are available, then we may have to think of
something else.
Valerie
On 6/27/2016 12:27 PM, Mandy Chung wrote:
I’m including security-dev which would be a better list to review this test fix.
Valerie,
Does this test have to be order-sensitive? I think this test would be
cleaner to make it order-insensitive and simply test the security provider
initialization.
See my comments below.
On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline
<alexandre.il...@oracle.com> wrote:
Hi.
Please take a look on a suggested for for the
java/lang/SecurityManager/CheckSecurityProvider.java test.
The test in question depend on a list of modules, some of them are
platform-specific. Listing all the dependencies in one test is causing the test
to be skipped on every platform. In an offline conversation it was decided that
it is better to split this tests into a few tests to declare the per-platform
module dependencies.
The bug: https://bugs.openjdk.java.net/browse/JDK-8158670
The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/
The copyright header start year of the new tests should be 2016.
I would suggest to make CheckSecurityProvide a platform-neutral test, i.e.,
- drop @requires
- make line 94-97 to ignore the platform-dependent provider if it’s present in
the white list
If we could make this test order-insensitive, it’d be cleaner to maintain a
platform-neutral list of security providers and one list for the
platform-dependent security providers for each platform. Just an idea.
Mandy
