cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Proposal for a new JMS configuration for CXF
Date Mon, 06 Oct 2008 21:50:51 GMT
Hi Dan,

that´s interesting I had never seen any other ConduitSelector than the 
Upfront conduitelector in practice. But I see it can be handy with http.

What about the following proposal:

<jaxws:client>
    <jaxws:conduitSelector>
        <upFrontConduitSelector" config-ref="jmsConfig"/>
    </jaxws:conduitselector>
</jaxws>

<jaxws:client>
    <jaxws:conduitSelector>
        <roundRobinConduitSelector">
            <config-ref="jmsConfig"/>
            <config-ref="jmsConfig2"/>
        <roundRobinConduitSelector">
    </jaxws:conduitselector>
</jaxws>

We already have the conduitSelector element. So we simply would have to 
add a property TransportConfig config to UpfrontConduitSelector. A 
RoundRobin Conduitselector would
of course need a list of configs.

Greetings

Christian

Daniel Kulp schrieb:
> I completely agree with MUCH of this.   I'd love it if the jaxws:client 
> and jaxws:endpoint/server things had a:
>
> <jaxws:conduit>
>     <bean ....... or jms or something>
> </jaxws:conduit>
>
> type thing that would configure that.   It's SLIGHTLY more complicated by 
> the presence of the conduit selector things in the client which allows 
> load balancing and such.   However, that could be made even more 
> configurable with something like:
>
> <jaxws:conduit selector="...RoundRobinSelector">
>     <bean ..../>
>     <bean ..../>
>     <bean ..../>
>     <bean ..../>
> </jaxws:conduit>
>
> (default would be the current "Upfront" selector.)
>
>
>
> Dan
>
>
>
> On Sunday 05 October 2008, Christian Schneider wrote:
>   
>> Hi Willem,
>>
>> if I understand it right there is always one conduit for each client
>> or endpoint. So I would not try to reference a conduit config via the
>> endpoint name like it is done now. The conduit can as well be
>> described as a parameter of client or endpoint. I really do not like
>> the way the old JMSConduit configured itself. Extracting the
>> configuration should be outside of the object to be configured.
>>
>> The way camel does this is ok. But instead of referencing a jms
>> configuration in the address line I would simply set it as a parameter
>> in client or endpoint. If you want to centralize certain parts of the
>> config spring still has the ref="" to reference a central config bean.
>> Additionally we can use abstract config beans so several jms
>> configurations can share some common parts.
>>
>> By simply being a property of the client or endpoint they can simply
>> add it to the endpointInfo. So the TransportFactory can extract it and
>> set the Conduit or Destination with it.
>>
>> Greetings
>>
>> Christian
>>
>> Willem Jiang schrieb:
>>     
>>> You could take a look at the configuration of camel transport for
>>> CXF. we inject the camel context (which could be an extension of
>>> TransportConfig) into the CamelTransportFactory or the
>>> {CamelConduit|CamelDestion}.
>>>
>>> Endpoint can find the CamelTransportFactory by using the transport
>>> id or transport perfix like 'camel:'.  Each Conduit or Destination
>>> configuration has its own id, when the endpoint find the transport
>>> factory and create the conduit or destination, current CXF
>>> configuration will call the 'configure' method which will seach the
>>> spring context and configure the conduit or destination according
>>> the bean id.
>>>
>>> If you want to add the TransportConfig into the endpoint , we need
>>> to hack the code of endpoint looking up the transport factory, and
>>> set the TransportConfig into the transport factory or the
>>> {conduit|destination}.
>>>
>>> Any thoughts?
>>>       
>
>
>
>   


-- 

Christian Schneider
---
http://www.liquid-reality.de


Mime
View raw message