cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <>
Subject Re: Proposal for a new JMS configuration for CXF
Date Mon, 06 Oct 2008 22:20:33 GMT

Hi Dan,

Dan Diephouse made a similar proposal about 18 months ago, and I was 
opposed at the time as it didn't accomodate what was trying to acheive 
with ConduitSelectors.

That discussion was also conflated with a bunch of other proposed 
changes, but in retrospect I think the <jaxws:conduit> bean had the 
essence of a really good idea.

So as long as support for the flexible conduit selection is maintained, 
I think this proposal would have potential.

Possible wrinkles would include things like:

- ensuring that the choice of conduit selector is validated against the 
presence or absence of fine-grained conduit beans, e.g. it wouldn't make 
sense to wire in any conduit beans at all when the deferred conduit 
selector is in use, as the whole idea here is to ensure that a conduit 
isn't created until we're sure we really need it (as we would never do 
so in the coloc case)

- ensuring the multiplicity of conduit beans configured alongside a 
failover selector is consistent with the set of ports defined in the 
WSDL, as the CXF static failover strategy is based on burning the 
alternate ports into a multi-port service definition in the WSDL.


Daniel Kulp wrote:
> 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?

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

View raw message