So with Uwe's "If there are license problems…" suggestion below, Solr8 on Java8 would run as today with HTTP1.1 unless you download that external jar, in which case it would be detected and give HTTP/2 with TLS. That is a similar situation as we had with geospatial and JTS. If doable in a non-messy way that sounds like a compromise?
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 30. nov. 2018 kl. 09:39 skrev Uwe Schindler <u...@thetaphi.de>: > > Hi, > > ASF legal replied. The whole thing looks like I expected: > > We may link to the conscrypt library (as it’s ASF2 licensed), but we may not > ship (like Jetty does) our “convenience” binaries with it. > Here is the text: > > Roman Shaposhnik commented on LEGAL-425: > ---------------------------------------- > First of all, Apache Software Foundation is ONLY in business of distributing > source code to public. From that perspective you're fine. > If you would like to keep distributing convenience binaries I suggest you cut > that dependency out. Will that work? > > So I think the best idea is to only support Java 9+, if you want HTTP2 and > TLS. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de <http://www.thetaphi.de/> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> > > From: Uwe Schindler <u...@thetaphi.de> > Sent: Wednesday, November 28, 2018 11:56 AM > To: dev@lucene.apache.org > Subject: RE: Poll: Merge jira/http2 to master branch > > Hi, > > About the bundling of conscrypt.jar in the binary distribution of Apache > Solr, I opened LEGAL-425: > https://issues.apache.org/jira/browse/LEGAL-425 > <https://issues.apache.org/jira/browse/LEGAL-425> > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de <http://www.thetaphi.de/> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> > > From: Uwe Schindler <u...@thetaphi.de <mailto:u...@thetaphi.de>> > Sent: Wednesday, November 28, 2018 11:38 AM > To: dev@lucene.apache.org <mailto:dev@lucene.apache.org> > Subject: RE: Poll: Merge jira/http2 to master branch > > Hi Dat, hi Shawn, > > Thanks for the confirmation! This is what I had in mind (missing ALPN > support). > > IMHO, we should not yet switch away from Java 8 as minimum requirement. With > multi-release JARs we are at the moment perfectly able to handle users with > newer Java versions, but we should still support Java 8 (as its still widely > deployed), although EOL is close. As Redhat, AdoptOpenJDK, and several Linux > distributions still provide support for Java 8 at least for 2 or 3 more > years, I think it’s to early to switch. With recent changes, the support by > Oracle is no longer the way to go, as there are many alternatives. > > My proposal would be to wait until master is branched to “branch_8x” (stays > on Java 8 + MR-JAR support), then change “master” to have Java 11 as minimum > requirement. > > About HTTP2: I have no problem with bundling conscrypt (is it needed for both > Jetty Server and Jetty Client)?, but disable it by default and only register > it in the Java TLS SPI, if Java 8 is used. On Java 9 and later use the > shipped HTTP2 support. My proposal would be to do it with a Multirelease JAR > (this is currently enabled in Lucene already). > > If there are license problems, we can do the following: Disable HTTP2 on Java > 8 completely but provide documentation in the Solr Ref Guide how to enable it > (something like: download conscrypt-uber.jar from maven and save in solr/lib > directory). We can enable it automatically, if class.forName() does not throw > CNFE). Maybe add a sysprop, but that’s not needed. I think enabling conscrypt > is easy with reflection only, or do we need to compile hard against it. From > what I figured out, it’s only used at a few places. > > SolrJ should by default ship without conscyrpt (make it “optional” maven > dependency). If it’s in classpath, enable it. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de <http://www.thetaphi.de/> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> > > From: Đạt Cao Mạnh <caomanhdat...@gmail.com <mailto:caomanhdat...@gmail.com>> > Sent: Wednesday, November 28, 2018 11:01 AM > To: Solr/Lucene Dev <dev@lucene.apache.org <mailto:dev@lucene.apache.org>> > Subject: Re: Poll: Merge jira/http2 to master branch > > Hi, > > I will try to summary all the options here > 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must > stick with HTTP/1.1 > 2. Set Java requirement to 9 and use ALPN implementation of JDK 9 > 3. If users want to use HTTP/2, we will notice about license problem then > download and use Conscrypt library. Of course that we still test the > Conscrypt implementation in tests. > > > On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey <apa...@elyograg.org > <mailto:apa...@elyograg.org>> wrote: >> On 11/27/2018 3:32 AM, Uwe Schindler wrote: >> > I'd like to bring one thing into attention: This library conscrypt is >> > ASF2-licensed, but the JAR files contain binary versions of an OpenSSL >> > fork named BoringSSL. I'd recommend to check the licensing, because >> > OpenSSL licenses are a bit strange (some BSD fork, also ASF2, but some >> > code is still outdated - I am not sure what the fork actually uses). I >> > have the feeling we should include ASF legal department. >> > >> > Nevertheless, I am not 100% sure if conscrypt should really be inclued by >> > default in SolrJ. As SolrJ is a client library for Solr and can be used by >> > external projects, there is the problem of incompatibilities with the >> > native C code included. E.g., if one uses SolrJ with IBM J9 or other Java >> > versions different from openjdk. So I'd be careful. My question is: Do we >> > really need that library. To me it looks like it improves speed only, or >> > is there something that requires its use? >> >> As you might know ... full and proper http/2 support with Java 8 >> requires the conscrypt library. With Java 9 or higher, the >> functionality is provided natively by Java. If I remember right, what >> conscrypt provides that Java 8 lacks is ALPN. >> >> If there are license issues with conscrypt, perhaps it might make sense >> to require a newer major version of Java instead ... but I think that >> upgrading the project's Java requirement to 9, 10, or 11 probably >> requires a wider discussion. Lucene probably has no burning need for it >> right now. I have no idea whether there are language features in Java >> 9+ that we as a group are wanting to use. Another point for >> consideration is that the effective EOL for Java 8 is fast approaching, >> and EOL dates have already come and gone for 9 and 10. >> >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> <mailto:dev-unsubscr...@lucene.apache.org> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> <mailto:dev-h...@lucene.apache.org> > > > -- > Best regards, > Cao Mạnh Đạt > D.O.B : 31-07-1991 > Cell: (+84) 946.328.329 > E-mail: caomanhdat...@gmail.com <mailto:caomanhdat...@gmail.com>
