cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Configuration
Date Wed, 24 Jan 2007 12:47:49 GMT
To sum up,  my main concerns are:

* Use of static APIs (I don't see how this can get around keeping 
references to the bus all over the place as the bus itself is not static).
* Reintroduction of configuration APIs - although IMO this would not be 
so bad,  Celtix has lived with cfg APIs long enough. I just find the 
idea surprising after the discussions that took place on this mailing 
list half a year earlier.
* If configuration APIs are reintroduced I would like to see them used 
consistently. If bean clients end up doing this:
T t = bean.getTValue();
in some places and:
T t = bus.getConfiguration(endpointInfo, defaultT, T.class);
or:
T t = bus.getConfiguration(endpointInfo, bean.getTValue(), T.class);
in others places I'd consider that a source of 
problems/inconsistencies.  But maybe others don't think it's as big 
problem as I think it is?

Andrea.

Some more comments below...

Dan Diephouse wrote:

> I wanted to make one more point explicit from my previous email. Both the
> current and the proposed approach require you to explicitly write code 
> which
> grabs configuration from the service model. In the current code this 
> takes
> the form of writing a ConfigurationProvider class and doing something 
> like
> this (from the JMS module)
>
>    public ServiceModelJMSConfigurationProvider(EndpointInfo i) {
>        info = i;
>    }
>
>    public Object getObject(String name) {
>
>        if (null == info) {
>            return null;
>        }
>
>        if ("server".equals(name)) {
>            return info.getExtensor(JMSServerBehaviorPolicyType.class);
>        }
> ...
>
> In the proposed approach this would just boil down to:
>
> setServer(bus.getConfiguration(endpointInfo, 
> defaultJMSServerBehaviorPolicy,
> JMSServerBehaviorPolicyType.class));

I don't know what are trying to get at by comparing the use of one API 
with the  implementation of another?

>
> Neither are 100% transparent, but the later seems a bit simpler to me.
>
> - Dan
>
>
> On 1/22/07, Dan Diephouse <dan@envoisolutions.com> wrote:
>
>>
>> OK, first let me try to give a little more context, as my last email was
>> rather vague. Then I'll try to answer your specific questions.
>>
>> In our current code we have a ConfigurationProvider mechanism. As I
>> understand the motivation for this as it allows configuration values 
>> to come
>> form places other than the bean itself. Supporting this use case is a 
>> Good
>> Thing.
>>
>> As I dug through Spring 2's documentation, I noticed the
>> BeanFactoryPostProcessor [1] and BeanPostProcessor interfaces [2]. These
>> allow customizing of how the beans are configured. One example of 
>> this bean
>> is the PropertyOverrideConfigurer bean. It can take values from a
>> properties file and override a bean's properties with them. Other 
>> examples
>> take configuration from web.xml files or from databases. Spring can 
>> take a
>> list of these BeanFactoryPostProcessors and they can be ordered. 
>> Since any
>> bean that takes configuration values goes through the Configurer or 
>> comes
>> from Spring itself, this means our configuration could be done via these
>> mechanisms.
>>
>> I'm thinking, this seems to do exactly what we want and so lets see 
>> if we
>> can reuse it instead of writing our own mechanism. The one notable 
>> problem
>> is how to wire in the service model.
>>
>> I'll divide our configuration sources into 3 areas: the bean (i.e.
>> HTTPDestinationConfigBean), the service model (i.e. EndpointInfo), and
>> "other stuff" (i.e. JDBC). And lets look at it in the context of our
>> favorite hypothetical example, the HTTPServerPolicy. Under the 
>> proposal we
>> would have a call like this in the AbstractHTTPDestination constructor:
>>
>> setServer(bus.getConfiguration(endpointInfo, new HTTPServerPolicy(),
>> HTTPServerPolicy.class));
>>
>> The resolution order would be like this:
>> 1. The default value - i.e. new HTTPServerPolicy();
>> 2. The value found on the service model - this would potentially be from
>> the WSDL.
>> 3. The value set on the bean in the config file
>
how can getConfiguration get the value of the bean in the config file 
with the given parametrization?

>> 4. The value set on the bean via "other stuff" aka
>> BeanFactoryPostProcessors/BeanPostProcessors
>>
>> Note that all the getConfiguration() method is doing is simply
>> encapsulating our service model traversing logic. So it would check the
>> endpointInfo, then the bindingInfo, then the ServiceInfo. If no value 
>> was
>> found, it would return the "new HTTPServerPolicy".
>>
>> I'm going to guess that the #1 objection toward this would be that the
>> resolution model isn't configurable. For instance I could have 
>> specified a
>> configuration in the WSDL, in a <bean> and in a property file. Which one
>> should CXF use? First, this highlights that in the current code there 
>> is no
>> way to merge these values at all as its kind of an all or nothing 
>> approach.
>
>> A ConfigurationProvider would simply grab the value from the service 
>> model
>> and give that to the HTTP transport. But, if we let Spring handle 
>> this, our
>> merging will occur automatically. Example:
>> 1. The value from the service model gets set on the JettyHTTPDestination
>> via our setServer(...) call above.
>> 2. There is a <property name="server.contentType" value="text/json"/> on
>> the Spring bean definition. This calls
>> getServer().setContentType("text/json") instead of creating a new
>> HTTPServerPolicy
>> 3. The -D...JettyHTTPDestination.server.receiveTimeout=300 property 
>> is set
>> from the command line. This operates similarly to #2.
>>
>> All three would then be merged into one HTTPServerPolicy object then. So
>> we have some added flexibility here IMO. Second, I don't know that I 
>> really
>> see any use cases for changing the ordering. This is partly because I 
>> don't
>> see multiple configuration sources being a case that occurs much (if 
>> at all?
>> Maybe wsdl + xml, or wsdl+properties, but I doubt all three). But also
>> because I'm not sure that I would want my WSDL to override what I set 
>> in my
>> xml config or specify via command line. If there are objections to the
>> ordering of the resolution, or it not being flexible enough, could you
>> please elaborate on some use cases?
>
Additional sources and in fact a more complicated lookup may come in 
with WS-Policy. A server endpoint's policy can come from the attachment 
of a policy to the port, portType, or binding element (i.e. different 
kind of navigation in the service model), combined with the effective 
policy for the service which apples to all of its endpoints.
There is also the option of external policy attachments, where you'd 
find policies along with an appliesTo that is expressed in the form of a 
URI domain expression, e.g.
<wsp:PolicyAttachment>
    <wsp:AppliesTo>
       
<wsp:URI>http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint)</wsp:URI>
    </wsp:AppliesTo>
  <wsp:Policy>
    <http:server>....</http:server>
  </wsp:Policy>
</wsp:PolicyAttachment>

WS-Policy vs. configuration is a big issue though, and I think we should 
focus on bringing the current discussion to an end,  it's been going on 
for too long. If changes will be needed in support of a common approach 
to configuration and WS-Policy we'll make them later.

>>
>> More comments inline...
>>
>> 1.
>> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/BeanFactoryPostProcessor.html

>>
>> 2.
>> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/BeanPostProcessor.html

>>
>>
>> On 1/22/07, Andrea Smyth < andrea.smyth@iona.com> wrote:
>> >
>> > Dan Diephouse wrote:
>> >
>> > > Hi All,
>> > >
>> > > Just wanted to propose something a bit more concrete via 
>> Configuration
>> > > before going about it. Basically we have these cases:
>> > > 1. Configuration comes from Spring XML
>> > > 2. Configuration comes from service model (WSDL, API)
>> > > 3. Configuration may come from some data source (Database, 
>> properties
>> > > file)
>> > >
>> > > Instead of the ConfigurationProvider approach we can simplify by
>> > > 1. Making beans just beans without our code generation customization
>> > > 2. Creating a method on the Bus to get configuration values:
>> > >
>> > > HTTPServerPolicy p = bus.getConfigurationValue(endpointInfo,
>> > > getDefaultHTTPServerPolicy(), HTTTPServerPolicy.class);
>> >
>> >
>> > Do you want to reintroduce configuration APIs -  what about 
>> testability?
>>
>>
>>  I don't think testability changes much from our current code to what 
>> this
>> proposal outlines. We set a value on our service model and then we run a
>> unit test to make sure the component used it.
>>
>> It looks like every bean client will need access to the bus ...
>>
>>
>> I'd consider making the getConfigurationValue method a static. The 
>> one use
>> case you had raised is that if you want to have a default value that 
>> is set
>> globally on the Bus (i.e. a Bus had a default HTTPServerPolicy). 
>> Although
>> I think that could just as easily be done with a BeanPostProcessor. 
>> So maybe
>> a static method is in order.
>>
>> Also not sure how this API is to be used, specifically
>> > a) when should a bean client use the bean's getter only/when should it
>> > use the bean's getter and/or the above API?
>>
>>
>> You would pretty much only use the getConfigurationValue if you 
>> needed to
>> get the value out of the service model. So its quite a bit different 
>> than
>> the original Configuration interface.
>>
>> b) where does the default value come from? In order to distinguish
>> > default value from in injected value ( i.e. value coming from 
>> sources 1.
>> > and 3. above) and value coming from service model it looks like every
>> > bean should have a
>> > T getTProperty();
>> > and a
>> > // no (public) setter for this one
>> > T getDefaultTProperty(); ?
>> > Where is the preference of injected value vs. default value vs. 
>> obtained
>> > from service model determined? IMO it's important this happens in one
>> > place only, and if it's in bus.getConfigurationValue(...) we need to
>> > pass both the default and the injected value.
>>
>>
>> See my explanation at the top.
>>
>> >
>> > > The method definition would be something like this:
>> > >
>> > > <T> T getConfigurationValue(AbstractPropertiesHolder, T 
>> defaultValue,
>> > > Class<T> type);
>> > >
>> > > This method would then search through the Bus, Endpoint, etc for the
>> > > HTTPServerPolicy value. If none is found the default value is
>> > returned.
>> >
>> > What do you mean with searching through the Bus?
>>
>>
>> See my above example of setting the HTTPServerPolicy on the Bus.
>>
>> >
>> > > You may ask, isn't it simpler to just call getHTTPServerPolicy() on
>> > the
>> > > current code? In actuality no, because we need to write
>> > > ConfigurationProviders which actually search the service model, 
>> so its
>> > > more
>> > > code.
>> >
>> > One generic ConfigurationProvider can be used in most if not all 
>> cases,
>> > and there would be no more code to that than there would be to the
>> > implementation of the above getConfigurationValue - in fact they'd be
>> > pretty much the same thing.
>> >
>> > Its not that ConfigurationProvider doesn't work, its that I want to 
>> have
>> Spring do as much of the work as possible and require as little
>> configuration code as possible for implementors.
>>
>> Cheers,
>> - Dan
>> -- 
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>
>
>


Mime
View raw message