OK Let's go for it :)
--G
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
