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
