Let's not forget the fact that jetty is not semantically versioned, which can cause ugly problems. The Uber jetty bundle hides this concern.
I'm not saying this couldn't be solved somehow but it can't be ignored. And also don't get me wrong, I love jetty! The thing is that Felix modules are cornerstone OSGi technologies and it takes things like semantic versioning seriously and I would be opposed to having a key part of the system suddenly become a burden by binding itself to something that isn't semantically versioned. Sincerely, - Ray On Sat, Jul 14, 2018, 04:04 Carsten Ziegeler, <cziege...@apache.org> wrote: > 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 > >
