Re: Aegis DataBinding Problem - "Error initializing parameters for operation"
can you attach your class to a JIRA? Do you have a .aegis.xml file for your
SEI?
On Wed, Feb 20, 2008 at 11:01 AM, chengas123 <[EMAIL PROTECTED]>
wrote:
>
> Hi,
> I am getting "Error initializing parameters for operation" from Aegis. I
> set it up through Spring. The method it is referring to
> (getEmployeePrivilegesByUid) takes two Strings as arguments, so I'm not
> sure
> why it's having a problem. I've included the stack trace below.
>
> Thanks,
> Ben
>
>
>
> 2008-02-20 10:53:34 ContextLoader [ERROR] Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean
> with name 'auth': Invocation of init method failed; nested exception is
> org.apache.cxf.aegis.DatabindingException: Error initializing parameters
> for
> operation
> {http://service.auth.sd.sherwin.com/}getEmployeePrivilegesByUid
> :
> Caused by:
> org.apache.cxf.aegis.DatabindingException: Error initializing parameters
> for
> operation
> {http://service.auth.sd.sherwin.com/}getEmployeePrivilegesByUid
> :
>at
> org.apache.cxf.aegis.type.DefaultTypeCreator.createCollectionType(
> DefaultTypeCreator.java:59)
>at
> org.apache.cxf.aegis.type.java5.Java5TypeCreator.createCollectionType(
> Java5TypeCreator.java:137)
>at
> org.apache.cxf.aegis.type.XMLTypeCreator.createCollectionType(
> XMLTypeCreator.java:241)
>at
> org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(
> AbstractTypeCreator.java:114)
>at
> org.apache.cxf.aegis.databinding.AegisDatabinding.getParameterType(
> AegisDatabinding.java:455)
>at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(
> AegisDatabinding.java:257)
>at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(
> AegisDatabinding.java:221)
>at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(
> AegisDatabinding.java:154)
>at
>
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass
> (ReflectionServiceFactoryBean.java:313)
>at
>
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel
> (ReflectionServiceFactoryBean.java:362)
>at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(
> ReflectionServiceFactoryBean.java:156)
>at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(
> JaxWsServiceFactoryBean.java:89)
>at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(
> AbstractWSDLBasedEndpointFactory.java:74)
>at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java
> :108)
>at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(
> JaxWsServerFactoryBean.java:147)
>at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java
> :299)
>at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java
> :230)
>at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:181)
>at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:352)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
> :39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:585)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod
> (AbstractAutowireCapableBeanFactory.java:1240)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods
> (AbstractAutowireCapableBeanFactory.java:1205)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean
> (AbstractAutowireCapableBeanFactory.java:1171)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean
> (AbstractAutowireCapableBeanFactory.java:425)
>at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(
> AbstractBeanFactory.java:251)
>at
>
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton
> (DefaultSingletonBeanRegistry.java:156)
>at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(
> AbstractBeanFactory.java:248)
>at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(
> AbstractBeanFactory.java:160)
>at
>
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons
> (DefaultListableBeanFactory.java:287)
>at
> org.springframework.context.support.AbstractApplicationContext.refresh(
> AbstractApplicationContext.java:352)
>at
> org.springframework.web.context.Con
Re: Aegis DataBinding does not work
I think I see. You've got a JAX-WS+JAXB service, and you're trying to talk
to it with an Aegis client, using the same SEI. That's not going to match
up. It's not very possible to use Aegis as the client to talk to something
else, as we don't have wsdl2java for Aegis, nor could we easily make one.
On Thu, Feb 21, 2008 at 12:16 PM, Benson Margulies <[EMAIL PROTECTED]>
wrote:
> What version of CXF?
>
>
> On Thu, Feb 21, 2008 at 11:36 AM, <[EMAIL PROTECTED]>
> wrote:
>
> > Hi
> > I have configured the CXF demo.spring.HelloWorld using Aegis DataBinding
> > as per instructions found at
> > http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
> > When I run my client I am receiving the following error
> > [21.02.08 17:26:16:939 CET] 0031 PhaseIntercep I
> > org.apache.cxf.phase.PhaseInterceptorChain doIntercept Interceptor has
> > thrown exception, unwinding now
> > org.apache.cxf.interceptor.Fault: Message part
> > {http://pojo.spring.demo/}sayHi was
> > not recognized.
> >
> > Can anyone help me?
> >
> > Cheers
> > Tezcan
> > ---
> > Here is the client code
> >
> > ClientProxyFactoryBean factory = new ClientProxyFactoryBean();
> >
> > factory.getInInterceptors().add(new LoggingInInterceptor());
> > factory.getOutInterceptors().add(new LoggingOutInterceptor());
> > factory.setServiceClass(HelloWorldPojo.class);
> > factory.setAddress("http://localhost:9080/Test_Pojo_WebApp/HelloWorldPoj
> > o");
> > factory.getServiceFactory().setDataBinding(new AegisDatabinding());
> > HelloWorldPojo client = (HelloWorldPojo) factory.create();
> > String reply = client.sayHi("Tex");
> > ---
> > Here is the client log
> > --
> > INFO: Outbound Message
> > --
> > > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > ayHi xmlns:ns1="http://pojo.spring.demo/";> > xmlns="http://pojo.spring.demo/";>Tex > p:Envelope>
> > --
> > 21.02.2008 17:26:17 org.apache.cxf.interceptor.LoggingInInterceptor
> > handleMessage
> > INFO: Inbound Message
> > --
> > > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > Fault>soap:ClientMessage part
> > {http://pojo.spring.demo/}sayHi was
> > not
> > recognized.
> > --
> > org.apache.cxf.binding.soap.SoapFault: Message part
> > {http://pojo.spring.demo/}sayHi was
> > not recognized.
> > ---
> > Here is the spring config
> > ---
> > http://www.springframework.org/schema/beans";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xmlns:jaxws="http://cxf.apache.org/jaxws";
> > xsi:schemaLocation="
> > http://www.springframework.org/schema/beans
> > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
> >
> >
> > > />
> >
> >
> > > class="org.apache.cxf.aegis.databinding.AegisDatabinding"
> > scope="prototype"/>
> >
> > >class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean"
> >scope="prototype">
> >
> >
> >
> >> class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration"/>
> >> class="org.apache.cxf.aegis.databinding.AegisServiceConfiguration"/>
> >> class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
> >
> >
> >
> >
> > >implementor="demo.spring.pojo.HelloWorldPojoImpl"
> > address="/HelloWorldPojo" >
> >
> >
> >
> >
> >
> >
> >
>
>
Re: Services documentation
Well, I was mistaken that CXF was stripping the documentation elements. Sorry for the false alarm. :) However, is there a way to add documentation elements to the generated WSDL? I thought XFire provided this (there is a link on the old XFire site to documenting the WSDL), has this feature made it's way over to CXF? If so, how does one go about doing this? Thanks again, Eric On Thu, 2008-02-21 at 12:22 -0500, Eric Miles wrote: > All, > > I know the WSDL is to service as a documentation tool to identify what > services are available and how to connect them, but I'm looking for > something a little more that I could hand over to clients. I was > looking at a couple of tools that take the WSDL and generate some > javadoc like documentation that seemed to work OK, however I have a > small issue. I have placed xsd:documentation throughout my schema and > it seems as though the WSDL that is being generated by CXF, all > documentation elements have been removed. Is there a way to control > this? > > Also, do any of you have any recommendations for tools/products to look > at? Does CXF have anything built in for this? > > Thanks all, > Eric
DynamicClientFactory - REST equivalent
Hello, How do I dynamically invoke REST end points using CXF APIs? I have seen this working for web services using DynamicClientFactory. Any pointer would be appreciated. Thank you Arul
RE: client SSL question
Now using NET, I can connect to it! But CXF client still doesn't work! The message could be sent! typo, I mean couldn't Please help! -- View this message in context: http://www.nabble.com/client-SSL-question-tp15564062p15618274.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: client SSL question
https://wjcp7meduat1.medpoint.com/mdfwebservices/hprequest.asmx"/>
The remote name could not be resolved: 'wjcp7meduat1.medpoint.com' I tried
both NET and CXF.
So I update it to https://mdf.ingenixmedpoint.com/mdfwebservices/hprequest.asmx?WSDL"/>
Now using NET, I can connect to it! But CXF client still doesn't work! The
message could be sent!
Please help!
-
FINE: Sending POST Message with Headers to
https://mdf.ingenixmedpoint.com/MDFWebServices/HPRequest.asmx Conduit
:{https://mdf.ingenixmedpoint.com/MDFWebServices/HPRequest.asmx}HPRequestWSSoap.http-conduit
Content-Type: text/xml; charset=UTF-8
Feb 21, 2008 12:39:27 PM org.apache.cxf.transport.http.HTTPConduit
logProtocolHeaders
FINE: SOAPAction:
"https://mdf.ingenixmedpoint.com/MDFWebServices/HPRequest.asmx/GetRequestIDsNDA";
Feb 21, 2008 12:39:27 PM org.apache.cxf.transport.http.HTTPConduit
logProtocolHeaders
FINE: Accept: *
Feb 21, 2008 12:39:27 PM org.apache.cxf.transport.http.HTTPConduit
makeTrustDecision
FINE: No Trust Decider for Conduit
'{https://mdf.ingenixmedpoint.com/MDFWebServices/HPRequest.asmx}HPRequestWSSoap.http-conduit'.
An afirmative Trust Decision is assumed.
Feb 21, 2008 12:39:28 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
FINE: Invoking handleMessage on interceptor
[EMAIL PROTECTED]
Feb 21, 2008 12:39:28 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
FINE: Invoking handleMessage on interceptor
[EMAIL PROTECTED]
Feb 21, 2008 12:39:28 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
FINE: Invoking handleMessage on interceptor
[EMAIL PROTECTED]
Feb 21, 2008 12:39:28 PM
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream handleResponse
FINE: Response Code: 404 Conduit:
{https://mdf.ingenixmedpoint.com/MDFWebServices/HPRequest.asmx}HPRequestWSSoap.http-conduit
Feb 21, 2008 12:39:28 PM
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream handleResponse
FINE: Content length: 103
Feb 21, 2008 12:39:28 PM
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream handleResponse
FINE: Header fields:
Content-Length: [103]
Connection: [close]
null: [HTTP/1.1 404 Not Found]
Date: [Thu, 21 Feb 2008 18:39:23 GMT]
Content-Type: [text/html]
Server: [UATWEB1]
Feb 21, 2008 12:39:28 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy27.getRequestIDsNDA(Unknown Source)
at
https.mdf_ingenixmedpoint_com.mdfwebservices.hprequest.HPRequestWSSoap_HPRequestWSSoap_Client.main(HPRequestWSSoap_HPRequestWSSoap_Client.java:80)
Caused by: java.io.IOException: Not Found
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1888)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1791)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 7 more
--
View this message in context:
http://www.nabble.com/client-SSL-question-tp15564062p15618240.html
Sent from the cxf-user mailing list archive at Nabble.com.
Loading data into pre-existing objects
I am trying to convert our webservices from WebMethods Glue to CXF and I am looking for some advice and good examples. The main thing we do is upload and download a list of objects, persisted to the database via Hibernate or EJBs. Our SOAP XML files look something like this Test1 123 Main St No Where CA value Test2 456 Main St and then we have a BuildingDTO which holds the data with a BuildingServiceEJB and BuildingEJB (and similar for about 40 other objects, all which can be in DataList). I would like to use the existing data objects to get the data rather than creating new ones with WSDLToJava. Any suggestions on how to best to this? Thanks, Dan
Services documentation
All, I know the WSDL is to service as a documentation tool to identify what services are available and how to connect them, but I'm looking for something a little more that I could hand over to clients. I was looking at a couple of tools that take the WSDL and generate some javadoc like documentation that seemed to work OK, however I have a small issue. I have placed xsd:documentation throughout my schema and it seems as though the WSDL that is being generated by CXF, all documentation elements have been removed. Is there a way to control this? Also, do any of you have any recommendations for tools/products to look at? Does CXF have anything built in for this? Thanks all, Eric
Re: Aegis DataBinding does not work
What version of CXF?
On Thu, Feb 21, 2008 at 11:36 AM, <[EMAIL PROTECTED]> wrote:
> Hi
> I have configured the CXF demo.spring.HelloWorld using Aegis DataBinding
> as per instructions found at
> http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
> When I run my client I am receiving the following error
> [21.02.08 17:26:16:939 CET] 0031 PhaseIntercep I
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept Interceptor has
> thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Message part
> {http://pojo.spring.demo/}sayHi was not
> recognized.
>
> Can anyone help me?
>
> Cheers
> Tezcan
> ---
> Here is the client code
>
> ClientProxyFactoryBean factory = new ClientProxyFactoryBean();
>
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.setServiceClass(HelloWorldPojo.class);
> factory.setAddress("http://localhost:9080/Test_Pojo_WebApp/HelloWorldPoj
> o");
> factory.getServiceFactory().setDataBinding(new AegisDatabinding());
> HelloWorldPojo client = (HelloWorldPojo) factory.create();
> String reply = client.sayHi("Tex");
> ---
> Here is the client log
> --
> INFO: Outbound Message
> --
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> ayHi xmlns:ns1="http://pojo.spring.demo/";> xmlns="http://pojo.spring.demo/";>Tex p:Envelope>
> --
> 21.02.2008 17:26:17 org.apache.cxf.interceptor.LoggingInInterceptor
> handleMessage
> INFO: Inbound Message
> --
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> Fault>soap:ClientMessage part
> {http://pojo.spring.demo/}sayHi was not
> recognized.
> --
> org.apache.cxf.binding.soap.SoapFault: Message part
> {http://pojo.spring.demo/}sayHi was not
> recognized.
> ---
> Here is the spring config
> ---
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxws="http://cxf.apache.org/jaxws";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
>
>
> />
>
>
> class="org.apache.cxf.aegis.databinding.AegisDatabinding"
> scope="prototype"/>
>
>class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean"
>scope="prototype">
>
>
>
>class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration"/>
>class="org.apache.cxf.aegis.databinding.AegisServiceConfiguration"/>
>class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
>
>
>
>
>implementor="demo.spring.pojo.HelloWorldPojoImpl"
> address="/HelloWorldPojo" >
>
>
>
>
>
>
>
Aegis DataBinding does not work
Hi
I have configured the CXF demo.spring.HelloWorld using Aegis DataBinding
as per instructions found at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
When I run my client I am receiving the following error
[21.02.08 17:26:16:939 CET] 0031 PhaseIntercep I
org.apache.cxf.phase.PhaseInterceptorChain doIntercept Interceptor has
thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Message part
{http://pojo.spring.demo/}sayHi was not recognized.
Can anyone help me?
Cheers
Tezcan
---
Here is the client code
ClientProxyFactoryBean factory = new ClientProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(HelloWorldPojo.class);
factory.setAddress("http://localhost:9080/Test_Pojo_WebApp/HelloWorldPoj
o");
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
HelloWorldPojo client = (HelloWorldPojo) factory.create();
String reply = client.sayHi("Tex");
---
Here is the client log
--
INFO: Outbound Message
--
http://schemas.xmlsoap.org/soap/envelope/";>http://pojo.spring.demo/";>http://pojo.spring.demo/";>Tex
--
21.02.2008 17:26:17 org.apache.cxf.interceptor.LoggingInInterceptor
handleMessage
INFO: Inbound Message
--
http://schemas.xmlsoap.org/soap/envelope/";>soap:ClientMessage part
{http://pojo.spring.demo/}sayHi was not
recognized.
--
org.apache.cxf.binding.soap.SoapFault: Message part
{http://pojo.spring.demo/}sayHi was not recognized.
---
Here is the spring config
---
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
RE: how to let cxf client accept all/any certificates
Maybe try looking at the CXF demos - there is a WSDL first HTTPs demo
there.
Normally the CXF SSL trust information is specified through the spring
config.
>Also what if server ca is self-assigned, how to handle in this case?
Generally a CA being self-signed doesn't make any difference to you,
it is actually the simplest CA case.
Please note that a CAs certificate is fundamentally different
to an applications certificate. i.e. There is no such thing as a
self-signed application cert.
So, a self-signed CA that signed a cert request for a server to create a
server certificate would simply mean that the chain length associated
with the servers certificate is 2.
If you are not using self-signed certificates then you are dealing with
CA chains in that a specific subordinate CA may be signed by a parent
CA.
If you only want to accept certificates issued by the subordinate CA
then only specify that CA as trusted, for all practical purposes this is
almost identical to using a self signed CA as mentioned above.
NB: Don't specify the parent CA (which itself may or may not be a
self-signed CA) unless you really do want to trust all certificates
issued by all CAs that the parent CA has signed.
Additionally, if you were to do this you would have to enable support
for cert-chaining in your applications to allow them to accept
application cert chains greater than length 2.
There are additional complexities with enabling cert chaining that I
wont go into now, but it sounds like you don't need to support chain
lengths greater than 2.
It might be an idea to have read up on the Java keytool and JSSE docs to
get an overview of the area?
There also are some excellent diagnostic and key/cert related utilities
(albeit C executables) available at www.openssl.org.
Specifically I find the openssl s_client and s_server utilties answer
almost all SSL diagnostic questions once you get familiar with them.
However they don't support the Java language proprietary Keytool JKS
format,
you would need to convert to PEM format.
While the openssl runtime proper does support PKCS#12 format, I don't
think they have updated the standalone utilities yet to support the
PKCS#12 from the command line.
Docs for these utilities are on the openssl website too.
Cheers,
Donal
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 21 February 2008 14:07
To: cxf-user@incubator.apache.org
Subject: RE: how to let cxf client accept all/any certificates
how to "configure your client to trust the *Issuing Certificate
Authority*"? Any code example?
Also what if server ca is self-assigned, how to handle in this case?
Arundel, Donal wrote:
>
> At the SSL protocol level the servers that a client will trust is
> governed by the list of Certificate Authorities (CAs) that the client
is
> configured to trust.
>
> i.e. You need to configure your client to trust the *Issuing
Certificate
> Authority* that created the specific server certificate concerned.
>
> At a separate higher level there may be additional level application
> specific constraints that one might want to apply to lock down things
> further to individual server certificates if neccessary.
> e.g. querying the TLS credentials and applying extra constraints on
the
> Subjects Common Name to limit things to a single server.
>
> Cheers,
> Donal
>
> -Original Message-
> From: yulinxp [mailto:[EMAIL PROTECTED]
> Sent: 19 February 2008 18:24
> To: cxf-user@incubator.apache.org
> Subject: how to let cxf client accept all/any certificates
>
>
> Below is my CXF client which use SSL. I have put server's certificate
in
> my
> client side.
> How to change it to let it accept all/any certificates from server??
>
> QName SERVICE_NAME = new QName("http://spring.demo/";,
> "HelloWorldService");
> HelloWorldService ss = new HelloWorldService(wsdlURL,
> SERVICE_NAME);
> HelloWorld port = ss.getHelloWorldPort();
> org.apache.cxf.endpoint.Client c =
ClientProxy.getClient(port);
>
> HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> try {
> tlsParams.setKeyManagers(getKeyManagers());
> tlsParams.setTrustManagers(getTrustManagers());
> } catch (IOException e) {
> e.printStackTrace();
> }
> httpConduit.setTlsClientParameters(tlsParams);
> --
> View this message in context:
>
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
> tp15562373p15562373.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
>
>
--
View this mes
Re: mutithread issues in interceptors and endpoints
On Thursday 21 February 2008, Davide Gesino wrote: > a question about multithread issues in CXF (maybe a silly one). > Multiple requests are managed relying upon the servlet engine I CXF > uses. Every request (so every SOAPMessageContext) lives in his own > thread? If there is a pool of them, every thread in the pool manages > one request each time? Yea. Pretty much. As a request comes in, the servlet engine (or jetty if using the embedded stuff) picks a thread and starts dispatching the request on it. > In CXF there is a single instance of any endpoint bean that manages > all the incoming requests, or somehow there is way to have a pool of > endpoints? With a little bit of code, yes. You can can configure in your own invoker that does something diffent. If you look in org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes, there are various ways to configure other policies. The simplest way would be to just subclass it and overwride the getServiceObject and releaseServiceObject methods to do whatever you need them to do. Those methods would be called for each invokation, but they could return an instance from a pool, create a new one for each invoke, etc... There was also this message that mentioned something about spring support for per-session or similar things: http://www.nabble.com/Re:-Share-object-in-request-scope-on-ws-server-p14674619.html I've never tried that though. > There is also a single interceptor chain for all of them? Yes and no. A new interceptor chain is created (cloned actually) for each request. Thus, the chain itself can be modified during the execution of the message without impacting future requests. However, the interceptor instances are not cloned. A single instance is used for all requests. > So when I program my own interceptor what are the multithread issued I > have to face and consider? Well, it needs to be threadsafe/reentrant. :-) Seriously, if you need to pass values to other interceptors along the same chain, etc... you should store them in the Message or in the exchange. (msg.getExchange()). If you need to hold some state for a session, grab the HttpRequest from the msg and create an http session. Any instance variables would need to be properly protected as they would apply for all invokations of that endpoint. (example: use an AtomicInteger for a "hit count" type thing) -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
RE: client SSL question
Yup, if you can't ping wjcp7meduat1.medpoint.com (the hostname part of
the URL) then nothing will work.
This has nothing to do with CXF or SSL per-se, just your systems TCP and
DNS setup, or even an incorrect URL.
The hostname has to be resolvable to an IP address,
e.g. an nslookup on NT should return the ip address.
If you do actually know the I/P address and your problem is just just a
DNS lookup issue then just replace the symbolic hostname with the
actual I/P address in the SOAP address location URL below.
e.g. www.iona.com would be changed to, where 10.70.2.23 is the result
of an nslookup of www.iona.com.
http://10.70.2.23/
Then perhaps seek assistance from either your local network admin about
the DNS issue.
Cheers,
Donal
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 21 February 2008 14:14
To: cxf-user@incubator.apache.org
Subject: RE: client SSL question
https://wjcp7meduat1.medpoint.com/mdfwebservices/hprequest.asm
x"/>
is the entry point, right? But I can't even ping
wjcp7meduat1.medpoint.com.
Should I be able to ping it cmd?
Arundel, Donal wrote:
>
>
> You are getting an unknown host exception in the second case..
>
> e.g A name lookup (DNS) issue.
>
> This error would occur at the vanila socket layer,
> and wouldn't really be anything to do with SSL specifically.
>
> Maybe try the direct ip address temporarily until you resolve the
lookup
> issue?
>
> The first error in your mail occurred at the TLS level after
> connectivity at the TCP layer was achieved.
> That's why the errors are different.
> "No trusted certificates found" error is presumably what you were
> expecting since you disabled the setting of your key and trust
managers.
>
> Cheers,
> Donal
>
>
>
> java.net.UnknownHostException: wjcp7meduat1.medpoint.com
>
> -Original Message-
> From: yulinxp [mailto:[EMAIL PROTECTED]
> Sent: 19 February 2008 20:34
> To: cxf-user@incubator.apache.org
> Subject: client SSL question
>
>
> Below is the working copy for client to connecting to a CXF server.
> Because I comment out tlsParams.setKeyManagers and
> tlsParams.setTrustManagers,
> client receives javax.net.ssl.SSLHandshakeException:
>
> HelloWorld ss = new HelloWorld();
> HelloWorldPortType port = ss.getHelloWorldPort();
> org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
>
> HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> //try {
> //tlsParams.setKeyManagers();
> //tlsParams.setTrustManagers(xxx);
> //} catch (IOException e) {
> //e.printStackTrace();
> //}
> httpConduit.setTlsClientParameters(tlsParams);
>
> Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: No trusted certificate
found
> at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
> at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476
> )
> at
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
> at
>
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHa
> ndshaker.java:847)
> at
>
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHands
> haker.java:106)
> at
>
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
> at
>
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:4
> 33)
> at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
> :815)
> at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSo
> cketImpl.java:1025)
> at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.
> java:1038)
> at
>
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402
> )
> at
>
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Ab
> stractDelegateHttpsURLConnection.java:170)
> at
>
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConne
> ction.java:836)
> at
>
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsU
> RLConnectionImpl.java:230)
> at
>
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHead
> ersTrustCaching(HTTPConduit.java:1766)
> at
>
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWri
> te(HTTPConduit.java:1734)
> at
>
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutpu
> tStream.java:42)
> at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:96)
> at
> com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
> at
> com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
> ... 100 more
> Cause
RE: client SSL question
https://wjcp7meduat1.medpoint.com/mdfwebservices/hprequest.asmx"/>
is the entry point, right? But I can't even ping
wjcp7meduat1.medpoint.com.
Should I be able to ping it cmd?
Arundel, Donal wrote:
>
>
> You are getting an unknown host exception in the second case..
>
> e.g A name lookup (DNS) issue.
>
> This error would occur at the vanila socket layer,
> and wouldn't really be anything to do with SSL specifically.
>
> Maybe try the direct ip address temporarily until you resolve the lookup
> issue?
>
> The first error in your mail occurred at the TLS level after
> connectivity at the TCP layer was achieved.
> That's why the errors are different.
> "No trusted certificates found" error is presumably what you were
> expecting since you disabled the setting of your key and trust managers.
>
> Cheers,
> Donal
>
>
>
> java.net.UnknownHostException: wjcp7meduat1.medpoint.com
>
> -Original Message-
> From: yulinxp [mailto:[EMAIL PROTECTED]
> Sent: 19 February 2008 20:34
> To: cxf-user@incubator.apache.org
> Subject: client SSL question
>
>
> Below is the working copy for client to connecting to a CXF server.
> Because I comment out tlsParams.setKeyManagers and
> tlsParams.setTrustManagers,
> client receives javax.net.ssl.SSLHandshakeException:
>
> HelloWorld ss = new HelloWorld();
> HelloWorldPortType port = ss.getHelloWorldPort();
> org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
>
> HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> //try {
> //tlsParams.setKeyManagers();
> //tlsParams.setTrustManagers(xxx);
> //} catch (IOException e) {
> //e.printStackTrace();
> //}
> httpConduit.setTlsClientParameters(tlsParams);
>
> Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: No trusted certificate found
> at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476
> )
> at
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
> at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHa
> ndshaker.java:847)
> at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHands
> haker.java:106)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:4
> 33)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
> :815)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSo
> cketImpl.java:1025)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.
> java:1038)
> at
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402
> )
> at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Ab
> stractDelegateHttpsURLConnection.java:170)
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConne
> ction.java:836)
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsU
> RLConnectionImpl.java:230)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHead
> ersTrustCaching(HTTPConduit.java:1766)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWri
> te(HTTPConduit.java:1734)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutpu
> tStream.java:42)
> at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:96)
> at
> com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
> at
> com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
> ... 100 more
> Caused by: sun.security.validator.ValidatorException: No trusted
> certificate
> found
> at
> sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator
> .java:304)
> at
> sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.ja
> va:107)
> at sun.security.validator.Validator.validate(Validator.java:203)
> at
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X50
> 9TrustManagerImpl.java:172)
> at
> com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSL
> ContextImpl.java:320)
> at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHa
> ndshaker.java:840)
>
> Now I use the same client to connect to NET server, I got different
> exception.
> Why it's using java.net.PlainSocketImpl to make the connection?
> I don't understand why the same client has different path when
> connecting to
RE: how to let cxf client accept all/any certificates
how to "configure your client to trust the *Issuing Certificate
Authority*"? Any code example?
Also what if server ca is self-assigned, how to handle in this case?
Arundel, Donal wrote:
>
> At the SSL protocol level the servers that a client will trust is
> governed by the list of Certificate Authorities (CAs) that the client is
> configured to trust.
>
> i.e. You need to configure your client to trust the *Issuing Certificate
> Authority* that created the specific server certificate concerned.
>
> At a separate higher level there may be additional level application
> specific constraints that one might want to apply to lock down things
> further to individual server certificates if neccessary.
> e.g. querying the TLS credentials and applying extra constraints on the
> Subjects Common Name to limit things to a single server.
>
> Cheers,
> Donal
>
> -Original Message-
> From: yulinxp [mailto:[EMAIL PROTECTED]
> Sent: 19 February 2008 18:24
> To: cxf-user@incubator.apache.org
> Subject: how to let cxf client accept all/any certificates
>
>
> Below is my CXF client which use SSL. I have put server's certificate in
> my
> client side.
> How to change it to let it accept all/any certificates from server??
>
> QName SERVICE_NAME = new QName("http://spring.demo/";,
> "HelloWorldService");
> HelloWorldService ss = new HelloWorldService(wsdlURL,
> SERVICE_NAME);
> HelloWorld port = ss.getHelloWorldPort();
> org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
>
> HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> try {
> tlsParams.setKeyManagers(getKeyManagers());
> tlsParams.setTrustManagers(getTrustManagers());
> } catch (IOException e) {
> e.printStackTrace();
> }
> httpConduit.setTlsClientParameters(tlsParams);
> --
> View this message in context:
> http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
> tp15562373p15562373.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
>
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-tp15562373p15612155.html
Sent from the cxf-user mailing list archive at Nabble.com.
mutithread issues in interceptors and endpoints
Hi, a question about multithread issues in CXF (maybe a silly one). Multiple requests are managed relying upon the servlet engine I CXF uses. Every request (so every SOAPMessageContext) lives in his own thread? If there is a pool of them, every thread in the pool manages one request each time? In CXF there is a single instance of any endpoint bean that manages all the incoming requests, or somehow there is way to have a pool of endpoints? There is also a single interceptor chain for all of them? So when I program my own interceptor what are the multithread issued I have to face and consider? -- View this message in context: http://www.nabble.com/mutithread-issues-in-interceptors-and-endpoints-tp15611836p15611836.html Sent from the cxf-user mailing list archive at Nabble.com.
[2.0.4] Service unit tests fail after upgrade from 2.0.2
We are using CXF for a shop backend. After we upgraded from 2.0.2 -> 2.0.4 the
unit tests (TestNG) for the CXF services all fail with the same exception like
the one below:
FAILED: testSaveCustomer
javax.xml.ws.soap.SOAPFaultException: Could not send Message.
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:175)
at $Proxy78.saveCustomer(Unknown Source)
at
com.ewerk.shop.backend.wsapi.customer.CustomerServiceTest.testSaveCustomer(CustomerServiceTest.java:246)
Caused by: org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
... 24 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1000)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1863)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1791)
at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
at
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:157)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 29 more
The services STILL just work fine from the backend system (a webapp), only the
tests fail.
--
The unit test setup is the following:
Maven dependencies: cxf-rt-frontend-jaxws, cxf-rt-transports-http (2.0.4)
@WebService( name = "CustomerService" )
public interface ICustomerService
{
@WebMethod( operationName = "saveCustomer" )
@WebResult( name = "saveCustomerResult" )
public BackendServiceStatus saveCustomer( @WebParam( name =
"auth" ) ServiceAuthentication auth,
@WebParam( name = "customer" ) Customer customer );
}
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean ();
sf.setServiceClass( ICustomerService.class );
sf.setServiceBean( getServiceImplementation() ); --> returns the
service impl bean from spring context ('CustomerServiceImpl')
sf.setAddress(
"http://localhost:8080/Shop_Backend/wsapi/CustomerService"; );
// additionally setup JAXB context
Server server = sf.create();
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass( ICustomerService.class );
factory.setAddress(
"http://localhost:8080/Shop_Backend/wsapi/CustomerService"; );
ICustomerService client = (ICustomerService)factory.create();
// call service
BackendServiceStatus status = customerServiceProxy.saveCustomer( auth,
customer );
--
Any solution is really appreciated. Thanks in advance.
Mit lieben Grüßen aus dem eWerk
| Holger Stolzenberg
| Softwareentwickler
|
| Geschäftsführer:
| Frank Richter, Erik Wende, Hendrik Schubert
|
| eWerk IT GmbH
| Markt 16
| Leipzig 04109
| http://www.ewerk.com
| HRB 9065, AG Leipzig
| Hauptniederlassung Leipzig
|
| fon +49.341.4 26 49-0
| fax +49.341.4 26 49-88
| mailto:[EMAIL PROTECTED]
|
| Support:
| fon 0700 CALLME24 (0700 2255
RE: how to let cxf client accept all/any certificates
At the SSL protocol level the servers that a client will trust is
governed by the list of Certificate Authorities (CAs) that the client is
configured to trust.
i.e. You need to configure your client to trust the *Issuing Certificate
Authority* that created the specific server certificate concerned.
At a separate higher level there may be additional level application
specific constraints that one might want to apply to lock down things
further to individual server certificates if neccessary.
e.g. querying the TLS credentials and applying extra constraints on the
Subjects Common Name to limit things to a single server.
Cheers,
Donal
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 18:24
To: cxf-user@incubator.apache.org
Subject: how to let cxf client accept all/any certificates
Below is my CXF client which use SSL. I have put server's certificate in
my
client side.
How to change it to let it accept all/any certificates from server??
QName SERVICE_NAME = new QName("http://spring.demo/";,
"HelloWorldService");
HelloWorldService ss = new HelloWorldService(wsdlURL,
SERVICE_NAME);
HelloWorld port = ss.getHelloWorldPort();
org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("SSL");
try {
tlsParams.setKeyManagers(getKeyManagers());
tlsParams.setTrustManagers(getTrustManagers());
} catch (IOException e) {
e.printStackTrace();
}
httpConduit.setTlsClientParameters(tlsParams);
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
tp15562373p15562373.html
Sent from the cxf-user mailing list archive at Nabble.com.
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
