I've been doing some work to enable the HTTP/2 support in jetty for usage
within the Felix Http Jetty 4.x bundle for an apache sling based project.

I'm not sure about the history of the felix.http.jetty bundle, but can I
ask why it was decided to make copies of the jetty classes inside the felix
bundle rather than just depending on the already existing jetty bundles and
then provisioning the jetty-* bundles to the OSGi profile to provide those
classes?

The reason I ask is that the jetty implementation is still utilizing the
java.util.ServiceLoader mechanism in a few places and the packaging of the
felix.http.jetty bundle is not copying the META-INF/services/* files or
merging the related "osgi.serviceloader" Require-Capability and
Provide-Capability attributes from the manifest of the embedded jetty-*
bundles when it is repackaged.  This makes it so the ServiceLoader code is
unable to discover the services provided by the jetty-http and the
jetty-alpn-* bundles and the jetty HTTP/2 related code fails.

In other words, using the jetty-* bundles has everything packaged and
declared correctly to utilize the OSGi ServiceLoader mediator patterns, but
the felix.http.jetty bundle is missing some of the critical details.  Also,
by using the jetty bundles directly, the jetty and felix bundles could
evolve at their own pace and felix would not have to re-release a new
version of the felix.http.jetty bundle every time a new jetty version gets
released.

I have proven locally that the above scenario works and have gotten the
jetty HTTP/2 support to work locally by refactoring to make a "thin"
version of the felix.http.jetty bundle that doesn't have a copy of the
jetty classes inside of it and then provision the following bundles to the
OSGi profile:

# "thin" felix http jetty without the jetty classes embedded
org.apache.felix/org.apache.felix.http.jetty/4.0.3-SNAPSHOT

# additional bundles to enable OSGi ServiceLoader mediator support
org.ow2.asm/asm-all/5.2
org.apache.aries/org.apache.aries.util/1.1.3
org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.0.12

# Jetty bundles
org.eclipse.jetty/jetty-servlet/9.4.11.v20180605
org.eclipse.jetty/jetty-server/9.4.11.v20180605
org.eclipse.jetty/jetty-http/9.4.11.v20180605
org.eclipse.jetty/jetty-io/9.4.11.v20180605
org.eclipse.jetty/jetty-util/9.4.11.v20180605
org.eclipse.jetty/jetty-jmx/9.4.11.v20180605
org.eclipse.jetty/jetty-security/9.4.11.v20180605
org.eclipse.jetty/jetty-webapp/9.4.11.v20180605
org.eclipse.jetty/jetty-xml/9.4.11.v20180605
org.eclipse.jetty.websocket/websocket-servlet/9.4.11.v20180605
org.eclipse.jetty.websocket/websocket-api/9.4.11.v20180605
org.eclipse.jetty.websocket/websocket-server/9.4.11.v20180605
org.eclipse.jetty.websocket/websocket-common/9.4.11.v20180605
org.eclipse.jetty.websocket/websocket-client/9.4.11.v20180605
org.eclipse.jetty/jetty-client/9.4.11.v20180605
org.eclipse.jetty.http2/http2-server/9.4.11.v20180605
org.eclipse.jetty.http2/http2-common/9.4.11.v20180605
org.eclipse.jetty.http2/http2-hpack/9.4.11.v20180605
org.eclipse.jetty/jetty-alpn-server/9.4.11.v20180605

# Provide ALPN support for JDK8 (doesn't work for JDK 9+).  Also requires
an additional alpn-boot-*.jar to be declared as a "-Xbootclasspath/p"
argument to java.
org.eclipse.jetty.osgi/jetty-osgi-alpn/9.4.11.v20180605
org.eclipse.jetty/jetty-alpn-openjdk8-server/9.4.11.v20180605

# Alternatively, exclude the JDK8 bundles and provide support for ALPN
based on support baked into the runtime for JDK9+ (doesn't work for JDK
8).  No alpn-boot-*.jar is required.
#    org.eclipse.jetty.alpn/alpn-api/1.1.3.v20160715
#    org.eclipse.jetty/jetty-alpn-java-server/9.4.11.v20180605

# Alternatively, exclude the JDK8/JDK9 ALPN impl bundles and provide
support for ALPN based on the conscrypt impl (NOTE: I haven't gotten this
one to work yet).
#
org.apache.servicemix.bundles/org.apache.servicemix.bundles.conscrypt-openjdk/1.0.1_1
#    org.eclipse.jetty/jetty-alpn-conscrypt-server/9.4.11.v20180605


FYI: I've stashed the changes to the felix.http.jetty code at [1] if you
wish to review.

   1.
   
https://github.com/enapps-enorman/felix/commit/76adf9d3a445cb620d2baa9fd1155f5e25aa3ca5


Please let me know if you have any thoughts on this.

Regards,
Eric Norman

Reply via email to