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 [email protected] http://dankulp.com/blog
