cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: Configuration APIs
Date Mon, 28 Aug 2006 16:24:39 GMT
Hani Suleiman wrote:
> On Aug 28, 2006, at 4:52 AM, Andrea Smyth wrote:
>>> I do see that you have the ability to search the service model for 
>>> configuration values, like the HTTPServicePolicy, but I don't like 
>>> the way it is done. It goes back to the things I said in the first 
>>> email about why we shouldn't be doing 
>>> Configuration/ConfigurationProvider stuff. It isn't friendly for 
>>> testing, embedding, api users, etc and creates unnecessary 
>>> indirection.  I'd much prefer the following method of finding the 
>>> apropriate HTTPServerPolicy:
>>> HTTPServerPolicy policy = endpoint.get(HTTPServicerPolicy.class);
>>> if (policy == null) getServicePolicy(); // the the server policy 
>>> that was injected in the constructor (see above)
>> It effectively means we are not using the Configuration API any more. 
>> As for the ConfigurationProviderAPI - they are generalised versions 
>> of the lookup you described earlier. Use of the ConfigurationProvider 
>> would be restricted to the generated POJOs, client code only uses the 
>> getters and would be uncluttered from many:
>> if (<not injected>) {
>>    // get it from somewhere else
>> }
>> (or, depending on what should take precedence) :
>> if (<can't get it from somewhere else>) {
>>    // use injected value
>> }
> I don't like the above code, because it tries to mix two models for no 
> real benefit beyond sticking to a legacy approach.
> You're right though in that we're (well, that there's a suggestion to) 
> not using the configuration API anymore. Sticking to plain POJOs means 
> you don't need a configuration API, everything is wired 
> programatically, and components don't pull config, they have it pushed 
> into them. If you're really attached to the configuration mechanism as 
> it exists now, it would have to be reworked slightly to function more 
> as a container, that injects HTTPServerPolicy for example to whatever 
> thing needs it, using whatever existing mechanism you have to resolve 
> what the actual policy instance is.
> It seems somewhat silly to invent/spend time on a configuration API 
> when it's completely tangential to what this project's 
> strength/point/focus is. It makes a lot more sense to me to instead do:
> 1) Use sane defaults
> 2) Let containers that focus on this sort of thing do all the gruntwork.
+1 to what Hani said. Lets get rid of 
Configuration/ConfigurationProvider and focus on being a good services 

- Dan

Dan Diephouse
Envoi Solutions

View raw message