cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <gma...@talend.com>
Subject Re: wsdl_first_https
Date Mon, 25 Jun 2012 16:12:20 GMT
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<gmazza@talend.com>  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<gmazza@talend.com>   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<coheigea@apache.org>>**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<himanshu.kgp@gmail.com
>>>>>>
>>>>>>   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<gmazza@talend.com>
>>>>>>> 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
>>
>>
>


-- 
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza


Mime
View raw message