On 11/21/2013 04:53 AM, Chris Hegarty wrote:
If I am correct, JTREG has support provider cleanup already. But the
question is even JTREG reset the providers, it still cannot ensure next
test won't be impacted because in some circumstances JDK may need to
cache something which depends on previous providers. Still need to
analysis the test case by case.
Right, any static or cached data may be invalid, and this will require
careful changes to the JRE itself.
Pardon my ignorance - if I gather correctly then ProvidersSnapshot
library also doesn't sandbox effects completely.
FYI. I am not part of the security team, and someone from the security
group should ultimately have to agree/disagree, but we have similar
issues in other parts of the platform. I don't know the specifics of the
code here so it may, or may not, be an issue.
If any part of the security framework stores values in static fields,
that is dependent on the security providers, then when the providers
change this static value may be incorrect.
We encounter this from time to time with system properties. E.g. JDK
HTTP Client code reads system property and stores in static field, JDK
HTTP Client will never never re-read the property as it believes it will
not change. Having jtreg reset/clean certain system properties will not
help in this case.
Yes, the example with system properties is a good one.
However, providers are designed to be added and removed dynamically (see
the java.security.Security API), so if there is some static information
not being cleared when providers are reset, I would tend to think it may
be a bug in the JDK.
My preference would be change jtreg to clear/restore providers, and more
thoroughly analyze any subsequent test failures as it may be a bug in
the JDK.
--Sean
