You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2008/10/03 21:51:50 UTC
Re: Proposal for a new JMS configuration for CXF
Hi Willem,
after completing the change to Spring JMS for the JMS transport I will
now tackle the configuration problem again.
I would also recommend thinking about a broader change of configuration
style. But I am unsure how to really do it. Can you elaborate a little
further how you would add the TransportConfig to the endpoint?
I would like to be able to configure the TransportConfig in the spring
client or endpoint definition definition. Where would I add the property
and how would I transport this information to the Conduit.
The current configs are added to the EndpointInfo from WSDL or Conduit /
Destination definitions. How would I connect this when the config is
added to client or endpoint?
I think we could introduce the new config style in parallel for 2.x and
if it is better than the current config could turn this off in 3.0. In
the JMS transport I have prepared all to be able to do this.
Greetings
Christian
Willem Jiang schrieb:
> Hi Christian,
>
> +1 for introducing the Camel style URL for the JMS configuration.
> In Camel, you just need to specify the jms component's connection
> factory, then the JMS component can take care of the URL itself.
>
> In you proposal , we need to add a TransportConfig element for the
> endpoint which could contain the Transport specified configuration for
> the JMSConduit or JMSDestination.
> I think we could go further, as you know for the HttpJettyDestination
> , there need to do some configuration for JettyServerEngine which is
> also a transport level configuration.
> We could also set the URLConnection factory for the HttpConduit in
> this way.
>
> Since most current CXF configration are based on parser an XML to Java
> Object by JAXB and few Spring style bean class injection.
> If we introduce the TransportConfig element and lots of transport
> configuration could be changed.
> Maybe we can do this in CXF 3.0.
>
> Any thoughts?
>
> Willem
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Proposal for a new JMS configuration for CXF
Posted by Eoghan Glynn <eo...@iona.com>.
Daniel Kulp wrote:
>> - 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.
>
> Well, this COULD actually remove that limitation. A FailoverSelector
> could have a bunch of conduits configured via configuration (like
> roundrobin) and failover from one to the other. Thus, the failover
> stuff would work for code first cases much better. If the
> FailoverSelector doesn't have any conduits coming in from spring, it
> could use the multi-port strategy it currently uses.
Yeah, that makes sense all right in the particular case of the alternate
addresses being taken from the WSDL. Encoding the alternate addresses in
<wsdl:port>s versus configuring the same info in the <jaxws:conduit>
would be similar strategies in the sense that in both cases the cluster
is statically defined (i.e. of fixed size and membership, modulo changes
to WSDL or config, which would generally require a restart/refresh in
the client).
But I also had in mind the case where the addresses are retrieved
dynamically from some external agency, such as a registry service. I've
built an example of this approach in another project which is layered
over CXF. In this case the cluster is dynamically assembled, and no
specific addressing info is statically burned into the client's WSDL (or
config).
Now in this latter case, there's a slightly different possible use-case
for the <jaxws:conduit> wiring. Instead of using this mechanism to
inject the target addresses (and other config) for individual conduits,
we could instead have a place-holder "abstract" conduit bean containing
only non-address config to be used for any concrete conduit instance (of
a particular type) created for this proxy over its lifetime, including
any failover events.
So for example, suppose I wanted to ensure that AllowChunking was always
set to false for a particular proxy because I suspect there's a bug in
the server-side stack's support for HTTP chunking (real-life example
from our own in-house interop testing). And say I'm using my
registry-mediated faliover strategy. In this case it would be neat to
just do something like:
<jaxws:client name="{http://apache.org/hw}MyPort">
<clustering:failover>
<clustering:strategy>
<ref bean="RegistryMediated"/>
</clustering:strategy>
</clustering:failover>
<jaxws:conduit>
<http:conduit name="{http://apache.org/hw}MyPort.http-conduit"
abstract="true">
<http:client AllowChunking="false"/>
</http:conduit>
</jaxws:conduit>
...
</jaxws:client>
and have the AllowChunking="false" applied to *any* HTTP conduit created
for this proxy over its lifetime.
Cheers,
Eoghan
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Proposal for a new JMS configuration for CXF
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 06 October 2008, Eoghan Glynn wrote:
> - 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)
I think Christian's latest proposal covers this. In the "Upfront" case,
the Upfront bean can only contain a single conduit. The "RoundRobin"
would have a List of conduits, etc... Each selector would have it's
own configuration requirements. Spring could validate that the
requirements are met.
> - 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.
Well, this COULD actually remove that limitation. A FailoverSelector
could have a bunch of conduits configured via configuration (like
roundrobin) and failover from one to the other. Thus, the failover
stuff would work for code first cases much better. If the
FailoverSelector doesn't have any conduits coming in from spring, it
could use the multi-port strategy it currently uses.
Dan
>
> Cheers,
> Eoghan
>
> 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-
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 str
> >> 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
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Proposal for a new JMS configuration for CXF
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: Proposal for a new JMS configuration for CXF
Posted by Eoghan Glynn <eo...@iona.com>.
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.
Cheers,
Eoghan
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
Re: Proposal for a new JMS configuration for CXF
Posted by Daniel Kulp <dk...@apache.org>.
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?
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Proposal for a new JMS configuration for CXF
Posted by Christian Schneider <ch...@die-schneider.net>.
Willem Jiang schrieb:
> Hi Christian,
>
> Current CXF configuration support the wildcard naming. If you want to
> share the configuration between several endpoints' conduits, you could
> using the * in the name attribute of conduit or destination.
> I agree we could do improvement on the current CXF configuration which
> doesn't provide a straight way for endpoint or client to configure the
> transport level objects.
> Since we have to support the old configure way for current user in the
> coming up release version, adding a property on the EndpointInfo could
> be a safe and quick way for the change.
>
> Here is another question for doing the transport configure from WSDL ?
> I don't do how could we put the transport configure property in the
> WSDL, and we still need to support it in the CXF future release.
>
I would not support the JMSConfiguration in WSDL. Of course we could try
to make a schema for it. But many aspects like setting a TaskExecutor
can not be done in the WSDL. So I would leave to old configuration for
WSDLs as is for the short run. To support a new WSDL config style I
would try to implement the SOAP/JMS spec. It looks quite nice and would
be a real standard. The implementation would build a JMSConfiguration
object out of the information from the SOAP/JMS conforming WSDL.
Greetings
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Proposal for a new JMS configuration for CXF
Posted by Willem Jiang <wi...@gmail.com>.
Hi Christian,
Current CXF configuration support the wildcard naming. If you want to
share the configuration between several endpoints' conduits, you could
using the * in the name attribute of conduit or destination.
I agree we could do improvement on the current CXF configuration which
doesn't provide a straight way for endpoint or client to configure the
transport level objects.
Since we have to support the old configure way for current user in the
coming up release version, adding a property on the EndpointInfo could
be a safe and quick way for the change.
Here is another question for doing the transport configure from WSDL ?
I don't do how could we put the transport configure property in the
WSDL, and we still need to support it in the CXF future release.
Regards,
Willem
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?
>>
>
Re: Proposal for a new JMS configuration for CXF
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: Proposal for a new JMS configuration for CXF
Posted by Willem Jiang <wi...@gmail.com>.
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?
On Sat, Oct 4, 2008 at 3:51 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> Hi Willem,
>
> after completing the change to Spring JMS for the JMS transport I will now
> tackle the configuration problem again.
>
> I would also recommend thinking about a broader change of configuration
> style. But I am unsure how to really do it. Can you elaborate a little
> further how you would add the TransportConfig to the endpoint?
> I would like to be able to configure the TransportConfig in the spring
> client or endpoint definition definition. Where would I add the property and
> how would I transport this information to the Conduit.
> The current configs are added to the EndpointInfo from WSDL or Conduit /
> Destination definitions. How would I connect this when the config is added
> to client or endpoint?
>
> I think we could introduce the new config style in parallel for 2.x and if
> it is better than the current config could turn this off in 3.0. In the JMS
> transport I have prepared all to be able to do this.
>
> Greetings
>
> Christian
>
> Willem Jiang schrieb:
>
>> Hi Christian,
>>
>> +1 for introducing the Camel style URL for the JMS configuration.
>> In Camel, you just need to specify the jms component's connection factory,
>> then the JMS component can take care of the URL itself.
>>
>> In you proposal , we need to add a TransportConfig element for the
>> endpoint which could contain the Transport specified configuration for the
>> JMSConduit or JMSDestination.
>> I think we could go further, as you know for the HttpJettyDestination ,
>> there need to do some configuration for JettyServerEngine which is also a
>> transport level configuration.
>> We could also set the URLConnection factory for the HttpConduit in this
>> way.
>>
>> Since most current CXF configration are based on parser an XML to Java
>> Object by JAXB and few Spring style bean class injection.
>> If we introduce the TransportConfig element and lots of transport
>> configuration could be changed.
>> Maybe we can do this in CXF 3.0.
>>
>> Any thoughts?
>>
>> Willem
>>
>
> --
>
> Christian Schneider
> ---
>
> http://www.liquid-reality.de
>
>