Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: CXF and HTTP proxy properties
Date: Fri, 15 Oct 2010 11:33:28 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.35; KDE/4.5.2; x86_64; ; )
Cc: Guillaume Sauthier <Guillaume.Sauthier@objectweb.org>
References: <4CB5B563.504@objectweb.org> <201010131721.49889.dkulp@apache.org>
 <4CB80892.5050305@objectweb.org>
In-Reply-To: <4CB80892.5050305@objectweb.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201010151133.29158.dkulp@apache.org>

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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog