feature for jetty proxy

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

feature for jetty proxy

maggu2810
Hello,

the Karaf distributions contains features for jetty.
Mainly there are the jetty one in the standard feature repo and
pax-jetty in the pax web feature repo.

Both feature repos does not contain a feature that provides the
jetty-proxy bundle.

With every Karaf bump I need to modify a feature of mine for
jetty-proxy to align the jetty version used by the Karaf distribution.

Would it be possible to add that bundle to the respective features?
Perhaps using dependency="true" so it is not installed if not needed?

Best regards,
Markus
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

jbonofre
Hi Markus,

I'm suggesting to take a look on the Karaf http feature. It provides the
Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
that can run in Karaf.

If you want to use the Jetty transport proxy servlet yourself, you can
add this as private package.

It's exactly what I do in Decanter backend:

https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java

You can see the bundle I did, using jetty proxy servlet as private
package (it's just a servlet after all ;) ):

https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88

So, I don't think jetty-proxy should be part of the http/jetty feature.

Regards
JB

On 10/06/2019 10:04, Markus Rathgeb wrote:

> Hello,
>
> the Karaf distributions contains features for jetty.
> Mainly there are the jetty one in the standard feature repo and
> pax-jetty in the pax web feature repo.
>
> Both feature repos does not contain a feature that provides the
> jetty-proxy bundle.
>
> With every Karaf bump I need to modify a feature of mine for
> jetty-proxy to align the jetty version used by the Karaf distribution.
>
> Would it be possible to add that bundle to the respective features?
> Perhaps using dependency="true" so it is not installed if not needed?
>
> Best regards,
> Markus
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

maggu2810
Hi JB,

I will have a look at the Karaf ProxyService if it fits the need.
What I need to do is to create proxies dynamic and programmatic on
runtime on special user behaviour.
Some of that proxies need to choose the redirect URI by some other
information about the client.
So the real proxy target varies.
Think about a reverse proxy that redirects to different targets based
on session information.
It already works using the proxy base class provided by Jetty.

Jetty Proxy depends on Jetty Client, Jetty Server, and all the
external dependencies Jetty is using.
I could embed Jetty Proxy to every bundle that uses it but this will
increase every bundle.
And I still risk that Jetty Proxy version X does not work correctly
with Jetty Proxy version Y.
If Jetty Proxy itself does not depend on any other Jetty package and
is just a standard servlet I will check again. At least the feature
verification of a feature uses jetty proxy also depends on other jetty
bundles.

What's the problem with adding a jetty-proxy feature to the standard
distribution that adds that one jetty bundle and depends
(dependency=true) on e.g. the jetty feature.
I see you don't use that bundle yourself but it will prevent anyone
that would like to use Karaf and jetty-proxy to align the versions.
And all the ones that don't need the feature just don't need to
install it (as any other).

Best regards,
Markus

Am Mo., 10. Juni 2019 um 13:32 Uhr schrieb Jean-Baptiste Onofré
<[hidden email]>:

>
> Hi Markus,
>
> I'm suggesting to take a look on the Karaf http feature. It provides the
> Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
> The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
> that can run in Karaf.
>
> If you want to use the Jetty transport proxy servlet yourself, you can
> add this as private package.
>
> It's exactly what I do in Decanter backend:
>
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java
>
> You can see the bundle I did, using jetty proxy servlet as private
> package (it's just a servlet after all ;) ):
>
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88
>
> So, I don't think jetty-proxy should be part of the http/jetty feature.
>
> Regards
> JB
>
> On 10/06/2019 10:04, Markus Rathgeb wrote:
> > Hello,
> >
> > the Karaf distributions contains features for jetty.
> > Mainly there are the jetty one in the standard feature repo and
> > pax-jetty in the pax web feature repo.
> >
> > Both feature repos does not contain a feature that provides the
> > jetty-proxy bundle.
> >
> > With every Karaf bump I need to modify a feature of mine for
> > jetty-proxy to align the jetty version used by the Karaf distribution.
> >
> > Would it be possible to add that bundle to the respective features?
> > Perhaps using dependency="true" so it is not installed if not needed?
> >
> > Best regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

maggu2810
Added a link below

Am Mo., 10. Juni 2019 um 13:51 Uhr schrieb Markus Rathgeb <[hidden email]>:

>
> Hi JB,
>
> I will have a look at the Karaf ProxyService if it fits the need.
> What I need to do is to create proxies dynamic and programmatic on
> runtime on special user behaviour.
> Some of that proxies need to choose the redirect URI by some other
> information about the client.
> So the real proxy target varies.
> Think about a reverse proxy that redirects to different targets based
> on session information.
> It already works using the proxy base class provided by Jetty.
>
> Jetty Proxy depends on Jetty Client, Jetty Server, and all the
> external dependencies Jetty is using.

See e.g. https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/ProxyServlet.java#L35-L44

> I could embed Jetty Proxy to every bundle that uses it but this will
> increase every bundle.
> And I still risk that Jetty Proxy version X does not work correctly
> with Jetty Proxy version Y.
> If Jetty Proxy itself does not depend on any other Jetty package and
> is just a standard servlet I will check again. At least the feature
> verification of a feature uses jetty proxy also depends on other jetty
> bundles.
>
> What's the problem with adding a jetty-proxy feature to the standard
> distribution that adds that one jetty bundle and depends
> (dependency=true) on e.g. the jetty feature.
> I see you don't use that bundle yourself but it will prevent anyone
> that would like to use Karaf and jetty-proxy to align the versions.
> And all the ones that don't need the feature just don't need to
> install it (as any other).
>
> Best regards,
> Markus
>
> Am Mo., 10. Juni 2019 um 13:32 Uhr schrieb Jean-Baptiste Onofré
> <[hidden email]>:
> >
> > Hi Markus,
> >
> > I'm suggesting to take a look on the Karaf http feature. It provides the
> > Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
> > The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
> > that can run in Karaf.
> >
> > If you want to use the Jetty transport proxy servlet yourself, you can
> > add this as private package.
> >
> > It's exactly what I do in Decanter backend:
> >
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java
> >
> > You can see the bundle I did, using jetty proxy servlet as private
> > package (it's just a servlet after all ;) ):
> >
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88
> >
> > So, I don't think jetty-proxy should be part of the http/jetty feature.
> >
> > Regards
> > JB
> >
> > On 10/06/2019 10:04, Markus Rathgeb wrote:
> > > Hello,
> > >
> > > the Karaf distributions contains features for jetty.
> > > Mainly there are the jetty one in the standard feature repo and
> > > pax-jetty in the pax web feature repo.
> > >
> > > Both feature repos does not contain a feature that provides the
> > > jetty-proxy bundle.
> > >
> > > With every Karaf bump I need to modify a feature of mine for
> > > jetty-proxy to align the jetty version used by the Karaf distribution.
> > >
> > > Would it be possible to add that bundle to the respective features?
> > > Perhaps using dependency="true" so it is not installed if not needed?
> > >
> > > Best regards,
> > > Markus
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > [hidden email]
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

jbonofre
In reply to this post by maggu2810
Hi Markus,

First, you can use the ProxyService directly to programmatically create
the proxies you need.

Second about the Jetty proxy, if you take a look in Decanter, you will
see that only org.eclipse.jetty.proxy is private, jetty-client,
jetty-server, etc, are import packages, not private. So the size of the
bundle is just few bytes.

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.

I don't have a proxy to extend the features (both pax and karaf ones),
but I just wanted to spot that it's not a requirement right now with
your need.

Regards
JB

On 10/06/2019 13:51, Markus Rathgeb wrote:

> Hi JB,
>
> I will have a look at the Karaf ProxyService if it fits the need.
> What I need to do is to create proxies dynamic and programmatic on
> runtime on special user behaviour.
> Some of that proxies need to choose the redirect URI by some other
> information about the client.
> So the real proxy target varies.
> Think about a reverse proxy that redirects to different targets based
> on session information.
> It already works using the proxy base class provided by Jetty.
>
> Jetty Proxy depends on Jetty Client, Jetty Server, and all the
> external dependencies Jetty is using.
> I could embed Jetty Proxy to every bundle that uses it but this will
> increase every bundle.
> And I still risk that Jetty Proxy version X does not work correctly
> with Jetty Proxy version Y.
> If Jetty Proxy itself does not depend on any other Jetty package and
> is just a standard servlet I will check again. At least the feature
> verification of a feature uses jetty proxy also depends on other jetty
> bundles.
>
> What's the problem with adding a jetty-proxy feature to the standard
> distribution that adds that one jetty bundle and depends
> (dependency=true) on e.g. the jetty feature.
> I see you don't use that bundle yourself but it will prevent anyone
> that would like to use Karaf and jetty-proxy to align the versions.
> And all the ones that don't need the feature just don't need to
> install it (as any other).
>
> Best regards,
> Markus
>
> Am Mo., 10. Juni 2019 um 13:32 Uhr schrieb Jean-Baptiste Onofré
> <[hidden email]>:
>>
>> Hi Markus,
>>
>> I'm suggesting to take a look on the Karaf http feature. It provides the
>> Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
>> The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
>> that can run in Karaf.
>>
>> If you want to use the Jetty transport proxy servlet yourself, you can
>> add this as private package.
>>
>> It's exactly what I do in Decanter backend:
>>
>> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java
>>
>> You can see the bundle I did, using jetty proxy servlet as private
>> package (it's just a servlet after all ;) ):
>>
>> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
>> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88
>>
>> So, I don't think jetty-proxy should be part of the http/jetty feature.
>>
>> Regards
>> JB
>>
>> On 10/06/2019 10:04, Markus Rathgeb wrote:
>>> Hello,
>>>
>>> the Karaf distributions contains features for jetty.
>>> Mainly there are the jetty one in the standard feature repo and
>>> pax-jetty in the pax web feature repo.
>>>
>>> Both feature repos does not contain a feature that provides the
>>> jetty-proxy bundle.
>>>
>>> With every Karaf bump I need to modify a feature of mine for
>>> jetty-proxy to align the jetty version used by the Karaf distribution.
>>>
>>> Would it be possible to add that bundle to the respective features?
>>> Perhaps using dependency="true" so it is not installed if not needed?
>>>
>>> Best regards,
>>> Markus
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

maggu2810
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
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

jbonofre
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
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

maggu2810
Thanks a lot (for both)!

Am Mo., 10. Juni 2019 um 18:36 Uhr schrieb Jean-Baptiste Onofré
<[hidden email]>:

>
> 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
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: feature for jetty proxy

Łukasz Dywicki
In reply to this post by jbonofre
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
>>
>