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
