Hi Eric, sorry, I was a bit brief in my last mail (was on my phone). The point is:
the TCCL is the mechanism intended for configuring a ServiceLoader. That is how this is supposed to work. The problem typically is that in OSGi it is either not set or its set to the wrong classloader. However, it sounds like in case of our jetty bundle we know what classloader we want namely, the classloader of the bundle. Granted, I might be missing something but it sounds like if set the TCCL to the the bundle classloader we don't need the ServiceLoader mediator involved in our jetty bundle at all (which would be nice as it should be as self-contained a possible). Am I missing some other service case that would require it? Furthermore, I'm not sure I understand you comment about the need to "provide the appropriate alpn-impl bundles that corresponds to your JRE". Don't these jars have to be added to the bootclasspath (in which case, they can't be provided as bundles, no)? regards, Karl On Sun, Jul 15, 2018 at 11:59 PM Eric Norman <eric.d.nor...@gmail.com> wrote: > > Hi Karl, > > Perhaps juggling the TCCL around the jetty startup code would workaround > the specific startup error from PreEncodedHttpField, but I don't really > like doing that around such a broad block of someone else's code. It > wouldn't be clear to me that it doesn't have any unintended side effects > now or in the future. > > I guess I can take a closer look at patching the jetty code. A solution > that replaces their usages of ServiceLoader with a ServiceTracker when > running inside of an osgi container would be better in the long run. Plus > that would remove the need for the additional ServiceLoader mediator > bundles which would make the distribution a bit smaller. > > Regards, > Eric > > On Sun, Jul 15, 2018 at 10:28 AM, Karl Pauls <karlpa...@gmail.com> wrote: > > > I think you can just set the thread context classloader to the classloader > > of the bundle in the activator and then you don’t need the spifly thingy at > > all anymore... > > > > > > regards, > > > > Karl > > > > On Sunday, July 15, 2018, Eric Norman <eric.d.nor...@gmail.com> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
