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/**
> 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 are
>>> you 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?**
>>> 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>
>>> >
>>> [2]
>>> 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>
>>> >
>>>
>>>
>>>
>>> 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 the service
>>>>> 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-****
>>>>> 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/**>
>>>>>>
>>>>> 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>
>>>>>> >".",
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> test
>>>>>
>>>>> my web services. I assume, along with the testing services, with this
>>>>>> approach 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>
>>>>>> <h**ttp://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 will
>>>>>>> need
>>>>>>> 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 our
>>>>>>>> existing
>>>>>>>> services as webservices. App is a standalone server, so am using
>>>>>>>>
>>>>>>>> embedded
>>>>>>>
>>>>>> jetty with https. Everything works fine, except that when I hit the
>>>>>>
>>>>>>> server
>>>>>>>> with 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
>>>>>>>>
>>>>>>>> and
>>>>>>>
>>>>>> hit 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>
>>>>>> >
>>>>>>
>>>>>> <
>>>>>>>>
>>>>>>>>
>>>>>>>> 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>
>>>>>>> >
>>>>>>>
>>>>>> .
>>>>>> 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/****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 Mazza
>>>>>>> Talend 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
>
>
--
Himanshu Gupta.