RESTEASY-1318: TJWS construct and register java internal JSSE provider if required

[alonbl]

Adding a security provider at runtime should be avoided as it effects
the entire JVM and may effect other efforts.

Constructing com.sun.net.ssl.internal is not part of public API.

This change performs the construction and registration of sun internal
JSSE provider only if SSLContext cannot be established, it solves only
the issue of not constructing and registering JSSE provider if already
available.

Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com

[ronsigal]

Hi Alon,

1. Why does this matter? tjws is just used for Resteasy testing.
2. Have you looked into the netty test failure (https://s3.amazonaws.com/archive.travis-ci.org/jobs/78357698/log.txt)?

-Ron

[alonbl]

@ronsigal: why do you think it is used only for testing? we got this error in our implementation.

I do not see how this test failure is related to this change, I will try to rebase.

[ronsigal]

re: "why do you think it is used only for testing? we got this error in our implementation."

Ah, you're using tjws in production? I didn't know anyone did that.

[alonbl]

@ronsigal: ci is ok, this change will be applied only if there is no ssl implementation what-so-ever, which is a very rare case, when falling back to "manual" injection (left for backward compatibility) the load of the internal sun provide may or may not be in classpath, which is fine.

Example: jboss module does not import the internal sun classes, it can use TLS protocol but cannot load the class directly.

[ronsigal]

Hi Alon,

Ok, looks good. I'm going to ask you for two things:

1. A Resteasy JIRA issue.
2. A test case - I can't see anywhere in Resteasy where Acme.Serve.Serve.Acceptor.SSLAcceptor is used.

Thanks,
Ron

[alonbl]

Hi Ron,

I am sorry, but I do not have access to the environment in which this happened. But again, what happened is that this class was somehow called and modified the system properties to try and load a class that was not set in the jboss module classpath.

A library should not modify the state of the entire jvm, this class is doing that and invalidate settings of the container and other classes.
You can look at the SSLAcceptor static contact, in which it calls an initHandler() that also modifies the jvm setting.

I am unsure what bug should I open... I suggest: "resteasy should not modify jvm context nor attempt to dynamic load any class outside of resteasy package".

What do you think?

Thanks,
Alon

[ronsigal]

1. For the test case, I wouldn't expect much. Just a test in which SSLAcceptor is used without any problems.
2. For the JIRA issue, maybe something more specific, like "SSLAcceptor should add security provider only when none exists", or something like that.

Thanks.

[liweinan]

Let me work on a test case

[liweinan]

I have made some progress on this. I'll try to update the PR next week.