cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Sauthier <>
Subject Re: CXF and HTTP proxy properties
Date Mon, 18 Oct 2010 07:22:57 GMT
OK Let's go for it :)

Le 15/10/2010 17:33, Daniel Kulp a écrit :
> On Friday 15 October 2010 3:53:54 am Guillaume Sauthier wrote:
>>> So, I come here to discuss this point.
>>>> Could it be possible (currently I'm not sure, but maybe as an evolution)
>>>> to provide the proxy configuration as some kind of global variable for
>>>> all the services (maybe as a per-bus configuration), but with support
>>>> for nonProxyHost (or the like) ?
>>>> WDYT ?
>>> I think this could be done via an interceptor as well.   An interceptor
>>> run very early in the chain could grab the conduit and reconfigure the
>>> proxy stuff fairly easily based on the URL it's going to hit.
>>> The other way to handle this, which is how JBoss does this I believe, is
>>> to set their own Configurer on the bus that wrappers the original one
>>> and has configureBean methods that, if the bean is an HTTPConduit,
>>> completely configures the conduit based on information from the app
>>> servers configs. Really, that is the ideal way for app servers and
>>> containers and such to configure the various parts of CXF as CXF uses
>>> that mechanism to configure itself.
>> OK I get your point.
>> But how this solution (not interceptor based) can handle the issue of
>> the client changing the endpoint address after it has retrieved the port
>> proxy ?
>> After reading the code, it seems that the real URL is finally known
>> during HTTPConduit.prepare(Message) (more precisely in
>> HTTPConduit.setupUrl() ), so using an Interceptor will probably not help
>> :'( Then the URL is passed to an HttpConnectionFactory along with a Proxy
>> instance (created from the proxy information in the Conduit's config)
>> After some more thinking I think my solution will be something like:
>> * Configure the HTTPConduit using the Configurer extension to propagate
>> the System HTTP proxy properties
> Yep, although ideally, HTTPConduit would call client.isSetProxyServer() and if
> false, use the system properties.   Then nothing to configure.   A patch for
> that would be more than welcome.  :-)
>> * Provides a new HttpUrlConnectionFactory that will act as  a proxy and
>> nullify the Proxy reference (given as param) if the URL endpoint is one
>> of the hosts filtered by http.nonProxyHosts before delegating to the
>> real HttpUrlConnectionFactory
> I really wouldn't go there.   If you look at what I'm doing on the branch for
> async work, the HttpUrlConnectionFactory isn't used for that since the http-
> client stuff doesn't use the HttpURLConnection object.
> Actually, an interceptor CAN configure an HTTPClientPolicy.   I can do
> something like:
> HTTPClientPolicy pol = new HTTPClientPolicy();
> pol.setABunchOf Things();
> message.put(HTTPClientPolicy.class, pol)
> and the HTTPConduit will intersect that with the one it has to create an
> effective HTTPClientPolicy that is used.   Thus, you can set a proxy from an
> interceptor that way and  not  really modify the CXF code at all.
> HOWEVER, my suggestion would be to:
> 1) Add a nonProxyHosts element to the HTTPClientPolicy so it can be
> configured.
> 2) Update the  getProxy(..) call in HTTPConduit to take the URL as a param and
> have it call the isSet things and such to do the logic.   Use the sysprops if
> unset.
> Then attach the above to a JIRA as a patch and we'll get it committed real
> soon.  :-)
> Dan
>> // Theses 2 first points could be contributed back directly to CXF
>> * Indeed, for JOnAS I'll have to intercept the HTTPConduit creation with
>> my own HTTPConduit subclass that will return my own
>> HttpUrlConnectionFactory.
>> // This last part could be introduced directly into CXF HTTPConduit if
>> you're ok with this (directly using the
>> FilteringNonProxyHostsHttpUrlConnectionFactory - quite long name BTW :) )
>> WDYT ?
>> --G

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