Hi Carsten, I tried to make it work with an uber bundle by merging in the important stuff. In this case the o.a.felix.http.jetty is both a consumer and a producer of a few ServiceLoader services.
Unfortunately, it looks like there is a problem with using the service loader mediator stuff in the uber bundle. The problem is that the spifly osgi.extender listens for new bundles being installed (when the bundle reaches the ACTIVE state) and registers the service providers it discovers at that point. However, one of the ServiceLoader.load consumer calls is invoked in the JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE state (see the stack trace below). So in this use case, the producer hasn't declared the services yet when the consumer tries to use them. PreEncodedHttpField.<clinit>() line: 49 MimeTypes$Type.<init>(String) line: 103 MimeTypes$Type.<clinit>() line: 58 MimeTypes.<clinit>() line: 191 ServletContextHandler(ContextHandler).doStart() line: 832 ServletContextHandler.doStart() line: 287 ServletContextHandler(AbstractLifeCycle).start() line: 68 ContextHandlerCollection(ContainerLifeCycle).start(LifeCycle) line: 138 ContextHandlerCollection(ContainerLifeCycle).doStart() line: 117 ContextHandlerCollection(AbstractHandler).doStart() line: 113 ContextHandlerCollection.doStart() line: 167 ContextHandlerCollection(AbstractLifeCycle).start() line: 68 Server(ContainerLifeCycle).start(LifeCycle) line: 138 Server.start(LifeCycle) line: 419 Server(ContainerLifeCycle).doStart() line: 108 Server(AbstractHandler).doStart() line: 113 Server.doStart() line: 386 Server(AbstractLifeCycle).start() line: 68 JettyService.initializeJetty() line: 426 JettyService.startJetty() line: 306 JettyService.start() line: 149 JettyActivator.doStart() line: 63 JettyActivator(AbstractActivator).start(BundleContext) line: 39 SecureAction.startActivator(BundleActivator, BundleContext) line: 697 SlingFelix(Felix).activateBundle(BundleImpl, boolean) line: 2240 SlingFelix(Felix).startBundle(BundleImpl, int) line: 2146 SlingFelix(Felix).setActiveStartLevel(int, FrameworkListener[]) line: 1373 FrameworkStartLevelImpl.run() line: 308 Thread.run() line: 748 It seems that some other changes would be required to get around that. Either changes to jetty code or changing the felix code to not start synchronously in the bundle activator. The uber bundle seems to complicate the scenario and additional bundles are still required anyways to enable OSGi ServiceLoader mediator support and provide the appropriate alpn-impl bundles that corresponds to your JRE. Does that make sense? Regards, Eric On Sat, Jul 14, 2018 at 1:04 AM, 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 > >
