Sure Xuelei, I read
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization
If I understand correctly, the most settings can be done via
system/security properties. But there may be some other ways like
setDefaultHostnameVerifier(), setDefaultSSLSocketFactory() methods.
My point is that it's better to run tests which don't modify the default
JSSE configuration in agent VM. It would speed up test execution. I
don't think that it's too hard to identify those tests which modify the
default JSSE configuration. and run them in a separate JVM. I believe
most of test are fine now.
I rely on your expertise, and I'll let you decide about it.
Artem
On 08/25/2016 10:45 AM, Xuelei Fan wrote:
On Aug 26, 2016, at 1:33 AM, Artem Smotrakov <artem.smotra...@oracle.com> wrote:
Hi Xuelei,
On 08/25/2016 10:26 AM, Xuelei Fan wrote:
On Aug 26, 2016, at 12:43 AM, Artem Smotrakov <artem.smotra...@oracle.com>
wrote:
Hi Xuelei,
I am not sure why you think it's too strong to follow to it. To me it's pretty
easy to see if a test calls System.setProperty() or Security.setProperty()
methods which modify default JSSE configuration.
Is there any other way to modify default JSSE configuration, so that it can't
be changes then?
Yes.
Could you give an example?
I will give some tomorrow. If you want to make a research by yourself, please
read the jsse reference guides.
And even it can only be set via explicit call to setProperty(), run it in agent
vm is still not safe because we don't know where the set may be used other than
this test case.
Those tests which modify default JSSE configuration should be run in othervm
mode. This way they won't affect any other tests.
"Should" is an assumption,but not the reality. And we do not always make it
right even we want that.
It is not only about this test, the impact need to consider all JDK test
cases in a big picture, which is a huge number and we cannot actually evaluate
so many test cases.
I think we just need to identify all tests that modify default JSSE
configuration, and make them run in othervm mode. I believe that currently most
of them run in othervm mode.
To be safe, all is needed, most is not enough. As I said, too much test case
to make the evaluation and make all right. Reality is reality. I will try to
find some out of the jsse components tomorrow. If you want to do by yourself
you can search https or ocsp or ldaps on all JDK test, it may be able to find
some hints.
Xuelei
Artem
I will reply more details when I have a PC tomorrow.
Xuelei
Artem
On 08/25/2016 12:43 AM, Xuelei Fan wrote:
On 8/25/2016 2:06 PM, Weijun Wang wrote:
I think Artem is correct here.
All those tests that modify static fields should run in othervm mode, so
that *each* runs in its *own* VM. All other tests, which make no such
modifications, can share the *same* VM using agentvm.
It's too strong to follow. And it is not easy to know there is no static
fields update in a test case.
Xuelei
On 8/25/2016 13:31, Xuelei Fan wrote:
On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
Those tests which modify default JSSE parameters should be run in
othervm mode. But other tests which don't do that can be safely run in
agent VM. This test doesn't seem to modify any default JSSE parameter.
If this test get booted, other test that need to do more customization
may not work any more.
For example, boolean variable A is a singleton static field, default is
true. If A get initialized in default mode, it is "true". It is not
possible to customize it to "false" any more in other test in
agentvm/samevm mode.
Shouldn't these "other" tests run in othervm mode?
Or, do you mean that even if a JSSE test does not modify a static field
inside the test, it will modify some through innocent JSSE calls, so no
JSSE test should ever run in agentvm?
I find this unnatural.
Thanks
Max
This test has no impact in agentvm/samevm mode unless no test run in
agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
configuration as this one. This assumption is too strong to follow.
Xuelei
Artem
