felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Norman <eric.d.nor...@gmail.com>
Subject Re: Felix Http Jetty packaging as uber bundle?
Date Mon, 16 Jul 2018 17:54:04 GMT
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 <karlpauls@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 <eric.d.norman@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 <karlpauls@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.norman@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message