On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
> 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. > Graal still only does Java 8 at the moment :) So no ALPN, but OTOH Java 8 doesn't otherwise cause too many problems. Graal works with tomcat-native/OpenSSL and HTTP/2 works fine there. Rémy > > 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 > >
