hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: Following up HTTPCLIENT-1238
Date Mon, 08 Apr 2013 14:56:13 GMT
Hi Oleg!

my initial approach to that problem is trying to reuse, as much as I can,
existing HttpClient classes, without modifying the current codebase, but
rather just adding new functionalities in the OSGi module.

What Dominique was trying to achieve is the following usecase:

 * a power-user, which has the rights to the OSGi ConfigurationManager,
sets-up one or more Proxy configurations;

 * users/developers, when instantiating HttpClient instances, automatically
and _transparently_ get those configs in their HttpClient instances,
without having any knowledge about the proxies.

That is why Dominique was trying to register configurations via OSGi that
were injected in a registry, which were all picked up by HttpClient
instances...

A different approach I am exploring is having a ManagedServiceFactory which
manages proxy configurations and that binds kind of HttpClient factory; it
should be less intrusive - it only adds new code in the OSGi module - and
doesn't alter the original codebase... let's see what I am able to do :)

Thanks for the hints, very appreciated!
All the best,
-Simo


http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Apr 8, 2013 at 3:28 PM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Mon, 2013-04-08 at 15:17 +0200, Simone Tripodi wrote:
> > Hi Oleg!
> >
> > thanks a lot for your kind help, very appreciated! I hope to get back to
> > the issue with a proposal very soon :)
> >
> > All the best,
> > -Simo
> >
>
> I am looking forward to it. Please do try to split the change set into a
> series of smaller, incremental patches with less intrusive changes
> first. One problem with the Dominique's patch was that it tried to
> change too many things in too many places at the same time. While some
> changes were good, some needed more work.
>
> Cheers
>
> Oleg
>
>
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.org/
> >
> >
> > On Mon, Apr 8, 2013 at 1:07 PM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> >
> > > On Mon, 2013-04-08 at 09:22 +0200, Simone Tripodi wrote:
> > > > Hi all mates,
> > > >
> > > > I am trying to support my colleague Dominique, the original
> > > HTTPCLIENT-1238
> > > > reporter, on providing the patch to provide such OSGi feature.
> > > >
> > > > What we would like to achieve is registering proxy configuration(s)
> that
> > > > will be automatically picked-up by HttpClient instances, so users
> don't
> > > > have to manually register the proxy for each instance.
> > > >
> > > > In the issue I read that Oleg was working on APIs design in order to
> > > > achieve, more or less, the same goal, but after one day of
> investigation
> > > I
> > > > haven't figured out how to do it - may I can kindly ask you if there
> is
> > > any
> > > > way to implement that feature with current APIs, without adding
> > > additional
> > > > code?
> > > >
> > > > Many thanks in advance, all the best!
> > > > -Simo
> > > >
> > >
> > > Hi Simone
> > >
> > > Please have a look at the HttpClientBuilder and HttpClients classes in
> > > the 4.3 branch (trunk). What I think might be a feasible approach is to
> > > provide OSGi aware versions of those classes (similar to the caching
> > > module). OSGi aware builder can selectively inject OSGi specific
> > > dependencies instead of default ones or use a different
> > > CloseableHttpCllient implementation altogether.
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

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