With Tomcat your SSL configuration will be defined with Tomcat and the web.xml (http://www.jroller.com/gmazza/entry/ssl_for_web_services), and the jaxws:endpoint element (if it has anything left in it) having a createdFromAPI value to "true" (I presently have a question on the CXF IRC on the default value of createdFromAPI, as it's not given in your documentation: http://cxf.apache.org/docs/jax-ws-configuration.html, but I think that flag will need to be added when on Tomcat.)
Glen On 06/26/2012 03:51 AM, Himanshu Gupta wrote:
Hey Thanks Glen, Thats exactly the plan. When we migrate from standalone java server to a standard app server, we would no longer need this embedded jetty stuff. Just to clarify, when you say, Endpoint.publish() is it a problem ?. We use end point spring beans now (using<jaxws:endpoint>. its a spring app), and I assume, this would still be the case when I use a standalone servlet container. Am I wrong with this assumption ? Thanks, On Mon, Jun 25, 2012 at 6:12 PM, Glen Mazza<[email protected]> wrote:Oh, no, CXF doesn't embed Tomcat in that manner, we use Jetty behind-the-scenes for that only. Sorry if I misunderstood your question. Regarding using embedded Jetty, that could just be me but I'm more comfortable seeing secure solutions implemented behind a standalone servlet container, JEE server or OSGi containers instead of relying on Endpoint.publish(). However, using standalone containers may still provide performance advantages, better logging, easier startup/shutdown, etc., so you might choose to upgrade to them in the future anyway. Glen On 06/25/2012 11:54 AM, Himanshu Gupta wrote:Hello Glen, From your blog it looks like, the embedded Tomcat could be used with test, and requires a war file or exploded war. I have a spring based java stand alone server. I intend to use the web server (embedded and in memory) in productive code. I cannot produce a war like structure. I am looking for something like "JettyHTTPTransportFactory" for Tomcat if possible. I would need something like<httpj:engine-factory> and engine, for Tomcat. PS : Is it not recommended to use embedded jetty in prod over ssl ?. That's one of the key ("highlighted") document over the cxf website :( Thanks, Himanshu. On Mon, Jun 25, 2012 at 5:25 PM, Glen Mazza<[email protected]> wrote: Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/****<http://www.jroller.com/gmazza/entry/**>junit_web_service_testing#****testtc<http://www.jroller.com/** gmazza/entry/junit_web_**service_testing#testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc> . Glen On 06/25/2012 11:10 AM, Himanshu Gupta wrote: Hello Glen,Thanks for the quick response. I am using scenario 2. With Scenario 2 and 1. not using "<sec:clientAuthentication want="true" required="true"/>" 2. importing the server sertificate on the JDK default keystore "cacerts" I could see the wsdl in the web browser. The client in the sample also works well. Also the Dynamic client also works, because it uses the default keystore (you cannot change it for dynamic clients). Everyone's Happy, but this means any one who needs to see the wsdl on the browser would need to do 2 (i.e. import server cert on the jre default keystore) :(( ... Problem seems to be solved, but any Insights (explanations) would be helpful. PS : Glen, to your previous question, we can not use standalone tomcat, as we have a standalone java server, and we need an embedded in memory solution. please let me know, if this could be done using tomcat just like jetty. Thanks, Himanshu. On Mon, Jun 25, 2012 at 4:42 PM, Glen Mazza<[email protected]> wrote: Himanshu, of the wsdl_first_https sample, which of the four scenarios areyou running--per that sample's README, scenarios 1 and 3 are supposed to fail due to lack of client credentials, while scenarios 2 and 4 should work. Also, is the problem with the running of the sample or just you viewing it from the browser? The blog entry you're referencing is from 2008 and covers the long-obsoleted CXF 2.1 (our lowest supported version is now 2.4), I would be surprised if that code still worked. I'm not much familiar with the Dynamic Client (I don't hear much about it today), whether it can/should work with HTTPS (the docs for it do not give that indication[1]), hopefully someone else can help you here or maybe the Nabble forums can help ( http://cxf.547215.n5.nabble.******com/template/NamlServlet.**jtp?**** macro=search_page&node=547216&******query=dynamic+client+ssl<**htt** p://cxf.547215.n5.nabble.com/****template/NamlServlet.jtp?**<http://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?**> macro=search_page&node=547216&****query=dynamic+client+ssl<htt** p://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?** macro=search_page&node=547216&**query=dynamic+client+ssl<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=547216&query=dynamic+client+ssl>).You might be better off with the more standard JAX-WS Dispatch method[2] if you can't use stub-based calls. Glen [1] http://cxf.apache.org/docs/******dynamic-clients.html<http://cxf.apache.org/docs/****dynamic-clients.html> <http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/**dynamic-clients.html> <http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-**clients.html> <http://**cxf.apache.org/docs/dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-clients.html> [2] http://www.jroller.com/gmazza/******entry/calling_rpc_encoded_** **web_**<http://www.jroller.com/gmazza/****entry/calling_rpc_encoded_**web_**> <http://www.jroller.**com/gmazza/**entry/calling_**rpc_encoded_web_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**> services<http://www.jroller.****com/gmazza/entry/calling_rpc_**** encoded_web_services<http://**www.jroller.com/gmazza/entry/** calling_rpc_encoded_web_**services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services> On 06/25/2012 10:02 AM, Himanshu Gupta wrote: Hello Colm,In the sample wsdl_first_https, I removed line<sec:clientAuthentication want="true" required="true"/> from the server configuration. The Client in the example works well. But the Firefox fails, and still gives error "javax.net.ssl.******SSLHandshakeException: no cipher suites in common" on the server. Please let me know, If you want me to try something specific. Sorry just looking for an appropriate solution :( Thanks, Himanshu. On Mon, Jun 25, 2012 at 3:57 PM, Colm O hEigeartaigh<coheigea@apache. **** ** org<[email protected]>>****wrote: Colm : I did add the certificates to for e.g. in the Firefox explicitly. Yes, you added the certificates so that the browser trusted theservice endpoint. However, as I explained in my previous mail, the service endpoint requires that the client presents its own certificate + private key for client authentication, hence the failure. Colm. On Mon, Jun 25, 2012 at 2:51 PM, Himanshu Gupta< [email protected] wrote:Hello Guys, Colm : I did add the certificates to for e.g. in the Firefox explicitly. Following http://aruld.info/programming-******ssl-for-jetty-based-cxf-******<http://aruld.info/programming-****ssl-for-jetty-based-cxf-****>services/<http://aruld.info/**programming-**ssl-for-jetty-** based-cxf-**services/<http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/> <http://aruld.info/****programming-ssl-for-jetty-**** based-cxf-services/<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/> <http://**aruld.info/programming-ssl-**for-jetty-based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/> for my Dynamic Client, I try to do somthing like below :1. JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.******newInstance();2. Client client = dcf.createClient("https://localhost:9001/******ApexCollateral/ing/services/**<https://localhost:9001/****ApexCollateral/ing/services/**> **<https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**> **> wss/agreementDemo/2.0?wsdl<**htt**ps://localhost:9001/**ApexCollateral/ing/services/****wss/agreementDemo/2.0?wsdl<htt** ps://localhost:9001/**ApexCollateral/ing/services/** wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl> ");3. configureSSLOnTheClient(******client); 4. Object[] res = client.invoke("******getAgreementDemoIdentifier", new Integer(1)); Theoretically it should have worked, but it fails with an exception like "org.apache.cxf.service.******factory.****** ServiceConstructionException: Could not resolve URL "https://localhost:9001/******someService/2.0?wsdl<https://localhost:9001/****someService/2.0?wsdl> <https://**localhost:9001/**someService/**2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl> <https://**localhost:9001/**someService/2.**0?wsdl<https:/** /localhost:9001/someService/2.**0?wsdl<https://localhost:9001/someService/2.0?wsdl> ".", while excetuing *line number 2 (*logs attached*) *that is even before line 3 where I could setup the truststore, manually. I really want to use the Dynamic Client approach in the test cases to testmy web services. I assume, along with the testing services, with thisapproach I also validate auto code generation for clients, which would be used eventually by the consumers (by exposed wsdls). Please help, Thanks, Himanshu. On Mon, Jun 25, 2012 at 2:51 PM, Glen Mazza<[email protected]> wrote: Personally, for SSL, I would recommend using a standalone servlet container like Tomcat to host your web service (http://www.jroller.com/**gmazza/entry/ssl_for_web_********services< http://www.jroller.com/gmazza/******entry/ssl_for_web_services<http://www.jroller.com/gmazza/****entry/ssl_for_web_services> **<http://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services> <h**ttp://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services> <http://www.jroller.**com/gmazza/entry/ssl_for_web_**services<http://www.jroller.com/gmazza/entry/ssl_for_web_services> ), I wouldn't rely on Endpoint.publish() for production, especially if you're using SSL. For your dynamic client, as the link above mentions, the certs willneed to be in the "cacerts" file used by the JRE that is running the dynamic client--or another truststore file that you configure--the browser is irrelevant as it's not being used there. HTH, Glen On 06/25/2012 07:46 AM, Himanshu Gupta wrote: Hello Experts, Quite new to CXF, having a usecase where I need to expose ourexisting services as webservices. App is a standalone server, so am using embeddedjetty with https. Everything works fine, except that when I hit theserverwith the wsdl url through a browser (any browser), I get "javax.net.ssl.********SSLHandshakeException: no cipher suites in common". This could be reproduced if you just run the wsdl_first_https server andhit the url https://localhost:9001/********SoapContext/SoapPort?wsdl<https://localhost:9001/******SoapContext/SoapPort?wsdl> <http**s://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl> <http**s://localhost:9001/******SoapContext/SoapPort?wsdl<http** s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl> <https://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl><http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl><http**s://localhost:9001/****SoapContext/SoapPort?wsdl<http** s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>. Please help escape this problem.Also the client in the wsdl_first_https works. But if I try to use the Dynamic Client (thats a requirement), it fails as well, as it could not find the wsdl. The Dynamic client looks somthing like below : JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.** newInstance(); Client client = dcf.createClient(" https://localhost:443/********someservice/2.0?wsdl<https://localhost:443/******someservice/2.0?wsdl> <https://**localhost:443/****someservice/**2.0?wsdl<https://localhost:443/****someservice/2.0?wsdl> <https://**localhost:443/****someservice/2.**0?wsdl<https:/** /localhost:443/**someservice/**2.0?wsdl<https://localhost:443/**someservice/2.0?wsdl> < https://localhost:443/******someservice/2.0?wsdl<https://localhost:443/****someservice/2.0?wsdl> <https://**localhost:443/**someservice/2.**0?wsdl<https://localhost:443/**someservice/2.0?wsdl><https://**localhost:443/**someservice/2.0?**wsdl<https:/** /localhost:443/someservice/2.**0?wsdl<https://localhost:443/someservice/2.0?wsdl><https://**localhost/******someservice/2.0?wsdl< https://localhost/someservice/******2.0?wsdl<https://localhost/someservice/****2.0?wsdl><https://**localhost/someservice/**2.0?**wsdl<https://localhost/someservice/**2.0?wsdl> <https://localhost/****someservice/2.0?wsdl<https://localhost/**someservice/2.0?wsdl> <https://**localhost/someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl> **>**> ");Object[] res = client.invoke(jnew QName("http://someNameSpace/<******h**ttp://somenamespace/< http://somenamespace/>","getSomeIdentifier"), new Integer(1));PS : I have already tried adding the certs to the browser. Thanks in Advance, -- Glen MazzaTalend Community Coders coders.talend.com blog: www.jroller.com/gmazza --Himanshu Gupta. --Colm O hEigeartaigh Talend Community Coder http://coders.talend.com --Glen Mazza Talend Community Coders coders.talend.com blog: www.jroller.com/gmazza --Glen Mazza Talend Community Coders coders.talend.com blog: www.jroller.com/gmazza-- Glen Mazza Talend Community Coders coders.talend.com blog: www.jroller.com/gmazza
-- Glen Mazza Talend Community Coders coders.talend.com blog: www.jroller.com/gmazza
