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
