You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Eric Norman <er...@gmail.com> on 2018/07/13 19:52:22 UTC
Felix Http Jetty packaging as uber bundle?
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
Re: Felix Http Jetty packaging as uber bundle?
Posted by Eric Norman <er...@gmail.com>.
Hi Karl,
I understand how ServiceLoader works. But in OSGi the proper way to do
ServiceLoader is what is described in the Service Loader Mediator
specification (see [1]). Playing with the TCCL is just a workaround and
error prone. Also, it seems to me that setting the TCCL to a specific
bundle makes the assumption that all the ServiceLoader providers are within
that same bundle which isn't always (or typically) the case.
RE: the alpn-impl bundles
Only the JDK8 impl requires adding the alpn-boot-*.jar to the
bootclasspath. In java 9 or later the ALPN support is baked into the JRE
so doing the same is not needed or appropriate anymore.
So my point was basically that there is a choice to be made about which
jetty ALPN bundles to include. There is one set of bundles if you are
running with java 8, another set of bundles if you are running java 9 or
later, and yet another set of bundles if you wish to use the conscript impl
of the same for better performance as described at [2].
If we don't use an uber bundle for felix.http.jetty then that choice is
easy as you can just provision whichever set of bundles is appropriate for
your environment and just ignore the others. However if we continue to use
an uber bundle, then we would likely need a new unique
felix.http.jetty artifact for
each combination of bundles?
So I guess my point remains that the uber felix.http.jetty bundle is not
really a good idea, but perhaps I haven't convinced everyone yet.
1. https://osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html
2. https://webtide.com/conscrypting-native-ssl-for-jetty/
I hope that makes sense.
Regards,
-Eric
On Mon, Jul 16, 2018 at 12:58 AM, Karl Pauls <ka...@gmail.com> wrote:
> 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 <er...@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 <ka...@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 <er...@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 <
> cziegeler@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
> > > > > cziegeler@apache.org
> > > > >
> > > > > ------------------------------------------------------------
> ---------
> > > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > > For additional commands, e-mail: users-help@felix.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> > >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Felix Http Jetty packaging as uber bundle?
Posted by Karl Pauls <ka...@gmail.com>.
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 <er...@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 <ka...@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 <er...@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 <cz...@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
> > > > cziegeler@apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> >
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix Http Jetty packaging as uber bundle?
Posted by Eric Norman <er...@gmail.com>.
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 <ka...@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 <er...@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 <cz...@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
> > > cziegeler@apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: Felix Http Jetty packaging as uber bundle?
Posted by Karl Pauls <ka...@gmail.com>.
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 <er...@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 <cz...@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
> > cziegeler@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
Karl Pauls
karlpauls@gmail.com
Re: Felix Http Jetty packaging as uber bundle?
Posted by Eric Norman <er...@gmail.com>.
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 <cz...@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Felix Http Jetty packaging as uber bundle?
Posted by Raymond Auge <ra...@liferay.com>.
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, <cz...@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Felix Http Jetty packaging as uber bundle?
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org