Re: Proposal for a new JMS configuration for CXF
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Proposal for a new JMS configuration for CXF
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
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Proposal for a new JMS configuration for CXF
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
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
Hi Glen, thanks for the link to the spec. That´s astonishing they use quite the same URL format (IRI) I imagined. I had not read the spec before. Perhaps they were inspired by camel too ;-) But they strictly map the IRI to message headers and properties. So we probably should set our own parameters separately from the URL. The spec mostly talks about the configuration by WSDL. I think we should separate WSDL config from Spring config. The WSDL config typically is defined by standards authorities so I think we would give away flexibility if we take this format also for our own internal config. Instead I would map the WSDL config to our internal config. On the other hand we should make sure to implement all options that the Soap Jms spec defines. So implementing the spec will be quite easy. Best regards Christian Glen Mazza schrieb: Christian, I would take a look at the IBM document attached here: http://www.nabble.com/SOAP-JMS-binding-tool-changes-td19073747.html and the specification it links to: http://www.w3.org/Submission/SOAPJMS/ I'm unsure of the relation to these documents to what you're proposing, nor am I necessarily recommending we do what they do, but I'm mentioning this in case there is something important in these documents that you might have overlooked in your suggestions. Glen Christian Schneider wrote: Hi, after Glen´s Mail about my tutorial for setting up JMS for CXF with Apache Camel on the dev list there was a discussion about improvements for the JMS config for CXF. I have written a proposal how I think this could be done. My focus is only on the configuration syntax not the implementation but I think it can be done. Here is the link to the proposal. I would be very interested in your opinions about this style of configuration: http://www.liquid-reality.de/display/liquid/2008/08/30/Proposal+for+a+new+JMS+Transport+configuration+for+CXF Best regards Christian -- Christian Schneider --- http://www.liquid-reality.de -- Christian Schneider --- http://www.liquid-reality.de
