RE: writing SSL webservice client
Yes, that is correct. Nate -Original Message- From: siva naresh [mailto:svu...@progress.com] Sent: Thursday, July 15, 2010 1:12 AM To: users@cxf.apache.org Subject: RE: writing SSL webservice client Lets keep it simple.. Lets say my original client ( that invokes http web service) is not modified at all except changing the webservice address from http to https. But the server has been modified to support https requests and it has certificate issued by well known GlobalSign CA. Can I assume that the client need not be changed accept changing the protocol from http to https..? -- View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p 1171276.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Generally, we use server keys provided by one of the common CA's that are in cacerts by default. I'm not sure if this is applicable to what you're doing. You can add keys to any keystore (including cacerts) using the keytool command (common uses: http://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html). Certificate validation is the responsibility of JSSE libraries. If you're trying to understand the ssl communication, you can turn on ssl debugging (-Djavax.net.debug=all) which may help elucidate what is actually happening for your code. Hope that get's you going in the the right direction, Nate -Original Message- From: siva naresh [mailto:svu...@progress.com] Sent: Wed 7/14/2010 1:41 AM To: users@cxf.apache.org Subject: Re: writing SSL webservice client I also tried an example locally, Where I generated certificates using keytool for the server and used the same certificate to invoke the server from the client using trustmanager in the following way. sec:trustManagers sec:keyStore type=JKS password=password file=truststore.jks/ it worked fine. But this is not for the production use. What changes do I need to make for production use ? what is the way to put the server's public key in the client JDK's cacerts file. Does CXF has anything to make this automatically? Does CXF verify the authenticity of the server's public key with the CA? -- View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086015.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: Lag in service creation
Well, largerly as an FYI, there's mojo in 2.2.7 that resolved the
problem. In the hail mary have you updated the firmware spirit, I
built a version on the latest 2.2.7 and it appeared to make the problem
go away for the customer. Unfortunately, I haven't been able to
duplicate the problem on anything locally and don't really have the
means to do anything on their machines, so I can't provide an actual
answer to what was happening or why it went away.
Either way, I'm going to take it.
Thanks,
Nate
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Wednesday, March 31, 2010 11:18 PM
To: users@cxf.apache.org
Cc: Nate Woody
Subject: Re: Lag in service creation
It definitely does sound like a WSDL/xsd download issue. I'm not sure
if you
can use wireshark or something to look at the traffic going back and
forth to
see if something obvious there is causing an issue.
We DO cache the wsdl which explains the speedup on the subsequent calls.
Dan
On Wednesday 31 March 2010 3:46:55 pm Nate Woody wrote:
I'm running an cxf-2.2.4 client against a .NET service located in NY.
Some customers running Mac 10.6 in Germany are seeing a massive lag in
talking to the service and I've managed to narrow it down to the
service
creation. It only appears to happen the first time the client
constructs the service, subsequent service constructions don't lag.
Here's the basic code:
(StubService is a javax.xml.ws.Service object created by WSDLTojava)
logger.info(Starting cert config);
StubService service = new StubService();
logger.info(Created service);
hpc = service.getFactoryPortType();
logger.info(Retrieved port);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(hpc);
logger.info(configuring logging interceptors);
client.getOutInterceptors().add(new
LoggingOutInterceptor());
client.getInInterceptors().add(new LoggingInInterceptor());
There is almost a 5 minute lag executing the Service constructor and
the
getFactoryPortType the first invocation:
[2010-03-31 20:51:37,034] INFO Mediator(main) - Starting cert config
[2010-03-31 20:58:26,040] INFO Mediator(main) - Created service
[2010-03-31 20:58:26,048] INFO ReflectionServiceFactoryBean(main) -
Creating Service {service} from WSDL: http://myserver.org/WSDL.xml
[2010-03-31 21:05:13,889] INFO Mediator(main) - Retrieved port
[2010-03-31 21:05:13,889] INFO Mediator(main) - configuring logging
interceptors
However, subsequent calls occur right away:
[2010-03-31 21:05:16,255] INFO Mediator(main) - Starting certHPC
config
[2010-03-31 21:05:16,255] INFO Mediator(main) - Created service
[2010-03-31 21:05:16,256] INFO ReflectionServiceFactoryBean(main) -
Creating Service {service} from WSDL: http://myserver.org/WSDL.xml
[2010-03-31 21:05:16,319] INFO Mediator(main) - Retrieved port
[2010-03-31 21:05:16,320] INFO Mediator(main) - configuring logging
interceptors
My only thought is that there is some network problems in retrieving
the
wsdl and associated xsds, though they don't see any problems if they
access the wsdl from a browser or wget. I can't duplicate the problem
on any of my systems and I haven't yet sent them a build that contains
the wsdl locally to completely remove the network communication. Is
there anything else going on in here that could be causing problems?
Is
cxf (or friends) doing something smart with the WSDL that explains why
I
only seem to see the lag the first time the service object is
constructed?
Thanks,
Nate
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Lag in service creation
I'm running an cxf-2.2.4 client against a .NET service located in NY.
Some customers running Mac 10.6 in Germany are seeing a massive lag in
talking to the service and I've managed to narrow it down to the service
creation. It only appears to happen the first time the client
constructs the service, subsequent service constructions don't lag.
Here's the basic code:
(StubService is a javax.xml.ws.Service object created by WSDLTojava)
logger.info(Starting cert config);
StubService service = new StubService();
logger.info(Created service);
hpc = service.getFactoryPortType();
logger.info(Retrieved port);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(hpc);
logger.info(configuring logging interceptors);
client.getOutInterceptors().add(new LoggingOutInterceptor());
client.getInInterceptors().add(new LoggingInInterceptor());
There is almost a 5 minute lag executing the Service constructor and the
getFactoryPortType the first invocation:
[2010-03-31 20:51:37,034] INFO Mediator(main) - Starting cert config
[2010-03-31 20:58:26,040] INFO Mediator(main) - Created service
[2010-03-31 20:58:26,048] INFO ReflectionServiceFactoryBean(main) -
Creating Service {service} from WSDL: http://myserver.org/WSDL.xml
[2010-03-31 21:05:13,889] INFO Mediator(main) - Retrieved port
[2010-03-31 21:05:13,889] INFO Mediator(main) - configuring logging
interceptors
However, subsequent calls occur right away:
[2010-03-31 21:05:16,255] INFO Mediator(main) - Starting certHPC config
[2010-03-31 21:05:16,255] INFO Mediator(main) - Created service
[2010-03-31 21:05:16,256] INFO ReflectionServiceFactoryBean(main) -
Creating Service {service} from WSDL: http://myserver.org/WSDL.xml
[2010-03-31 21:05:16,319] INFO Mediator(main) - Retrieved port
[2010-03-31 21:05:16,320] INFO Mediator(main) - configuring logging
interceptors
My only thought is that there is some network problems in retrieving the
wsdl and associated xsds, though they don't see any problems if they
access the wsdl from a browser or wget. I can't duplicate the problem
on any of my systems and I haven't yet sent them a build that contains
the wsdl locally to completely remove the network communication. Is
there anything else going on in here that could be causing problems? Is
cxf (or friends) doing something smart with the WSDL that explains why I
only seem to see the lag the first time the service object is
constructed?
Thanks,
Nate
RE: Service authentication credentials
I've been forced to write quite a few CXF clients to Microsoft services, I think the mailing list is littered with my questions about that. Is this a service someone developed using Microsoft tools, or a service produced by Microsoft? That's a Great Plains reference? I've often had trouble with figuring the security mechanism from a MS wsdl, so I tend to go pragmatic and start here: 1) What does the service reply with when you call it from CXF? If it's something as simple as WS-S, you ought to get a complaint about missing security headers. 2) It sounds like you have a functional .NET implementation. Log the packets from that implementation and take a look at what's going in. Best, Nate -Original Message- From: Bruno Melloni [mailto:bruno.mell...@chickasaw.net] Sent: Thursday, March 11, 2010 9:20 AM To: 'users@cxf.apache.org' Subject: Service authentication credentials I am trying to access a Microsoft-developed service that requires authentication. Being Microsoft, they do not document anything at the web service level since they want you to use Visual Studio which creates a .NET proxy that is capable of using NTLM to supply the username/password to the underlying web service. I *think* that they are following web services standards for the underlying web service. Of course, I am trying to use a CXF client to access the underlying web service from Java. I used wsdl2java to generate the java classes, but I see no credentials-related information (which you do see in the .NET proxy). That makes me suspect that they must be in the stored in the SOAP headers and that in CXF we access them in a different way. I could use any clues on how to: a) Figure out how authentication is being done for this web service. b) Figure out how to provide the credentials to the web service when called. I am using the Spring approach to get the CXF client proxy and my current configuration looks like: jaxws:client id=gpClient address=http://myServer.myDomain/DynamicsGPWebServices/DynamicsGPServic e.asmx serviceClass=com.microsoft.schemas.dynamics.gp._2006._01.DynamicsX0020G PSoap / Needless to say, my experience with CXF is not too deep (created and called a few services via the Spring method - the simplest), and my knowledge of web services authentication is zero. Unfortunately CXF's documentation isn't very helpful for someone at my stage of learning CXF. I'll appreciate any help I can get. I tried to attach a copy of the WSDL for the service that I'm trying to access, but it exceeds the size limits for this mailing list.
RE: SSL with mutual authentication for system and propagating username in same call
Hello, I, too, am interested in intelligent ways to implement this solution and so am interested in any feedback on this. We recently implemented something similar and I've got an axe to grind. 2-way SSL is a bit of an annoyance as it's really out-of-band with the web service. CXF has essentially no role to play (aside from the fact that I configured 2-way ssl in cxf.xml), so the certificates used for client authentication must be separately accessed if you want to include something from that in the message. In our case, we were able to extract the DN from the client SSL certificate on the server side and then do a look-up with that DN for authorization of the particular action. But that's a mess. Depending on how requirement-y your requirements are, it feels like a better solution is to use 1-way SSL to secure the channel and then use WSS to identify the individual call inside the ssl connection. This has the advantage of putting all authentication and authorization inside the message and relying on SSL only to secure the transport channel. It should probably be noted that these are all essentially in pursuit of a stateless solution where every message is individually authorized, as opposed to a solution that implements some sort of a login (which is how I used to operate in the XFire world). Given all that, I'd be interested in hearing the opinion of someone who knows what they're talking about. Best, Nate -Original Message- From: forda [mailto:daniel.forb...@bredband.net] Sent: Tuesday, December 01, 2009 2:36 AM To: users@cxf.apache.org Subject: SSL with mutual authentication for system and propagating username in same call Hi ! I am designing a security solution ordered from the Security architect for a customer i work for. The requirement is to use a two-way ssl handshake in order indentify/authenticate system access to webservices. Except the authentication of the system against CA Certificate, authorization map is needed to determine which systems have access to which services. The systems enduser must also be propagated in the call for auditing logging purposes. The infrastructure used is Apache webbserver 2.2.X, Tomcat 6, Private CA and CXF 2.2.4 of course. In order to make this to work there are a number of options to accomplish the same thing. Therefore i just want to discuss the solution with you here at the forum, to achieve the other opions and knowledge than my own. *Certificates generated by private CA *HTTPConduit can be used to establish the two-way ssl handshake with use of client-certificate used in conjunction with jaxws-client. Is there a way to add the system identity to the Principal object along with the username which indentifies the user ? One option would be to use X509 Token Profile or CLIENT-CERT authentication or ? *Customized authorization based on client-certificates subject dn, map against the service/-es. ? Any built in support for this? *WSS Security, wit WSS4j to accomplish propagation if the username, no need for authentication, though include the username in the Principal in the webservicecontext. Does the WSS4J interceptor put the username in the Principal object on the Webservicecontext which is injected with @Resource annotation ? If not, howto ? Thanks in advance. Regards, Daniel -- View this message in context: http://old.nabble.com/SSL-with-mutual-authentication-for-system-and-prop agating-username-in-same-call-tp26587711p26587711.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: SSL Woes. Can't get past handshake_failure message
FWIW, the only way I've successfully debugged SSL problems is by turning on SSL debugging (something like: System.setProperty(javax.net.debug,ssl)). Hopefully, you can at least verify where/why the handshake is failing, what truststore is being used, etc. You will definitely see if the server certificate is the problem. Nate -Original Message- From: cj91 [mailto:jonathan.fis...@argushealth.com] Sent: Tuesday, November 03, 2009 4:35 PM To: users@cxf.apache.org Subject: SSL Woes. Can't get past handshake_failure message Hi guys. I'm trying to connect via SSL to another webservice. I'm not having much luck. We tried entering the root certificates from versign and the server certificate but still getting this exception message: Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.ibm.jsse2.n.a(n.java:3) at com.ibm.jsse2.n.a(n.java:23) at com.ibm.jsse2.jc.b(jc.java:464) at com.ibm.jsse2.jc.a(jc.java:429) at com.ibm.jsse2.jc.g(jc.java:257) at com.ibm.jsse2.jc.a(jc.java:361) at com.ibm.jsse2.jc.startHandshake(jc.java:304) Here is my spring config: .*_EXPORT_.* .*_EXPORT1024_.* .*_WITH_DES_.* .*_WITH_NULL_.* .*_DH_anon_.* ]] -- View this message in context: http://old.nabble.com/SSL-Woes.-Can%27t-get-past-handshake_failure-messa ge-tp26163597p26163597.html Sent from the cxf-user mailing list archive at Nabble.com.
WSDLToJava Error
I maintain a CXF-interface to Microsofts HPC2008 webservice (meaning the WSDL exists in the wild), which we recently upgraded and I'm unable to build stubs off of the WSDL anymore. I've tried wsdltojava from 2.3 and 2.4, but I get the same error. It's a WS-Addressing error of some sort, but I'm not sure if it's a CXF bug. The WSDL provides an import for WS-A: xsd:import schemaLocation=http://hostname/WSDL?xsd=xsd5; namespace=http://www.w3.org/2005/08/addressing; / Which refers to a partial schema I've pasted at the bottom of the email. If I change that import to point to a local ws-addr.xsd taken from the W3 site then the service builds and works OK. The provided schema is missing these entries, which I suspect is what breaks things. xs:element name=ReplyTo type=tns:EndpointReferenceType/ xs:element name=From type=tns:EndpointReferenceType/ xs:element name=FaultTo type=tns:EndpointReferenceType/ xs:element name=To type=tns:AttributedURIType/ xs:element name=Action type=tns:AttributedURIType/ I can provide a test case and put in a JIRA ticket if the dev's think this is a CXF bug. Thanks, Nate Partial WS-A schema: xs:schema elementFormDefault=qualified targetNamespace=http://www.w3.org/2005/08/addressing; xs:complexType name=EndpointReferenceType xs:sequence xs:element minOccurs=0 maxOccurs=1 name=Address type=tns:AttributedURIType/ xs:element minOccurs=0 maxOccurs=1 name=ReferenceParameters type=tns:ReferenceParametersType/ xs:element minOccurs=0 maxOccurs=1 name=Metadata type=tns:MetadataType/ xs:any minOccurs=0 maxOccurs=unbounded namespace=##other/ /xs:sequence xs:anyAttribute/ /xs:complexType xs:complexType name=AttributedURIType xs:simpleContent xs:extension base=xs:anyURI xs:anyAttribute/ /xs:extension /xs:simpleContent /xs:complexType xs:complexType name=ReferenceParametersType xs:sequence xs:any minOccurs=0 maxOccurs=unbounded/ /xs:sequence xs:anyAttribute/ /xs:complexType xs:complexType name=MetadataType xs:sequence xs:any minOccurs=0 maxOccurs=unbounded/ /xs:sequence xs:anyAttribute/ /xs:complexType /xs:schema
RE: WSDLToJava Error
Sorry, thought I'd included the stack trace initially. The -noAddressBinding allows wsdl2java to finish successfully, but looks like it breaks things. At the very least the existing code doesn't work and like you say I've got a workaround with replacing the Addressing schema. Thanks, Nate [java] Loading FrontEnd jaxws ... [java] Loading DataBinding jaxb ... [java] wsdl2java -client -d src -verbose http://hostname/WSDL?wsdl [java] wsdl2java - Apache CXF 2.2.4 [java] WSDLToJava Error: Thrown by JAXB : SCD wsa:From didnt match any schema component at line 32 column 28 of schema jar:file:/C:/Documents%20and%20Settings/nate/Desktop/apache-cxf-2.2.4/li b/cxf-2.2.4.jar!/org/apache/cxf/tools/wsdlto/databinding/jaxb/W3CEPRJaxb Binding.xml [java] org.apache.cxf.tools.common.ToolException: Thrown by JAXB : SCD wsa:From didnt match any schema component at line 32 column 28 of schema jar:file:/C:/Documents%20and%20Settings/nate/Desktop/apache-cxf-2.2.4/li b/cxf-2.2.4.jar!/org/apache/cxf/tools/wsdlto/databinding/jaxb/W3CEPRJaxb Binding.xml [java] at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error (JAXBBindErrorListener.java:35) [java] at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerIm pl.java:286) [java] at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.jav a:77) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.reportError(SCD BasedBindingSet.java:255) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.reportError(SCD BasedBindingSet.java:246) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.access$100(SCDB asedBindingSet.java:74) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.apply(SC DBasedBindingSet.java:154) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.applyAll (SCDBasedBindingSet.java:138) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.apply(SC DBasedBindingSet.java:159) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.applyAll (SCDBasedBindingSet.java:138) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.access$7 00(SCDBasedBindingSet.java:82) [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedB indingSet.java:237) [java] at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:522) [java] at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImp l.java:236) [java] at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImp l.java:85) [java] at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize( JAXBDataBinding.java:328) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJava Container.java:568) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaCo ntainer.java:219) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai ner.java:127) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai ner.java:263) [java] at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java: 103) [java] at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) [java] at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86) [java] at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:184) [java] Caused by: com.sun.istack.SAXParseException2: SCD wsa:From didnt match any schema component [java] at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.reportError(SCD BasedBindingSet.java:252) [java] ... 20 more -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Tuesday, October 27, 2009 2:27 PM To: users@cxf.apache.org Cc: Nate Woody Subject: Re: WSDLToJava Error It's possible that the modified schema is causing issues. What's the stack trace if you run wsdl2java with -v? Also, you can try adding: -noAddressBinding to wsdl2java to turn off the internal mapping of the ws-addressing schema into javax.xml.ws.wsaddressing types. It would actually generate types for stuff in the schema which may or may not be appropriate for what you need to accomplish, but worth a shot. That said, using a catalog or something to map that schemaLocation to a local xsd is probably the best option. Dan On Tue October 27 2009 9:19:43 am Nate Woody wrote: I maintain a CXF-interface to Microsofts HPC2008 webservice (meaning the WSDL exists in the wild), which we recently upgraded and I'm unable to build stubs off of the WSDL anymore. I've tried wsdltojava from 2.3 and 2.4, but I get the same error. It's a WS-Addressing error of some sort, but I'm
WSS with SSL configuration problem ClassCastException in decorateWithTLS
Hello, I should probably first admit I'm trying to do something stupid, I have written a CXF client to a WSS (username token) web service, which I have packaged up into a jar to enable use of the service from Matlab. Thanks to previous help, the client appears to work fine except when I try to call the functionality from inside Matlab, where I get a ClassCastException when the SSL socket is being created. I know this isn't really a CXF issue, but I'm hoping someone can diagnose the error to point me where the configuration is broken. The same code works fine from outside matlab, so it seems like this must be a configuration problem of some kind. The problem only appears when using WSS, a client to a non-WSS service using the same platform works fine. Info: CXF-2.2.3 snapshot, Java 1.6.0_04-b12 The client does claim to find cxf.xml, I packaged this in the root of the jar, is this appropriate? [INFO] ControlledValidationXmlBeanDefinitionReader - Loading XML bean definitions from class path resource [cxf.xml] The logging from the service call and stack trace are provided below. Thanks in advance, Nate The stack trace follows below: Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suites have not been configured, falling back to cipher suite filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suite filters have not been configured, falling back to default filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersFromList INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. Jul 15, 2009 10:17:15 AM 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.handleMessage(MessageSenderInterceptor.java:48) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121) at $Proxy44.createActivity(Unknown Source) at edu.cornell.cac.tuc.matlab.JSDLMediator.jobStart(JSDLMediator.java:97) Caused by: javax.imageio.IIOException: Error while initializing secure socket at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:148) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:497) at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) ... 8 more Caused by: java.lang.IllegalArgumentException: Error decorating connection class ice.https.HttpsURLConnection at org.apache.cxf.transport.https.HttpsURLConnectionFactory.decorateWithTLS(HttpsURLConnectionFactory.java:255) at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:140) ... 10 more Caused by: java.lang.ClassCastException at java.lang.Class.cast(Unknown Source) at org.apache.cxf.transport.https.HttpsURLConnectionFactory.decorateWithTLS(HttpsURLConnectionFactory.java:250) ... 11 more javax.xml.ws.soap.SOAPFaultException: Could not send Message. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141) at $Proxy44.createActivity(Unknown Source) at edu.cornell.cac.tuc.matlab.JSDLMediator.jobStart(JSDLMediator.java:97) Caused by: javax.imageio.IIOException: Error while initializing secure socket at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:148) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:497) at
WSS with SSL configuration problem ClassCastException in decorateWithTLS
Hello, I should probably first admit I'm trying to do something stupid, I have written a CXF client to a WSS (username token) web service, which I have packaged up into a jar to enable use of the service from Matlab. Thanks to previous help, the client appears to work fine except when I try to call the functionality from inside Matlab, where I get a ClassCastException when the SSL socket is being created. I know this isn't really a CXF issue, but I'm hoping someone can diagnose the error to point me where the configuration is broken. The same code works fine from outside matlab, so it seems like this must be a configuration problem of some kind. The problem only appears when using WSS, a client to a non-WSS service using the same platform works fine. Info: CXF-2.2.3 snapshot, Java 1.6.0_04-b12 The client does claim to find cxf.xml, I packaged this in the root of the jar, is this appropriate? [INFO] ControlledValidationXmlBeanDefinitionReader - Loading XML bean definitions from class path resource [cxf.xml] The logging from the service call and stack trace are provided below. Thanks in advance, Nate The stack trace follows below: Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suites have not been configured, falling back to cipher suite filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suite filters have not been configured, falling back to default filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersFromList INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. Jul 15, 2009 10:17:15 AM 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.handleMessage(MessageSenderInterceptor.java:48) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121) at $Proxy44.createActivity(Unknown Source) at edu.cornell.cac.tuc.matlab.JSDLMediator.jobStart(JSDLMediator.java:97) Caused by: javax.imageio.IIOException: Error while initializing secure socket at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:148) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:497) at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) ... 8 more Caused by: java.lang.IllegalArgumentException: Error decorating connection class ice.https.HttpsURLConnection at org.apache.cxf.transport.https.HttpsURLConnectionFactory.decorateWithTLS(HttpsURLConnectionFactory.java:255) at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:140) ... 10 more Caused by: java.lang.ClassCastException at java.lang.Class.cast(Unknown Source) at org.apache.cxf.transport.https.HttpsURLConnectionFactory.decorateWithTLS(HttpsURLConnectionFactory.java:250) ... 11 more javax.xml.ws.soap.SOAPFaultException: Could not send Message. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141) at $Proxy44.createActivity(Unknown Source) at edu.cornell.cac.tuc.matlab.JSDLMediator.jobStart(JSDLMediator.java:97) Caused by: javax.imageio.IIOException: Error while initializing secure socket at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:148) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:497) at
RE: WSS with SSL configuration problem ClassCastException in decorateWithTLS
Eamonn, Thanks, I completely missed that wasn't a CXF class. A little rooting in the matlab classpath found the ice.* stuff and removing it solved the problem. I have to figure out what that's in there, but I know the problem now! More help than you expected! Thanks! Nate -Original Message- From: Eamonn Dwyer [mailto:eamdwyer...@hotmail.com] Sent: Wednesday, July 15, 2009 11:21 AM To: users@cxf.apache.org Subject: RE: WSS with SSL configuration problem ClassCastException in decorateWithTLS Hi Nate it looks like Matlab is using ice.https.HttpsURLConnection - it could be that this class is not an instance of Sun's HttpsURLConnection class. My guess is that when you run it outside of Matlab you are using the jdk's HttpsURLConnection class and that's why it works outside Matlab. I've no idea what the ice.https.HttpsURLConnection class is - I tried google'ing it for its API and couldn't find anything to help. Maybe you could check to see if Matlab is using ice.https.HttpsURLConnection and if there is a way to get Matlab to use the JDK's HttpsURLConnection instead? Not much help I'm afraid. regards Eamonn Subject: WSS with SSL configuration problem ClassCastException in decorateWithTLS Date: Wed, 15 Jul 2009 10:49:24 -0400 From: na...@cac.cornell.edu To: users@cxf.apache.org Hello, I should probably first admit I'm trying to do something stupid, I have written a CXF client to a WSS (username token) web service, which I have packaged up into a jar to enable use of the service from Matlab. Thanks to previous help, the client appears to work fine except when I try to call the functionality from inside Matlab, where I get a ClassCastException when the SSL socket is being created. I know this isn't really a CXF issue, but I'm hoping someone can diagnose the error to point me where the configuration is broken. The same code works fine from outside matlab, so it seems like this must be a configuration problem of some kind. The problem only appears when using WSS, a client to a non-WSS service using the same platform works fine. Info: CXF-2.2.3 snapshot, Java 1.6.0_04-b12 The client does claim to find cxf.xml, I packaged this in the root of the jar, is this appropriate? [INFO] ControlledValidationXmlBeanDefinitionReader - Loading XML bean definitions from class path resource [cxf.xml] The logging from the service call and stack trace are provided below. Thanks in advance, Nate The stack trace follows below: Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suites have not been configured, falling back to cipher suite filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersuites INFO: The cipher suite filters have not been configured, falling back to default filters. Jul 15, 2009 10:17:15 AM org.apache.cxf.transport.https.SSLUtils getCiphersFromList INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. Jul 15, 2009 10:17:15 AM 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.handleMessage(Messag eSenderInterceptor.java:48) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:236) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121) at $Proxy44.createActivity(Unknown Source) at edu.cornell.cac.tuc.matlab.JSDLMediator.jobStart(JSDLMediator.java:97) Caused by: javax.imageio.IIOException: Error while initializing secure socket at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnectio n(HttpsURLConnectionFactory.java:148) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:497) at
NPE from WSDL2Java
Hello, I'm getting a NPE while running WSDL2Java on a wsdl. (FYI, this is the Windows HPC 2008 services for remote submission of jobs to their clustering software, so it's a in-the-wild wsdl). This looks very much like the problem reported here: http://www.nabble.com/wsdl2java-NullPointer-tp19720254p19720254.html but I wasn't able to figure a solution based on the output of that thread. Related forum posts suggests it has to do with JAXB binding issues, but I'm none too sure. Background: I'm using CXF 2.2.2 with JDK 1.6.0_07 and I've verified I have no problem building stubs against other WSDLs (my cxf configuration is most likely not broken) and I was able to run the axis2 wsdl2java against the wsdl (it's likely the WSDL isn't horribly broken). The wsdl has two imports, one of which imports additional xsd's. I've linked the lot of them below: Wsdl: http://sites.google.com/site/cacviz/webdocs/bes-factory.wsdl?attredirect s=0 Bundle with wsdl and all xsds: http://sites.google.com/site/cacviz/webdocs/wsdl_bundle.zip?attredirects =0 I figure the zip is less annoying then 6 separate links. I'm not sure what direction to go in to resolve this and I'd really like to get this working from an CXF client. Can anyone out there give me a hand on what might be the problem? Thanks in advance, Nate Output: apache-cxf-2.2.2\bin\wsdl2java -verbose -client bes-factory.wsdl Loading FrontEnd jaxws ... Loading DataBinding jaxb ... wsdl2java -verbose -client bes-factory.wsdl wsdl2java - Apache CXF 2.2.2 WSDLToJava Error: java.lang.NullPointerException org.apache.cxf.tools.common.ToolException: java.lang.NullPointerException at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon tainer.java:260) at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.ja va:83) at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103) at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:173) Caused by: java.lang.NullPointerException at org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.annotat or.WSActionAnnotator.annotate(WSActionAnnotator.java:97) at org.apache.cxf.tools.common.model.JavaMethod.annotate(JavaMethod.java :368) at org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.Operati onProcessor.process(OperationProcessor.java:68) at org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.PortTyp eProcessor.process(PortTypeProcessor.java:143) at org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProces sor.wsdlDefinitionToJavaModel(WSDLToJavaProcessor.java:88) at org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProces sor.process(WSDLToJavaProcessor.java:60) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJav aContainer.java:218) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon tainer.java:127) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon tainer.java:252) ... 3 more
RE: NPE from WSDL2Java
Wow! Thanks for the fix! I'll grab the snapshot in the morning and let you
know how it goes.
Thanks again as I ignore the humiliation of you apparently figuring this out in
about 20 seconds.
Best,
Nate
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Tue 6/30/2009 3:43 PM
To: users@cxf.apache.org
Cc: Nate Woody
Subject: Re: NPE from WSDL2Java
I just fixed this on trunk. I'll get it merged down to 2.2.x and 2.1.x
branches shortly.
It's a bug in the processing of extensors on the wsdl:fault elements. It
assumes that there is a {http://www.w3.org/2006/05/addressing/wsdl}Action
extensor on it if there are any extensors there.In your case, your action
is in the older 2005/08 namespace and thus it doesn't work.
I DID put a guard there to prevent the NPE. However, that won't result in
the the Action annotations being generated as those are only done for the
2006/05 namespace.
Dan
On Tue June 30 2009 2:25:41 pm Nate Woody wrote:
Hello,
I'm getting a NPE while running WSDL2Java on a wsdl. (FYI, this is the
Windows HPC 2008 services for remote submission of jobs to their
clustering software, so it's a in-the-wild wsdl). This looks very much
like the problem reported here:
http://www.nabble.com/wsdl2java-NullPointer-tp19720254p19720254.html but
I wasn't able to figure a solution based on the output of that thread.
Related forum posts suggests it has to do with JAXB binding issues, but
I'm none too sure.
Background: I'm using CXF 2.2.2 with JDK 1.6.0_07 and I've verified I
have no problem building stubs against other WSDLs (my cxf configuration
is most likely not broken) and I was able to run the axis2 wsdl2java
against the wsdl (it's likely the WSDL isn't horribly broken).
The wsdl has two imports, one of which imports additional xsd's. I've
linked the lot of them below:
Wsdl:
http://sites.google.com/site/cacviz/webdocs/bes-factory.wsdl?attredirect
s=0
Bundle with wsdl and all xsds:
http://sites.google.com/site/cacviz/webdocs/wsdl_bundle.zip?attredirects
=0
I figure the zip is less annoying then 6 separate links. I'm not sure
what direction to go in to resolve this and I'd really like to get this
working from an CXF client. Can anyone out there give me a hand on what
might be the problem?
Thanks in advance,
Nate
Output:
apache-cxf-2.2.2\bin\wsdl2java -verbose -client bes-factory.wsdl
Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -verbose -client bes-factory.wsdl
wsdl2java - Apache CXF 2.2.2
WSDLToJava Error: java.lang.NullPointerException
org.apache.cxf.tools.common.ToolException:
java.lang.NullPointerException
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon
tainer.java:260)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.ja
va:83)
at
org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
at
org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:173)
Caused by: java.lang.NullPointerException
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.annotat
or.WSActionAnnotator.annotate(WSActionAnnotator.java:97)
at
org.apache.cxf.tools.common.model.JavaMethod.annotate(JavaMethod.java
:368)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.Operati
onProcessor.process(OperationProcessor.java:68)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.PortTyp
eProcessor.process(PortTypeProcessor.java:143)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProces
sor.wsdlDefinitionToJavaModel(WSDLToJavaProcessor.java:88)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProces
sor.process(WSDLToJavaProcessor.java:60)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJav
aContainer.java:218)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon
tainer.java:127)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon
tainer.java:252)
... 3 more
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
