Hi Eric, that sounds interesting. As far as I remember we started to embed Jetty as by that time Jetty was not available as OSGi bundles out of the box. The other reason is ease of use, you just need to install a single bundle - which is sufficient for most users - instead of a set of bundles.
Would it be possible to create the uber bundle with the correct set of files like the service loader stuff? How about we provide two artifacts, the uber and the thin one? I really would like to keep the uber one as this makes using it easier and is easier for upgrading existing systems. Regards Carsten Eric Norman wrote > 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 > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
