You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Guillaume Sauthier <Gu...@objectweb.org> on 2010/10/13 15:34:27 UTC
CXF and HTTP proxy properties
Hi team
I've found plenty of examples over the internet explaining how to setup
an HTTP proxy (using Spring or the API).
This is always done on a per-service basis.
I was wondering why the http.proxy* System properties were not used for
supporting this ?
In my use case (the JOnAS application server), I have fileds annotated
with @WebServiceRef (plus some standard XML descriptors). The job of the
AS is to prepare the instances (port or services) that will be injected
into theses fields. I was thinking that I could configure the CXF Client
object in this phase.
I was hoping that I could take the proxy System properties, extract
required values from them and apply them on an HTTPClientPolicy for the
HTTPConduit (no Spring Configuration here, remember the Java EE saint
graal of portability between different providers), but I found that I
may be blindly configuring a port to use the system proxy without
knowing if the real endpoint address required a proxy or not.
For example, imagine an environment were system proxy is required and
configured to access external world, but the user wants to use a WS on
localhost: if I configure it to use the proxy, it will fail during the call.
I thought to use the nonProxyHost system property to conditionally apply
the proxy config but my use case required me to apply the config at the
very last moment (when we know the exact endpoint URL), requiring me to
wrap and proxy a lot of CXF classes. Definitely not an ideal solution :)
Or maybe I could implement this directly inside CXF...
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 ?
Thanks
--Guillaume
Re: CXF and HTTP proxy properties
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Le 20/10/2010 04:59, Daniel Kulp a écrit :
> On Tuesday 19 October 2010 9:06:03 am Guillaume Sauthier wrote:
>
>> (re-sending to the list this time)
>>
>> Thanks for the tips Dan.
>> I've attached patches to the original issue:
>> https://issues.apache.org/jira/browse/CXF-2839
>>
>> It's for the 2.2.x branch (Sorry that was my primary target).
>>
> Very cool. Looked perfect.
>
Thanks for applying.
>
>> As per the last comment, I was wondering what was the best option to
>> contribute things to CXF when using git ?
>> There is a git mirror of CXF in github, so we could fork that repository
>> and you could see the progress directly (no more patches exchanges)...
>> Do you have any prior experience ?
>>
> I'm definitely OK with it. I've worked with a couple things that way. Not
> so sure about some of the other committers though. The only issue is you
> would need to state in the JIRA comment or similar that the contribution is
> contributable under the Apache license. Nothing major though.
>
OK, next time I will make a try using github :)
thanks
--G
> Dan
>
>
>
>> Thanks
>> --G
>>
>> Le 18/10/2010 18:47, Daniel Kulp a écrit :
>>
>>> On Monday 18 October 2010 7:57:50 am Guillaume Sauthier wrote:
>>>
>>>> OK, I need a little help on this.
>>>>
>>>> I'm trying to imlpement the new HTTPClientPolicy "NonProxyHosts"
>>>> attributes. Ideally, I would like to directly have in the bean a Pattern
>>>> so that it's only initiallized once at parsing time.
>>>>
>>>> How to deal with that in JAXB ?
>>>> It's simple to add a String attribute in the schema resulting in a new
>>>> property in the generated bean, but how can I convert it into a regular
>>>> Pattern ?
>>>>
>>>> Some ideas ?
>>>>
>>> You'll probably need a jaxb binding file for the http-conf.xsd. Not a
>>> huge deal.
>>>
>>> It would need to do two thing:
>>> 1) For this element, it would need to set the java class to Pattern (or
>>> whatever)
>>>
>>> 2) Provide parse and print methods. (which would have to be added to a
>>> utility class in HTTP component someplace.
>>>
>>> Here is an example for a Calendar thing:
>>> <jxb:bindings schemaLocation="hello_schema2.xsd" node="/xs:schema">
>>>
>>> <jxb:globalBindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
>>>
>>> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>>>
>>> <jxb:javaType name="java.util.Calendar" xmlType="xs:dateTime"
>>>
>>> parseMethod="javax.xml.bind.DatatypeConverter.parseDateTime"
>>> printMethod="javax.xml.bind.DatatypeConverter.printDateTime"/>
>>>
>>> </jxb:globalBindings>
>>>
>>> </jxb:bindings>
>>>
>>> However, that sets it on a global level which isn't what you'd want. You
>>> would need to xpath it into the right element and set it that way.
>>>
>
Re: CXF and HTTP proxy properties
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 19 October 2010 9:06:03 am Guillaume Sauthier wrote:
> (re-sending to the list this time)
>
> Thanks for the tips Dan.
> I've attached patches to the original issue:
> https://issues.apache.org/jira/browse/CXF-2839
>
> It's for the 2.2.x branch (Sorry that was my primary target).
Very cool. Looked perfect.
>
> As per the last comment, I was wondering what was the best option to
> contribute things to CXF when using git ?
> There is a git mirror of CXF in github, so we could fork that repository
> and you could see the progress directly (no more patches exchanges)...
> Do you have any prior experience ?
I'm definitely OK with it. I've worked with a couple things that way. Not
so sure about some of the other committers though. The only issue is you
would need to state in the JIRA comment or similar that the contribution is
contributable under the Apache license. Nothing major though.
Dan
> Thanks
> --G
>
> Le 18/10/2010 18:47, Daniel Kulp a écrit :
> > On Monday 18 October 2010 7:57:50 am Guillaume Sauthier wrote:
> >> OK, I need a little help on this.
> >>
> >> I'm trying to imlpement the new HTTPClientPolicy "NonProxyHosts"
> >> attributes. Ideally, I would like to directly have in the bean a Pattern
> >> so that it's only initiallized once at parsing time.
> >>
> >> How to deal with that in JAXB ?
> >> It's simple to add a String attribute in the schema resulting in a new
> >> property in the generated bean, but how can I convert it into a regular
> >> Pattern ?
> >>
> >> Some ideas ?
> >
> > You'll probably need a jaxb binding file for the http-conf.xsd. Not a
> > huge deal.
> >
> > It would need to do two thing:
> > 1) For this element, it would need to set the java class to Pattern (or
> > whatever)
> >
> > 2) Provide parse and print methods. (which would have to be added to a
> > utility class in HTTP component someplace.
> >
> > Here is an example for a Calendar thing:
> > <jxb:bindings schemaLocation="hello_schema2.xsd" node="/xs:schema">
> >
> > <jxb:globalBindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
> >
> > xmlns:xs="http://www.w3.org/2001/XMLSchema">
> >
> > <jxb:javaType name="java.util.Calendar" xmlType="xs:dateTime"
> >
> > parseMethod="javax.xml.bind.DatatypeConverter.parseDateTime"
> > printMethod="javax.xml.bind.DatatypeConverter.printDateTime"/>
> >
> > </jxb:globalBindings>
> >
> > </jxb:bindings>
> >
> > However, that sets it on a global level which isn't what you'd want. You
> > would need to xpath it into the right element and set it that way.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: CXF and HTTP proxy properties
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
(re-sending to the list this time)
Thanks for the tips Dan.
I've attached patches to the original issue:
https://issues.apache.org/jira/browse/CXF-2839
It's for the 2.2.x branch (Sorry that was my primary target).
As per the last comment, I was wondering what was the best option to
contribute things to CXF when using git ?
There is a git mirror of CXF in github, so we could fork that repository
and you could see the progress directly (no more patches exchanges)...
Do you have any prior experience ?
Thanks
--G
Le 18/10/2010 18:47, Daniel Kulp a écrit :
> On Monday 18 October 2010 7:57:50 am Guillaume Sauthier wrote:
>
>> OK, I need a little help on this.
>>
>> I'm trying to imlpement the new HTTPClientPolicy "NonProxyHosts"
>> attributes. Ideally, I would like to directly have in the bean a Pattern
>> so that it's only initiallized once at parsing time.
>>
>> How to deal with that in JAXB ?
>> It's simple to add a String attribute in the schema resulting in a new
>> property in the generated bean, but how can I convert it into a regular
>> Pattern ?
>>
>> Some ideas ?
>>
> You'll probably need a jaxb binding file for the http-conf.xsd. Not a huge
> deal.
>
> It would need to do two thing:
> 1) For this element, it would need to set the java class to Pattern (or
> whatever)
>
> 2) Provide parse and print methods. (which would have to be added to a utility
> class in HTTP component someplace.
>
> Here is an example for a Calendar thing:
>
>
> <jxb:bindings schemaLocation="hello_schema2.xsd" node="/xs:schema">
> <jxb:globalBindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <jxb:javaType name="java.util.Calendar" xmlType="xs:dateTime"
> parseMethod="javax.xml.bind.DatatypeConverter.parseDateTime"
> printMethod="javax.xml.bind.DatatypeConverter.printDateTime"/>
> </jxb:globalBindings>
> </jxb:bindings>
>
> However, that sets it on a global level which isn't what you'd want. You
> would need to xpath it into the right element and set it that way.
>
>
>
>
Re: CXF and HTTP proxy properties
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 18 October 2010 7:57:50 am Guillaume Sauthier wrote:
> OK, I need a little help on this.
>
> I'm trying to imlpement the new HTTPClientPolicy "NonProxyHosts"
> attributes. Ideally, I would like to directly have in the bean a Pattern
> so that it's only initiallized once at parsing time.
>
> How to deal with that in JAXB ?
> It's simple to add a String attribute in the schema resulting in a new
> property in the generated bean, but how can I convert it into a regular
> Pattern ?
>
> Some ideas ?
You'll probably need a jaxb binding file for the http-conf.xsd. Not a huge
deal.
It would need to do two thing:
1) For this element, it would need to set the java class to Pattern (or
whatever)
2) Provide parse and print methods. (which would have to be added to a utility
class in HTTP component someplace.
Here is an example for a Calendar thing:
<jxb:bindings schemaLocation="hello_schema2.xsd" node="/xs:schema">
<jxb:globalBindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jxb:javaType name="java.util.Calendar" xmlType="xs:dateTime"
parseMethod="javax.xml.bind.DatatypeConverter.parseDateTime"
printMethod="javax.xml.bind.DatatypeConverter.printDateTime"/>
</jxb:globalBindings>
</jxb:bindings>
However, that sets it on a global level which isn't what you'd want. You
would need to xpath it into the right element and set it that way.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: CXF and HTTP proxy properties
Posted by Guillaume Sauthier <gu...@bull.net>.
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
>>
>
Re: CXF and HTTP proxy properties
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
OK, I need a little help on this.
I'm trying to imlpement the new HTTPClientPolicy "NonProxyHosts" attributes.
Ideally, I would like to directly have in the bean a Pattern so that
it's only initiallized once at parsing time.
How to deal with that in JAXB ?
It's simple to add a String attribute in the schema resulting in a new
property in the generated bean, but how can I convert it into a regular
Pattern ?
Some ideas ?
--G
Re: CXF and HTTP proxy properties
Posted by Daniel Kulp <dk...@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
Re: CXF and HTTP proxy properties
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Le 13/10/2010 23:21, Daniel Kulp a écrit :
> On Wednesday 13 October 2010 9:34:27 am Guillaume Sauthier wrote:
>
>> Hi team
>>
>> I've found plenty of examples over the internet explaining how to setup
>> an HTTP proxy (using Spring or the API).
>> This is always done on a per-service basis.
>> I was wondering why the http.proxy* System properties were not used for
>> supporting this ?
>>
> This is: https://issues.apache.org/jira/browse/CXF-2839
>
Oops missed that issue ...
> 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
* 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
// 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
>
>
Re: CXF and HTTP proxy properties
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 13 October 2010 9:34:27 am Guillaume Sauthier wrote:
> Hi team
>
> I've found plenty of examples over the internet explaining how to setup
> an HTTP proxy (using Spring or the API).
> This is always done on a per-service basis.
> I was wondering why the http.proxy* System properties were not used for
> supporting this ?
This is: https://issues.apache.org/jira/browse/CXF-2839
> In my use case (the JOnAS application server), I have fileds annotated
> with @WebServiceRef (plus some standard XML descriptors). The job of the
Configuration here, remember the Java EE saint
> graal of portability between different providers), but I found that I
> may be blindly configuring a port to use the system proxy without
> knowing if the real endpoint address required a proxy or not.
> For example, imagine an enviro
> AS is to prepare the instances (port or services) that will be injected
> into theses fields. I was thinking that I could configure the CXF Client
> object in this phase.
>
> I was hoping that I could take the proxy System properties, extract
> required values from them and apply them on an HTTPClientPolicy for the
> HTTPConduit (no Spring Configuration here, remember the Java EE saint
> graal of portability between different providers), but I found that I
> may be blindly configuring a port to use the system proxy without
> knowing if the real endpoint address required a proxy or not.
> For example, imagine an environment were system proxy is required and
> configured to access external world, but the user wants to use a WS on
> localhost: if I configure it to use the proxy, it will fail during the
> call.
>
> I thought to use the nonProxyHost system property to conditionally apply
> the proxy config but my use case required me to apply the config at the
> very last moment (when we know the exact endpoint URL), requiring me to
> wrap and proxy a lot of CXF classes. Definitely not an ideal solution :)
> Or maybe I could implement this directly inside CXF...
>
> 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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog