cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: Configuration APIs
Date Wed, 30 Aug 2006 16:26:12 GMT
Forgive me if I'm missing something, but it sounds a lot like the
proposed changes are potentially going to make writing configuration
much more verbose and therefore more complex. From a user's point of
view that is less than ideal.

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Wednesday, August 30, 2006 11:35 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Configuration APIs
> 
> Andrea Smyth wrote:
> > Dan Diephouse wrote:
> >
> >> Andrea Smyth wrote:
> >>
> >>> So assuming all configurable properties of the http client and
> >>> server transport are data members of HTTPConduit.java and
> >>> JettyHTTPDestination with corresponding getters/setters (whether
> >>> manually coded or inherited from a generated POJO, also assume
> >>> standard getters for now) - how can we use Spring (for example) to
> >>> run the ClientServerTest in the systest module with a non-default
> >>> value for the contextMatchStrategy field (picking this one as it's
> >>> of type String) - without changing the test code? Any other
> >>> properties of the transport and other objects (e.g. bus) should be
> >>> left at their defaults.
> >>>
> >>> We'll have something like:
> >>>
> >>> <bean id="?"
> >>> class="org.apache.cxf.transport.http.JettyHTTPDestination">
> >>>    <property name="contextMatchStrategy" value="stem"/>
> >>> </bean>
> >>>
> >>> But do we need other beans that reference this one? How should the
> >>> id(s) be chosen?
> >>> And what's the role of HTTPConduitFactory in this - is it not used
> >>> at all or is it used as a factory in the above bean definition?
Same
> >>> question for the BusFactory.
> >>>
> >>> Dan D. - it would help if you could sketch out the steps involved
-
> >>> or point to code for similar in XFire.
> >>>
> >>> Andrea.
> >>
> >>
> >> Hi Andrea,
> >>
> >> Sorry if I was being too vague.
> >>
> >> Lets start off with our baseline spring definitions (these would be
> >> defined in an xml somewhere
> >> <bean id="httpTransport">
> >>  <property name="serverPolicy" ref="servicePolicy"/>
> >> </bean>
> >>
> >> <bean id="serverPolicy" class="...HttpServerPolicy"/>
> >>
> >> <bean id="bus" class="org.apache.cxf.bus.CXFBus">
> >>  <constructor-arg>
> >>   <map>
> >>    <entry key="org.apache.cxf.transport.DestinationFactoryManager"
> >> value-ref="destinationFactorymanager"/>
> >> ...
> >>   </map>
> >>  </constructor-arg>
> >> </bean>
> >>
> >> <bean id="destinationFactoryManager"
> >> class="org.apache.cxf.transport.DestinationFactoryManagerImpl">
> >>  <property name="transports">
> >>   <list>
> >>     <entry ref="httpTransport">
> >> ...
> >>   </list>
> >>  </property>
> >> </bean>
> >>
> >> Now if we have a spring user all they need to override the policy
is:
> >>
> >> <import resource="/org/apache/cxf/spring/beans.xml"/>
> >>
> >> <bean id="serverPolicy" class="...HttpServerPolicy">
> >> .. override the defaults here.
> >> </bean>
> >>
> >> Similarily they could define their own list of transports. Or we
> >> could even help them by creating an abstract destination factory
> >> manager which they can extend.
> >>
> >> The abstract one:
> >> <bean id="abstractDestinationFactoryManager"
> >> class="org.apache.cxf.transport.DestinationFactoryManagerImpl"
> >> abstract="true">
> >>  <property name="transports">
> >>   <list>
> >>     <entry ref="httpTransport">
> >> ...
> >>   </list>
> >>  </property>
> >> </bean>
> >>
> >> The user's:
> >> <bean id="destinationFactoryManager"
> >> extends="abstractDestinationFactoryManager">
> >>  <property name="transports">
> >>    <list merge="true">
> >>      <entry ref="myTransport">
> >>   </list>
> >>  </property>
> >> </bean>
> >>
> >> So in summary, the user only modifies what they want and the
> >> policies, transports, bus, are all handled by Spring. Also, the
bean
> >> names don't really matter. If a user wants to override a bean in
our
> >> beans.xml, the will need to know that name, but it doesn't really
> >> matter what it is.
> >>
> >> - Dan
> >>
> > Hi Dan,
> >
> > OK, so this raises a couple of questions as to how our code is
> > supposed to digest this information:
> >
> > 1. The current bus factory (CXFBusFactory in rt-core) would have to
be
> > replaced by a SpringBusFactory which does not actually create a bus
> > itself but obtains it from an XmlBeanFactory (and similar for other
> > frameworks), right? And with the bus being the to level object this
> > would be the only place where we are interacting with the
> > XmlBeanFactory I assume.
> I suppose we could make a helper class like a SpringBusFactory which
> helps a user load in different ApplicationContexts. But there is no
> reason that we have to.
> > Where does that leave the bus extensions, i.e. the  recently
> > implemented component discovery mechanism?
> It wouldn't be used.
> > Could it ever be used in conjunction with an IOC style configuration
> > mechanism?
> I don't see why you would. IoC is doing the wiring for you.
> >
> > 2. DestinationFactoryManager does not manage actual Destinations but
> > DestinationFactories, so if anything  it'd have to be something
like:
> > <bean id="destinationFactoryManager"
> > class="org.apache.cxf.transport.DestinationFactoryManagerImpl">
> > <property name="destinationFactories">
> >   <map>
> >     <entry key="http://schemas.xmlsoap.org/wsdl/http/"
> > value-ref="HTTPDestinationFactory"/>
> >   <map>
> > </property>
> > </bean>
> > (again - how does this relate to the component discovery mechanism?)
> >
> Oops! Yes, you're right, that would be what needs to happen. And
again,
> there is no need for a component discover mechanism here because
Spring
> is doing it all for you.
> 
> We can also have the @PostConstruct & @Resource annotations help us in
> component discovery like they are now. For instance, take the JMS
> transport. To make it easier, we can do:
> 
> public class JMSTransport implements DestinationFactory {
>   @Resource DestinationFactoryManager dfm;
> 
>   @PostConstruct
>   public void registerDestination() {
>     dfm.register(namespaces, this);
>   }
> }
> 
> I think the HTTPTransport can already do this in fact. Then a user can
> import specific sections of the cxf spring files:
> 
> The basic beans:
> <import resource="/org/apache/cxf/spring/cxf.xml"/>
> The JMS beans:
> <import resource="/org/apache/cxf/jms/beans.xml"/>
> 
> Etc.
> 
> > Actual instances of  HTTP Destination could be stored in a
list-type
> > property of the http destination factory:
> >
> > <bean id="HTTPDestinationFactory"
> > class="org.apache.cxf.transports.http.HTTPTransportFactory">
> > <property name="destinations">
> >   <list merge="true">
> >     <entry ref="myDestination">
> >     <entry ref="anotherDestination">
> >  </list>
> > </property>
> > </bean>
> >
> > but that way they are not related to any specific endpoints. Suppose
> > the server had two endpoints, each using their own destination, and
we
> > wanted to configure those two destinations with different
> > HTTPServerPolicies. That seems to suggest the destinations should be
> > ref'd by their corresponding endpoint beans (of which we can't have
> > any in the default cxf.xml), as in:
> >
> > a) <bean
> > id="{http://apache.org/hello_world_soap_http}/SOAPService/SOAPPort"
> > class="<endpoint bean class>">
> >    <property name="destination" ref="myDestination"> </bean>
> >
> > or  the destinations instances are kept  in a map instead,  keyed
with
> > the id of the endpoint for which they are used
> >
> > b) <bean id="HTTPDestinationFactory"
> > class="org.apache.cxf.transports.http.HTTPTransportFactory">
> > <property name="destinations">
> >   <map>
> >     <entry
> > key="{http://apache.org/hello_world_soap_http}/SOAPService/SOAPPort"
> > value-ref="myDestination">
> >  </map>
> > </property>
> > </bean>
> >
> > In case a) the question is what for do we need the
DestinationFactory
> > and the DestinationFactoryManager at all. and in case b) the
> > implementation for the destination factory has to change so that
> > (given the id of the endpoint) it returns either a pre-injected
> > destination that can be used for the endpoint in question or else
> > instantiates a new one - right?
> > Ditto for bindings.
> >
> So this depends a bit on how we want to build up our services. One way
> is to have the ServiceBean register activate all the endpoints, and
then
> provide a reference to an EndpointBean which configures that specific
> Endpoint. The EndpointBean would participate in the service
construction
> via the a ServiceConfiguration for a ServiceFactory.
> 
> <bean id="helloWorldService"
> class="org.apache.cxf.jaxws.JaxWsServiceFactoryBean">
>  <property name="serviceClass" value="...HelloWorld"/>
>  <property name="bus" ref="bus"/>
>  <property name="endpoints">
>    <map>
>      <entry key="{endpoint}QName" ref="helloWorldEndpoint"/>
>    <map>
>  </property>
> </bean>
> 
> <bean id="helloWorldEndpoint"
class="org.apache.cxf.spring.EndpointBean">
>  <property name="properties">
>    <map>
>      <entry key="HTTPServerPolicy" ref="myServerPolicy"/>
>    <map>
>  </property>
> </bean>
> 
> OR we could have an EndpointBean which actually activates/starts the
> endpoint:
> 
> <bean id="helloWorldService"
> class="org.apache.cxf.jaxws.JaxWsServiceFactoryBean"
> factory-method="create">
>  <property name="serviceClass" value="...HelloWorld"/>
>  <property name="bus" ref="bus"/>
> </bean>
> 
> <bean id="helloWorldEndpoint"
class="org.apache.cxf.spring.EndpointBean">
>  <property name="service" ref="helloWorldService"/>
>  <property name="properties">
>    <map>
>      <entry key="HTTPServerPolicy" ref="myServerPolicy"/>
>    <map>
>  </property>
> </bean>
> 
> This all goes back to the contextual lookup. The Destination would be
> able to find the server policy via a search through the contexts.
> Eventually it would get to
endpointInfo.getProperty("HTTPServerPolicy")
> and the myServerPolicy bean would be retrieved. The same concept could
> be applied to bindings.
> 
> I think this has two advantages over a & b above. First, it doesn't
> require any special bean naming. Second, it doesn't require the
> transport to hold information about the service.
> 
> We could definitely add a lot of syntax sugar to all this so JAXB
> objects and other extensor are directly usable within Spring.
> 
> >
> > It is  not clear to me how you want to bridge the application
specific
> > (for which there are no defaults) with the common infrastructure
(all
> > the stuff in the default cxf.xml).
> I would see cxf.xml containing defaults for how things are wired
> together. The schema generated beans would be in the context too. So
the
> HTTPDestinationFactory could reference a default server policy bean.
And
> a specific HTTPDestination could reference another.
> 
> > As endpoints and services are always associated with a bus, would
the
> > bus bean not also have to be overwritten in the user.xml file to ref
> > those endpoint beans?
> No, because, the Endpoints & Services get built via the EndpointBean &
> JaxWsServiceFactoryBean.
> 
> BTW, I'm not  saying that it'd be a bad idea to have a simple built in
> discovery mechanism. In fact I think it would be a good thing so we
> don't require Spring.
> 
> Does this make more sense?
> 
> - Dan
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog



Mime
View raw message