You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by jmdev <jh...@yahoo.com> on 2008/12/09 14:44:46 UTC
Re: Are properties not resolved in http:conduit
I am using 2.1.4 SNAPSHOT and am still not able to get this working. Is
there anything special one needs to do to get the
PropertyPlaceholderConfigurer to be recognized? Is there an example or test
case that you could refer me to if available.
Thanks!
dkulp wrote:
>
> On Tuesday 11 November 2008 12:31:32 pm Harry van Rijn wrote:
>> Hi,
>>
>> It looks like that properties in the http:conduit element are NOT
>> resolved.
>> Is there a way out?
>
> This SHOULD be working in CXF 2.1.3, maybe 2.1.2. What version of CXF
> are
> you using?
>
> Dan
>
>
>> I want to refer to configuration files in the JBoss
>> config directoy:
>>
>> <sec:keyManagers keyPassword="${model.server.keystore.password}">
>> <sec:keyStore type="JKS" password="${model.server.keystore.password}"
>>
>> file="${jboss.server.home.dir}/conf/props/model/${model.server.keystore.fil
>>ename}"/>
>>
>> Here is my beans containing file:
>>
>> <beans
>> xmlns="http://www.springframework.org/schema/beans"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:sec="http://cxf.apache.org/configuration/security"
>> xmlns:http="http://cxf.apache.org/transports/http/configuration"
>> xmlns:jaxws="http://cxf.apache.org/jaxws"
>> xmlns:wsa="http://cxf.apache.org/ws/addressing"
>> xmlns:cxf="http://cxf.apache.org/core"
>> xsi:schemaLocation="
>> http://cxf.apache.org/core
>> http://cxf.apache.org/schemas/core.xsd
>> http://www.springframework.org/schema/beans
>> http://www.springframework.org/schema/beans/spring-beans.xsd
>> http://cxf.apache.org/configuration/security
>> http://cxf.apache.org/schemas/configuration/security.xsd
>> http://cxf.apache.org/transports/http/configuration
>> http://cxf.apache.org/schemas/configuration/http-conf.xsd
>> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
>> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
>>
>> <bean
>> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigur
>>er"> <property name="location">
>>
>> <value>${jboss.server.config.url}/props/model/model.properties</value>
>> </property>
>> </bean>
>>
>> <import resource="classpath:META-INF/cxf/cxf.xml" />
>> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
>> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>>
>> <http:conduit
>> name="{http://modelwebservice.c.b.a/wsdl}ModelPort.http-conduit">
>> <http:tlsClientParameters secureSocketProtocol="SSL">
>> <sec:keyManagers keyPassword="${model.server.keystore.password}">
>> <sec:keyStore type="JKS" password="${model.server.keystore.password}"
>>
>> file="${jboss.server.home.dir}/conf/props/model/${model.server.keystore.fil
>>ename}"/> </sec:keyManagers>
>> <sec:trustManagers>
>> <sec:keyStore type="JKS"
>> password="${model.server.truststore.password}"
>>
>> file="${jboss.server.home.dir}/conf/props/model/${model.server.truststore.f
>>ilename}"/> </sec:trustManagers>
>> <sec:cipherSuitesFilter>
>> <!-- these filters ensure that a ciphersuite with
>> export-suitable or null encryption is used,
>> but exclude anonymous Diffie-Hellman key change as
>> this is vulnerable to man-in-the-middle attacks -->
>> <sec:include>.*_EXPORT_.*</sec:include>
>> <sec:include>.*_EXPORT1024_.*</sec:include>
>> <sec:include>.*_WITH_DES_.*</sec:include>
>> <sec:include>.*_WITH_NULL_.*</sec:include>
>> <sec:exclude>.*_DH_anon_.*</sec:exclude>
>> </sec:cipherSuitesFilter>
>> </http:tlsClientParameters>
>>
>> <!-- Default: authorization = none
>> <http:authorization>
>> <sec:UserName>tomcat</sec:UserName>
>> <sec:Password>tomcat</sec:Password>
>> </http:authorization>
>> -->
>>
>> <!-- Default: AutoRedirect = false, Connection = close
>> <http:client AutoRedirect="true" Connection="Keep-Alive"/>
>> -->
>>
>> <http:client ContentType="text/xml"/>
>> </http:conduit>
>>
>> <bean id="modelWebService"
>> class="com.tsystems.model.server.ModelPortTypeImpl" lazy-init="true" >
>> <property name="preis" value="${model.price}"/>
>> <property name="menge" value="${model.quantity}"/>
>> </bean>
>>
>> <cxf:bus>
>> <cxf:features>
>> <cxf:logging/>
>> </cxf:features>
>> </cxf:bus>
>>
>> <jaxws:endpoint id="modelEndpoint"
>> implementor="#modelWebService"
>> wsdlLocation="WEB-INF/wsdl/ModelWebService.wsdl"
>> address="/Model">
>> </jaxws:endpoint>
>>
>> </beans>
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p20914953.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by jmdev <jh...@yahoo.com>.
Alright, I dug into this one a bit more and learned that this is one of the
features they are trying to fix in Spring 3.*. For now, I will post my
solution so that others may benefit...
CXF has a solution for turning off schema validation if you are using their
application context. Since I used CXF's custom namespaces in my own
application context I was not able to leverage their code. However, if you
override ClassPathXmlApplicationContext (or whatever type you may want to
use), you can override initBeanDefinitionReader(XmlBeanDefinitionReader
xmlBeanDefinitionReader) If you set the validation mode on the
xmlBeanDefinitionReader to VALIDATION_NONE and set namespace aware to true,
you then are able to bypass schema validation, allowing you to use
properties where schema int's, booleans, etc. are expected. The obvious
downside is no more schema validation, but turning it off also boosts
performance :)
Hope that helps someone else!
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p22709973.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by jmdev <jh...@yahoo.com>.
OK Dan, I finally got back to this problem I was having and thought I would
post what I've found in case you have a simple solution. Spring property
resolution works fine for http:client http:proxyAuthorization and
http:tlsClientParameters as you said...however...
What I found is that having a property for ProxyPort
i.e.
<http:client AllowChunking="false" ProxyServer="${proxyServer}"
ProxyServerPort="${proxyPort}"/>
seems to fail schema validation before the property has a chance to be
replaced since the ProxyServerPort is defined as an xs:int in
http://cxf.apache.org/schemas/wsdl/http-conf.xsd
Here is the relevant snippet of the exception
Exception in thread "Primary Chain"
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
24 in XML document from class path resource [app-context.xml] is invalid;
nested exception is org.xml.sax.SAXParseExcep
tion: cvc-datatype-valid.1.2.1: '${proxyPort}' is not a valid value for
'integer'.
If I hard code proxyPort to say 8080 but leave ProxyServer as a Spring
property, everything works fine and the property is resolved.
Perhaps I am missing something simple... Any ideas on how I can externalize
the proxy port as a spring property?
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p22706352.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by Olivier Billard <ol...@gmail.com>.
Thank you for you answer, Dan.
The problem is trickier, as the configuration works with HTTP (I can pass
through the corporate proxy), and not HTTPs.
With HTTP, Proxy-Authorization and Authorization request headers are already
set in the first POST request (see my previous message). But with HTTPS, no
such header is set, even after the Proxy Auth challenge sent by the
corporate proxy.
The path is the following :
[Client] -> [Corporate proxy, Auth required] -> [Web service server, Basic
Auth]
I did set both http-conf:authorization and http-conf:proxyAuthorization, but
I might have set it in a wrong way, you could be right about it. Here is the
conduit configuration:
<http:conduit name="*.http-conduit">
<http:tlsClientParameters disableCNCheck="true"
secureSocketProtocol="SSL">
<sec:trustManagers>
<sec:keyStore type="JKS" password="pass" resource="truststore.jks"
/>
</sec:trustManagers>
</http:tlsClientParameters>
<!-- Corporate proxy configuration -->
<http:client AllowChunking="false" ProxyServer="${proxy.host}"
ProxyServerPort="8080" />
<!-- Application Basic Auth -->
<http:authorization>
<sec:UserName>${application.username}</sec:UserName>
<sec:Password>${application.password}</sec:Password>
</http:authorization>
<!-- Proxy Auth -->
<http:proxyAuthorization>
<sec:UserName>${proxy.username}</sec:UserName>
<sec:Password>${proxy.password}</sec:Password>
</http:proxyAuthorization>
</http:conduit>
dkulp wrote:
>
>
> It looks like you set the:
> http-conf:authorization
> stuff (through config or through code), but didn't set the
> http-conf:proxyAuthorization
> which would provide the basic auth stuff for communicating with the proxy
> server.
>
> Dan
>
>
> On Mon March 9 2009 9:56:18 am Olivier Billard wrote:
>> From TCPmon :
>>
>> With an HTTP URL endpoint :
>> POST http://endpoint-server/endpoint-url Content-Type: text/xml;
>> charset=UTF-8
>> Authorization: Basic <snip/>
>> SOAPAction: ""
>> Accept: *
>> Connection: Keep-Alive
>> Cache-Control: no-cache
>> Pragma: no-cache
>> User-Agent: Java/1.6.0_07
>> Host: proxy-server:proxy-port
>> Proxy-Connection: keep-alive
>> Content-Length: 834
>>
>>
>> With an HTTPS URL endpoint :
>> CONNECT endpoint-server:443 HTTP/1.1
>> User-Agent: Java/1.6.0_07
>> Host: proxy-server:proxy-port
>> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>>
>> And in this case, the CXF client does not reply to the HTTP Basic
>> authentication challenge.
>> Is there a particular configuration to set, different from [1]
>> (cxf-2.1.4)
>> ?
>>
>>
>> [Edit] and with the call to Authenticator.setDefault(...) added, the
>> challenge is replied correctly :
>>
>> CONNECT endpoint-server:443 HTTP/1.1
>> User-Agent: Java/1.6.0_07
>> Host: proxy-server:proxy-port
>> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>> Proxy-authorization: Basic <snip />
>>
>> [/Edit]
>>
>> Thank you !
>>
>> [1] http://cwiki.apache.org/CXF20DOC/client-http-transport.html
>> --
>> Olivier Billard
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p22430044.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by Daniel Kulp <dk...@apache.org>.
It looks like you set the:
http-conf:authorization
stuff (through config or through code), but didn't set the
http-conf:proxyAuthorization
which would provide the basic auth stuff for communicating with the proxy
server.
Dan
On Mon March 9 2009 9:56:18 am Olivier Billard wrote:
> From TCPmon :
>
> With an HTTP URL endpoint :
> POST http://endpoint-server/endpoint-url Content-Type: text/xml;
> charset=UTF-8
> Authorization: Basic <snip/>
> SOAPAction: ""
> Accept: *
> Connection: Keep-Alive
> Cache-Control: no-cache
> Pragma: no-cache
> User-Agent: Java/1.6.0_07
> Host: proxy-server:proxy-port
> Proxy-Connection: keep-alive
> Content-Length: 834
>
>
> With an HTTPS URL endpoint :
> CONNECT endpoint-server:443 HTTP/1.1
> User-Agent: Java/1.6.0_07
> Host: proxy-server:proxy-port
> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>
> And in this case, the CXF client does not reply to the HTTP Basic
> authentication challenge.
> Is there a particular configuration to set, different from [1] (cxf-2.1.4)
> ?
>
>
> [Edit] and with the call to Authenticator.setDefault(...) added, the
> challenge is replied correctly :
>
> CONNECT endpoint-server:443 HTTP/1.1
> User-Agent: Java/1.6.0_07
> Host: proxy-server:proxy-port
> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> Proxy-authorization: Basic <snip />
>
> [/Edit]
>
> Thank you !
>
> [1] http://cwiki.apache.org/CXF20DOC/client-http-transport.html
> --
> Olivier Billard
>
> Olivier Billard wrote:
> > Hi all,
> >
> > I still have a problem against corporate proxy authentication.
> > To help solve this, it works against standard HTTP connection, but not if
> > the endpoint is reached through HTTPS. I have to add the following code
> > (not production code for the moment) in my client to configure proxy
> > authorization. This only thing that varies in configuration is endpoint
> > URL.
> >
> > <code>
> > (...)
> > Authenticator.setDefault(new Authenticator() {
> > @Override
> > protected PasswordAuthentication getPasswordAuthentication()
> > { return new PasswordAuthentication("username",
> > "password".toCharArray());
> > }
> > });
> > (...)
> > </code>
> >
> > --
> > Olivier Billard
> >
> > dkulp wrote:
> >> Any chance you could produce a small sample for this? I just tried and
> >> it
> >> seemed to work fine.
> >>
> >> Dan
> >>
> >> On Tuesday 27 January 2009 2:16:30 pm jmdev wrote:
> >>> Just to add to this thread, I am having trouble with Spring property
> >>> resolution in http:client and http:proxyAuthorization as well.
> >>>
> >>> http:tlsClientParameters works fine however.
> >>>
> >>> jmdev wrote:
> >>> > It appears to work for the conduit now. Thanks! The "address"
> >>>
> >>> property
> >>>
> >>> > of jaxws:client does not appear to work however. Does that require a
> >>> > similar fix?
> >>> >
> >>> > dkulp wrote:
> >>> >> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
> >>> >>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
> >>> >>> > I am using 2.1.4 SNAPSHOT and am still not able to get this
> >>>
> >>> working.
> >>>
> >>> >>> Is
> >>> >>>
> >>> >>> > there anything special one needs to do to get the
> >>> >>> > PropertyPlaceholderConfigurer to be recognized? Is there an
> >>>
> >>> example
> >>>
> >>> >>> or
> >>> >>>
> >>> >>> > test case that you could refer me to if available.
> >>> >>>
> >>> >>> Arg.... I just checked the code and the TLSClientParameters are
> >>> >>> treated
> >>> >>> differently in the code for some reason and thus stuff in there
> >>>
> >>> doesn't
> >>>
> >>> >>> get
> >>> >>> properly processed. I'll see what can be done here. Shouldn't
> >>> >>> be too hard. (famous last words)
> >>> >>
> >>> >> Just committed some changes to trunk. Any chance you could
> >>> >> checkout trunk,
> >>> >> build it and check to make sure it works? I may get a chance to do
> >>> >> another
> >>> >> snapshot tomorrow if not.
> >>> >>
> >>> >> --
> >>> >> Daniel Kulp
> >>> >> dkulp@apache.org
> >>> >> http://dankulp.com/blog
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Are properties not resolved in http:conduit
Posted by Olivier Billard <ol...@gmail.com>.
>From TCPmon :
With an HTTP URL endpoint :
POST http://endpoint-server/endpoint-url Content-Type: text/xml;
charset=UTF-8
Authorization: Basic <snip/>
SOAPAction: ""
Accept: *
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.6.0_07
Host: proxy-server:proxy-port
Proxy-Connection: keep-alive
Content-Length: 834
With an HTTPS URL endpoint :
CONNECT endpoint-server:443 HTTP/1.1
User-Agent: Java/1.6.0_07
Host: proxy-server:proxy-port
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
And in this case, the CXF client does not reply to the HTTP Basic
authentication challenge.
Is there a particular configuration to set, different from [1] (cxf-2.1.4) ?
Thank you !
[1] http://cwiki.apache.org/CXF20DOC/client-http-transport.html
--
Olivier Billard
Olivier Billard wrote:
>
> Hi all,
>
> I still have a problem against corporate proxy authentication.
> To help solve this, it works against standard HTTP connection, but not if
> the endpoint is reached through HTTPS. I have to add the following code
> (not production code for the moment) in my client to configure proxy
> authorization. This only thing that varies in configuration is endpoint
> URL.
>
> <code>
> (...)
> Authenticator.setDefault(new Authenticator() {
> @Override
> protected PasswordAuthentication getPasswordAuthentication() {
> return new PasswordAuthentication("username",
> "password".toCharArray());
> }
> });
> (...)
> </code>
>
> --
> Olivier Billard
>
>
> dkulp wrote:
>>
>>
>> Any chance you could produce a small sample for this? I just tried and
>> it
>> seemed to work fine.
>>
>> Dan
>>
>>
>> On Tuesday 27 January 2009 2:16:30 pm jmdev wrote:
>>> Just to add to this thread, I am having trouble with Spring property
>>> resolution in http:client and http:proxyAuthorization as well.
>>>
>>> http:tlsClientParameters works fine however.
>>>
>>> jmdev wrote:
>>> > It appears to work for the conduit now. Thanks! The "address"
>>> property
>>> > of jaxws:client does not appear to work however. Does that require a
>>> > similar fix?
>>> >
>>> > dkulp wrote:
>>> >> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
>>> >>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
>>> >>> > I am using 2.1.4 SNAPSHOT and am still not able to get this
>>> working.
>>> >>>
>>> >>> Is
>>> >>>
>>> >>> > there anything special one needs to do to get the
>>> >>> > PropertyPlaceholderConfigurer to be recognized? Is there an
>>> example
>>> >>>
>>> >>> or
>>> >>>
>>> >>> > test case that you could refer me to if available.
>>> >>>
>>> >>> Arg.... I just checked the code and the TLSClientParameters are
>>> >>> treated
>>> >>> differently in the code for some reason and thus stuff in there
>>> doesn't
>>> >>> get
>>> >>> properly processed. I'll see what can be done here. Shouldn't be
>>> >>> too hard. (famous last words)
>>> >>
>>> >> Just committed some changes to trunk. Any chance you could checkout
>>> >> trunk,
>>> >> build it and check to make sure it works? I may get a chance to do
>>> >> another
>>> >> snapshot tomorrow if not.
>>> >>
>>> >> --
>>> >> Daniel Kulp
>>> >> dkulp@apache.org
>>> >> http://dankulp.com/blog
>>
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p22413408.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by Olivier Billard <ol...@gmail.com>.
Hi all,
I still have a problem against corporate proxy authentication.
To help solve this, it works against standard HTTP connection, but not if
the endpoint is reached through HTTPS. I have to add the following code (not
production code for the moment) in my client to configure proxy
authorization. This only thing that varies in configuration is endpoint URL.
<code>
(...)
Authenticator.setDefault(new Authenticator() {
@Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("username",
"password".toCharArray());
}
});
(...)
</code>
--
Olivier Billard
dkulp wrote:
>
>
> Any chance you could produce a small sample for this? I just tried and
> it
> seemed to work fine.
>
> Dan
>
>
> On Tuesday 27 January 2009 2:16:30 pm jmdev wrote:
>> Just to add to this thread, I am having trouble with Spring property
>> resolution in http:client and http:proxyAuthorization as well.
>>
>> http:tlsClientParameters works fine however.
>>
>> jmdev wrote:
>> > It appears to work for the conduit now. Thanks! The "address"
>> property
>> > of jaxws:client does not appear to work however. Does that require a
>> > similar fix?
>> >
>> > dkulp wrote:
>> >> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
>> >>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
>> >>> > I am using 2.1.4 SNAPSHOT and am still not able to get this
>> working.
>> >>>
>> >>> Is
>> >>>
>> >>> > there anything special one needs to do to get the
>> >>> > PropertyPlaceholderConfigurer to be recognized? Is there an
>> example
>> >>>
>> >>> or
>> >>>
>> >>> > test case that you could refer me to if available.
>> >>>
>> >>> Arg.... I just checked the code and the TLSClientParameters are
>> >>> treated
>> >>> differently in the code for some reason and thus stuff in there
>> doesn't
>> >>> get
>> >>> properly processed. I'll see what can be done here. Shouldn't be
>> >>> too hard. (famous last words)
>> >>
>> >> Just committed some changes to trunk. Any chance you could checkout
>> >> trunk,
>> >> build it and check to make sure it works? I may get a chance to do
>> >> another
>> >> snapshot tomorrow if not.
>> >>
>> >> --
>> >> Daniel Kulp
>> >> dkulp@apache.org
>> >> http://dankulp.com/blog
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p22412723.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by Daniel Kulp <dk...@apache.org>.
Any chance you could produce a small sample for this? I just tried and it
seemed to work fine.
Dan
On Tuesday 27 January 2009 2:16:30 pm jmdev wrote:
> Just to add to this thread, I am having trouble with Spring property
> resolution in http:client and http:proxyAuthorization as well.
>
> http:tlsClientParameters works fine however.
>
> jmdev wrote:
> > It appears to work for the conduit now. Thanks! The "address" property
> > of jaxws:client does not appear to work however. Does that require a
> > similar fix?
> >
> > dkulp wrote:
> >> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
> >>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
> >>> > I am using 2.1.4 SNAPSHOT and am still not able to get this working.
> >>>
> >>> Is
> >>>
> >>> > there anything special one needs to do to get the
> >>> > PropertyPlaceholderConfigurer to be recognized? Is there an example
> >>>
> >>> or
> >>>
> >>> > test case that you could refer me to if available.
> >>>
> >>> Arg.... I just checked the code and the TLSClientParameters are
> >>> treated
> >>> differently in the code for some reason and thus stuff in there doesn't
> >>> get
> >>> properly processed. I'll see what can be done here. Shouldn't be
> >>> too hard. (famous last words)
> >>
> >> Just committed some changes to trunk. Any chance you could checkout
> >> trunk,
> >> build it and check to make sure it works? I may get a chance to do
> >> another
> >> snapshot tomorrow if not.
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Are properties not resolved in http:conduit
Posted by jmdev <jh...@yahoo.com>.
Just to add to this thread, I am having trouble with Spring property
resolution in http:client and http:proxyAuthorization as well.
http:tlsClientParameters works fine however.
jmdev wrote:
>
> It appears to work for the conduit now. Thanks! The "address" property
> of jaxws:client does not appear to work however. Does that require a
> similar fix?
>
>
> dkulp wrote:
>>
>> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
>>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
>>> > I am using 2.1.4 SNAPSHOT and am still not able to get this working.
>>> Is
>>> > there anything special one needs to do to get the
>>> > PropertyPlaceholderConfigurer to be recognized? Is there an example
>>> or
>>> > test case that you could refer me to if available.
>>>
>>> Arg.... I just checked the code and the TLSClientParameters are
>>> treated
>>> differently in the code for some reason and thus stuff in there doesn't
>>> get
>>> properly processed. I'll see what can be done here. Shouldn't be too
>>> hard. (famous last words)
>>
>> Just committed some changes to trunk. Any chance you could checkout
>> trunk,
>> build it and check to make sure it works? I may get a chance to do
>> another
>> snapshot tomorrow if not.
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p21692323.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by jmdev <jh...@yahoo.com>.
It appears to work for the conduit now. Thanks! The "address" property of
jaxws:client does not appear to work however. Does that require a similar
fix?
dkulp wrote:
>
> On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
>> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
>> > I am using 2.1.4 SNAPSHOT and am still not able to get this working.
>> Is
>> > there anything special one needs to do to get the
>> > PropertyPlaceholderConfigurer to be recognized? Is there an example or
>> > test case that you could refer me to if available.
>>
>> Arg.... I just checked the code and the TLSClientParameters are
>> treated
>> differently in the code for some reason and thus stuff in there doesn't
>> get
>> properly processed. I'll see what can be done here. Shouldn't be too
>> hard. (famous last words)
>
> Just committed some changes to trunk. Any chance you could checkout
> trunk,
> build it and check to make sure it works? I may get a chance to do
> another
> snapshot tomorrow if not.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Are-properties-not-resolved-in-http%3Aconduit-tp20444369p20921645.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Are properties not resolved in http:conduit
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 09 December 2008 11:23:35 am Daniel Kulp wrote:
> On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
> > I am using 2.1.4 SNAPSHOT and am still not able to get this working. Is
> > there anything special one needs to do to get the
> > PropertyPlaceholderConfigurer to be recognized? Is there an example or
> > test case that you could refer me to if available.
>
> Arg.... I just checked the code and the TLSClientParameters are treated
> differently in the code for some reason and thus stuff in there doesn't get
> properly processed. I'll see what can be done here. Shouldn't be too
> hard. (famous last words)
Just committed some changes to trunk. Any chance you could checkout trunk,
build it and check to make sure it works? I may get a chance to do another
snapshot tomorrow if not.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Are properties not resolved in http:conduit
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 09 December 2008 8:44:46 am jmdev wrote:
> I am using 2.1.4 SNAPSHOT and am still not able to get this working. Is
> there anything special one needs to do to get the
> PropertyPlaceholderConfigurer to be recognized? Is there an example or
> test case that you could refer me to if available.
Arg.... I just checked the code and the TLSClientParameters are treated
differently in the code for some reason and thus stuff in there doesn't get
properly processed. I'll see what can be done here. Shouldn't be too
hard. (famous last words)
Dan
>
> Thanks!
>
> dkulp wrote:
> > On Tuesday 11 November 2008 12:31:32 pm Harry van Rijn wrote:
> >> Hi,
> >>
> >> It looks like that properties in the http:conduit element are NOT
> >> resolved.
> >> Is there a way out?
> >
> > This SHOULD be working in CXF 2.1.3, maybe 2.1.2. What version of CXF
> > are
> > you using?
> >
> > Dan
> >
> >> I want to refer to configuration files in the JBoss
> >> config directoy:
> >>
> >> <sec:keyManagers keyPassword="${model.server.keystore.password}">
> >> <sec:keyStore type="JKS"
> >> password="${model.server.keystore.password}"
> >>
> >> file="${jboss.server.home.dir}/conf/props/model/${model.server.keystore.
> >>fil ename}"/>
> >>
> >> Here is my beans containing file:
> >>
> >> <beans
> >> xmlns="http://www.springframework.org/schema/beans"
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >> xmlns:sec="http://cxf.apache.org/configuration/security"
> >> xmlns:http="http://cxf.apache.org/transports/http/configuration"
> >> xmlns:jaxws="http://cxf.apache.org/jaxws"
> >> xmlns:wsa="http://cxf.apache.org/ws/addressing"
> >> xmlns:cxf="http://cxf.apache.org/core"
> >> xsi:schemaLocation="
> >> http://cxf.apache.org/core
> >> http://cxf.apache.org/schemas/core.xsd
> >> http://www.springframework.org/schema/beans
> >> http://www.springframework.org/schema/beans/spring-beans.xsd
> >> http://cxf.apache.org/configuration/security
> >> http://cxf.apache.org/schemas/configuration/security.xsd
> >> http://cxf.apache.org/transports/http/configuration
> >> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> >> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> >> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
> >>
> >> <bean
> >> class="org.springframework.beans.factory.config.PropertyPlaceholderConfi
> >>gur er"> <property name="location">
> >>
> >> <value>${jboss.server.config.url}/props/model/model.properties</value>
> >> </property>
> >> </bean>
> >>
> >> <import resource="classpath:META-INF/cxf/cxf.xml" />
> >> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
> >> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
> >>
> >> <http:conduit
> >> name="{http://modelwebservice.c.b.a/wsdl}ModelPort.http-conduit">
> >> <http:tlsClientParameters secureSocketProtocol="SSL">
> >> <sec:keyManagers keyPassword="${model.server.keystore.password}">
> >> <sec:keyStore type="JKS"
> >> password="${model.server.keystore.password}"
> >>
> >> file="${jboss.server.home.dir}/conf/props/model/${model.server.keystore.
> >>fil ename}"/> </sec:keyManagers>
> >> <sec:trustManagers>
> >> <sec:keyStore type="JKS"
> >> password="${model.server.truststore.password}"
> >>
> >> file="${jboss.server.home.dir}/conf/props/model/${model.server.truststor
> >>e.f ilename}"/> </sec:trustManagers>
> >> <sec:cipherSuitesFilter>
> >> <!-- these filters ensure that a ciphersuite with
> >> export-suitable or null encryption is used,
> >> but exclude anonymous Diffie-Hellman key change as
> >> this is vulnerable to man-in-the-middle attacks -->
> >> <sec:include>.*_EXPORT_.*</sec:include>
> >> <sec:include>.*_EXPORT1024_.*</sec:include>
> >> <sec:include>.*_WITH_DES_.*</sec:include>
> >> <sec:include>.*_WITH_NULL_.*</sec:include>
> >> <sec:exclude>.*_DH_anon_.*</sec:exclude>
> >> </sec:cipherSuitesFilter>
> >> </http:tlsClientParameters>
> >>
> >> <!-- Default: authorization = none
> >> <http:authorization>
> >> <sec:UserName>tomcat</sec:UserName>
> >> <sec:Password>tomcat</sec:Password>
> >> </http:authorization>
> >> -->
> >>
> >> <!-- Default: AutoRedirect = false, Connection = close
> >> <http:client AutoRedirect="true" Connection="Keep-Alive"/>
> >> -->
> >>
> >> <http:client ContentType="text/xml"/>
> >> </http:conduit>
> >>
> >> <bean id="modelWebService"
> >> class="com.tsystems.model.server.ModelPortTypeImpl" lazy-init="true" >
> >> <property name="preis" value="${model.price}"/>
> >> <property name="menge" value="${model.quantity}"/>
> >> </bean>
> >>
> >> <cxf:bus>
> >> <cxf:features>
> >> <cxf:logging/>
> >> </cxf:features>
> >> </cxf:bus>
> >>
> >> <jaxws:endpoint id="modelEndpoint"
> >> implementor="#modelWebService"
> >> wsdlLocation="WEB-INF/wsdl/ModelWebService.wsdl"
> >> address="/Model">
> >> </jaxws:endpoint>
> >>
> >> </beans>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog