cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hani Suleiman <>
Subject Re: Configuration APIs
Date Mon, 28 Aug 2006 15:07:32 GMT
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.

View raw message