cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Configuration APIs
Date Mon, 28 Aug 2006 18:02:55 GMT
You could use a @PostConstruct or any other mean (like the
spring InitializingBean#afterPropertiesSet) to check for null
properties and provide default values for them instead of doing
this logic in the getters.

On 8/28/06, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
> 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
> >
>
>


-- 
Cheers,
Guillaume Nodet

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message