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 thecurrent 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 likethis (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?
how can getConfiguration get the value of the bean in the config file with the given parametrization?Neither are 100% transparent, but the later seems a bit simpler to me. - Dan On 1/22/07, Dan Diephouse <[EMAIL PROTECTED]> 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 Iunderstand the motivation for this as it allows configuration values to come form places other than the bean itself. Supporting this use case is a GoodThing. As I dug through Spring 2's documentation, I noticed the BeanFactoryPostProcessor [1] and BeanPostProcessor interfaces [2]. Theseallow customizing of how the beans are configured. One example of this beanis the PropertyOverrideConfigurer bean. It can take values from aproperties 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 comesfrom 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 problemis 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 ourfavorite hypothetical example, the HTTPServerPolicy. Under the proposal wewould 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
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.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 theendpointInfo, then the bindingInfo, then the ServiceInfo. If no value wasfound, it would return the "new HTTPServerPolicy". I'm going to guess that the #1 objection toward this would be that theresolution model isn't configurable. For instance I could have specified aconfiguration in the WSDL, in a <bean> and in a property file. Which oneshould 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, ourmerging 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 HTTPServerPolicy3. The -D...JettyHTTPDestination.server.receiveTimeout=300 property is setfrom the command line. This operates similarly to #2. All three would then be merged into one HTTPServerPolicy object then. Sowe 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 alsobecause I'm not sure that I would want my WSDL to override what I set in myxml 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?
<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.html2.http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/BeanPostProcessor.htmlOn 1/22/07, Andrea Smyth < [EMAIL PROTECTED]> 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 thisproposal 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 maybea 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 thanthe 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 haveSpring 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
