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 APIs
Date Mon, 28 Aug 2006 17:20:34 GMT
Dan Diephouse wrote:

> 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 
> framework.

Don't get me wrong - I am all for letting containers do the injection 
where they can, and I'm not that attached to the old Celtix 
configuration mechanism:)
But as long as frameworks such as Spring do not look up injectable 
resources in wsdl we do need to have code that does that kind of stuff 
instead. To minimize such additional code (check operation properties 
first, then endpoint properties, then service properties) and to 
encapsulate it I suggest enhancing the generated POJO with providers 
like so:
// generated getter
HTTPServerPolicy getHTTPServerPolicy() {
    if (null != httpServerPolicy ) {
       return httpServerPolicy;
   }
   return tryProviders(HTTPServerPolicy.class, "httpServerPolicy");
}
To me the getter seems a better place than repeatedly do that kind of 
lookup in application code, with the risk of omitting it in some 
locations, or using the wrong property name  ...
I would not call such a use of providers a 'configuration mechanism' at 
all - it's more an enhancement of an IOC based approach.

Andrea.

>
> - Dan
>


Mime
View raw message