cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <ning.ji...@iona.com>
Subject Re: [jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint on httpj:engine-factory is not encoded in Spring
Date Fri, 07 Sep 2007 02:14:06 GMT
Hi

If the user still put the <http-conduit> bean  in the same configuration 
file with the <jaxws:client> we still can't walk around by specifying a 
bus in the configuration file.
It is a kind of cycle dependency  problem.

Willem.

Daniel Kulp wrote:
> Willem,
>
> I guess that's my point...  Should his configuration for the ProxyFactory 
> have a :
> <property name="bus" ref="cxf"/>
> to get the bus and then also a "depend-on" or similar to make sure the 
> bus and conduit configs are all set properly first?   I think just 
> adding the bus might do it.   Either that, or a depend-on="cxf" type 
> thing to say it depends on the bus.  That may allow the bus to be setup 
> first and set as the default bus before the proxy is created.  
>
> Dan
>
>
> On Thursday 06 September 2007, Willem Jiang wrote:
>   
>> Hi Dan,
>>
>> There are some differences between CXF-922 and CXF-955.
>> 1. The http-conduit bean object in CXF-922 just a object instance that
>> marshaled by JAXB, you still need use the ConfigureImpl which hold the
>> application context of the spring bean to set this object to the
>> httpConduit.
>>     The key issue of CXF-922 is that we setup the configureImpl with
>> the application context after the bus is loaded and at the same time
>> the HttpConduit is created by the ClientProxyFactoryBean which uses
>> the default bus instead.
>>     If we do not load the bus with the configuration file and set the
>> bus to the ClientProxyFactoryBean, we can't configure the http-conduit
>> as we wished.
>>
>> 2. In CXF-955, we create the JettyHTTPServerEngine , the
>> JettyHTTPServerEngineFactory directly in spring , and we just retrieve
>> the JettyHTTPServerEngineFactory when ServerFactoryBean create the
>> server. There is no ConfigureImpl as the mediation.  In this case we
>> just make sure the JettyHTTPServerEngine  and the
>> JettyHTTPServerEngineFactory are created before the ServerFactoryBean.
>> So the spring's depend-on help us :).
>>
>> I am just thinking about we could resolve the CXF-922 by the way that
>> CXF-955 did, that is to say we can take the dependency of the
>> ApplicationContext from the ConfigureImpl by creating the
>> ConfigureImpl in the spring context as the
>> JettyHTTPServerEngineFactory did (but I don't know how to pass the
>> beans instances to it yet) .
>>
>> Willem.
>>
>> Daniel Kulp wrote:
>>     
>>> Willem,
>>>
>>> Are you sure?   Looking at CXF-922, it looks VERY similar.   They
>>> are using the "bean" format, but most likely, the the non-bean
>>> format would have the same issue.   Could they add the depend-on
>>> thing to their bean and have that work?
>>>
>>> Dan
>>>
>>> On Wednesday 05 September 2007, Willem Jiang wrote:
>>>       
>>>> I just went through the patch, we still need to add the same
>>>> support for the jaxws:server and simple:server, I will work on it
>>>> :) Because it just work for the CXF server side, specially the
>>>> Jetty engine. I don't think it also relates to the client side.
>>>>
>>>> Willem.
>>>>
>>>> Daniel Kulp (JIRA) wrote:
>>>>         
>>>>>     [
>>>>> https://issues.apache.org/jira/browse/CXF-955?page=com.atlassian.j
>>>>> ir a.plugin.system.issuetabpanels:comment-tabpanel#action_12525274
>>>>> ]
>>>>>
>>>>> Daniel Kulp commented on CXF-955:
>>>>> ---------------------------------
>>>>>
>>>>>
>>>>> Fred: do you know if this also needs to be done for jaxws:server
>>>>> and simple:server or the clients?
>>>>>
>>>>>           
>>>>>> Implicit dependency from jaxws:endpoint on httpj:engine-factory
>>>>>> is not encoded in Spring
>>>>>> -----------------------------------------------------------------
>>>>>> -- ---------------------
>>>>>>
>>>>>>                 Key: CXF-955
>>>>>>                 URL:
>>>>>> https://issues.apache.org/jira/browse/CXF-955 Project: CXF
>>>>>>          Issue Type: Bug
>>>>>>            Reporter: Fred Dushin
>>>>>>         Attachments: cxf-955.patch
>>>>>>
>>>>>>
>>>>>> Suppose an application spring-loads a jaxws:endpoint, as in:
>>>>>> {{{
>>>>>> <jaxws:endpoint
>>>>>>         id="HttpsEndpoint"
>>>>>>         implementor="org.apache.cxf.systest.https.GreeterImpl"
>>>>>>         address="https://localhost:9001/SoapContext/SoapPort"
>>>>>>         serviceName="s:SOAPService"
>>>>>>         endpointName="e:SoapPort"
>>>>>>         xmlns:e="http://apache.org/hello_world"
>>>>>>         xmlns:s="http://apache.org/hello_world"/>
>>>>>> }}}
>>>>>> (IMPORTANT: Note the https protocol)
>>>>>> And suppose further the application tries to define the TLS
>>>>>> parameters for servicing listing on the IP port 9001, as follows:
>>>>>> {{{
>>>>>>     <httpj:engine-factory bus="cxf" id="foo">
>>>>>>         <!-- -->
>>>>>>         <!-- https://localhost:9001/... -->
>>>>>>         <!-- -->
>>>>>>         <httpj:engine port="9001">
>>>>>>             <httpj:tlsServerParameters>
>>>>>>                 <sec:keyManagers keyPassword="password">
>>>>>>                     <sec:keyStore type="jks"
>>>>>> resource="keys/server.jks" password="password"/>
>>>>>> </sec:keyManagers> <sec:trustManagers>
>>>>>>                     <sec:keyStore type="jks"
>>>>>> resource="keys/truststore.jks"/> </sec:trustManagers>
>>>>>>                 <sec:clientAuthentication want="true"
>>>>>> required="true"/> </httpj:tlsServerParameters>
>>>>>>         </httpj:engine>
>>>>>> }}}
>>>>>> What will happen is that jaxws:endpoint will get instantiated
>>>>>> before the httpj:engine-factory (at least on the JVM I am using).
>>>>>> This will cause the implicit endpoint.publish to fail, because at
>>>>>> the time the publish occurs, there are no TLS settings
>>>>>> established with the Bus for that physical port. The error you
>>>>>> will typically see is:
>>>>>> {{{
>>>>>> Caused by: java.io.IOException: Protocol mismatch: engine's
>>>>>> protocol is http, the url protocol is https }}}
>>>>>> We need to define an implicit (or explicit) Spring dependency
>>>>>> between these beans. A simple Spring "depends-on" would work, but
>>>>>> both elements are custom XML spring beans, so schema needs to be
>>>>>> modified, and the beans themselves need the DependsOn bean
>>>>>> attribute, at a minimum.  Additional work may be needed to inform
>>>>>> Spring of the actual dependency, so that it Does the Right Thing
>>>>>> (r), and instantiates the httpj:engine-factory before the
>>>>>> jaxws:endpoint. I have a test case for this, which I will provide
>>>>>> a patch for shortly (if I can't figure out how to fix the issue).
>>>>>>             
>
>
>
>   

Mime
View raw message