Hi dev@, hi George,
Am 20.09.2019 um 01:36 schrieb George Stanchev:
Since I was the one that brought up a question about OpenJSSE on the
User Mailing List several weeks ago, just wanted to bring up to your
attention that there are quirks of OpenJSSE that people are discovering.
I was able to get TC85 to run with OpenJSSE but admitting haven’t done
extensive testing. For example this thread [1]. There are also other
projects (such as OkHttp http client) that have ran into specificities
on running with OpenJSSE.
[1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077
(sorry for top posting, Outlook doesn’t make it easy)
I answered on tc-users to your test observations (warnings). IMHO they
are not OpenJSSE related.
Concerning the GH issue, I did not yet see any similar problems, at
least not for TC 9. When using the security manager I added
grant codeBase "file:/path/to/openjsse.jar" {
permission java.security.AllPermission;
};
to catalina.policy and again observed no problems.
My updated patch implementing the ALPN check in the normal compat
classes is here:
http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch
I will now check the unit tests for changed behavior.
What would be interesting to know, is whether Graal supports the ALPN
methods or not, so that I can check/implement the correct behavior of
the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that
currently GraalCompat only overwrites one method from JreCompat whereas
Jre9Compat overwrites all of them.
Regards,
Rainer
*From:*Rémy Maucherat <r...@apache.org>
*Sent:* Thursday, September 19, 2019 5:02 AM
*To:* Tomcat Developers List <dev@tomcat.apache.org>
*Subject:* Re: Better support for OpenJSSE?
On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <ma...@apache.org
<mailto:ma...@apache.org>> wrote:
On 19/09/2019 09:27, Rainer Jung wrote:
<snip/>
> I made a patch to detect ALPN support at runtime using reflection.
> Please have a look. Feedback welcome, whether we want to include
that or
> whether we want to stick with the simpler approach we currently use.
Past experience suggests a lot of users will be on Java 8 for quite some
time. I think it makes sense to support this.
> Of
> course the windows for Java 8 plus OpenJSSE is getting smaller over
> time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On
> the other hand integration of OpenJSSE is pretty simple and some
users
> don't like native code in their JVM (and its maintenance). IMHO
support
> for OpenJSSE (including HTTP/2) would be a nice addition.
>
> My TC 9 patch is available under:
>
> http://home.apache.org/~rjung/patches/tc9-openjsse.patch
>
> It moves the ALPN detection from classes Jre(9)Compat to class TLS in
> the same package and uses the same approach that we use for other
> runtime detection. It needs to make one method accessible,
because under
> Java 9+ the implementation class SSLEngineImpl is no longer a public
> class. Since it is accessed normally via SSLEngine, direct method
calls
> still work, but reflective calls no longer.
Currently TLS.java is only used by the unit tests.
We only need to use reflection on Java 8 since we know ALPN is available
on Java 9 onwards.
The module system adds additional restrictions to calling
setAccessible() that might cause problems in the future.
I was a bit worried about that too.
I wonder if a cleaner solution might be:
- Move isTlsv13Available to TesterSupport and deprecate TLS.java
- Add isAlpnAvailable() to JreCompat where:
- Java 7 (for 8.5.x) hard codes to false
- Java 8 uses reflection
- Java 9 hard codes to true
+1
Personally I wouldn't use OpenJSSE over tomcat-native (performance ?
long term support ?), but since it's only about making the Tomcat code a
bit more flexible that works for me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
