I've used JettyProxyServlet too, and it works with openHAB out of the box: https://github.com/ConnectorIO/connectorio-io-http :-)
At least for openHAB it wasn't a problem cause jetty-proxy is present at runtime. Anyhow - there is bunch of advanced features Jetty's proxy servlet enables. I been using it to transform on the fly response from proxied services. It's quite powerful. If you need a sample of this - I will be able to cut it from somewhere. Cheers, Łukasz -- Code-House http://code-house.org On 10.06.2019 18:35, Jean-Baptiste Onofré wrote: > Hi Markus, > > I'm already added jetty-proxy in the Pax Web and Karaf features. > > I just mentioned a workaround waiting for new Pax Web/Karaf releases. > > Regards > JB > > On 10/06/2019 17:55, Markus Rathgeb wrote: >> Hi JB, >> >>> First, you can use the ProxyService directly to programmatically create >>> the proxies you need. >> >> I read the proxy service of the Karaf project but this does not fit to >> my use-case. >> I use a subclass of Jetty's proxy servlet because the "proxyTo" is not fixed. >> It depends on the caller of the URL which backend is used to generate >> the response for the request. >> >> Think about a system where an user needs to be logged in first. >> The login credentials are used to choose the real backend system. >> >> If user 1 calls httsp://some.thing/foo/bar the "reverse proxy" >> redirects the request to https://10.10.10.101/foo/bar >> If user 2 calls httsp://some.thing/foo/bar the "reverse proxy" >> redirects the request to https://10.10.10.102/foo/bar >> ... >> >> So my servlet is a subclass of the proxy servlet that generated the >> URL for the rewrite target in a very dynamic way. >> >> And it is already working it is just some additional work to align the >> Jetty version on every Karaf bump. >> >>> About the version, it's actually the opposite: the Jetty proxy is a pure >>> servlet, and a version of Jetty proxy can work with other Jetty version. >> >> Sure, the proxy is just a servlet but the implementation is using a >> e.g. Jetty HttpClient: >> >> * >> https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L43 >> * >> https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L129 >> * >> https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L273 >> >> If the Jetty proxy servlet implementation is newer then the Jetty HTTP >> Client the proxy servlet implementation could potentially use >> functions that are not yet present in the provided HttpClient >> implementation. >> If strong semver is used a newer HTTP Client should still support all >> stuff used by the proxy servlet but how knows... >> >> >> The Jetty proxy artifact is already an OSGi bundle, so what's the "big >> win" to add its classes to every bundle as private package instead of >> adding the jetty-proxy bundle to the OSGi runtime? >> >> Thank you for your patient, >> Markus >> >
