Hi Dan,

Approach sounds good. I agree with you that getConfigurationValue()
method sounds a bit clunky. How about getConfigurationBean() or
getPolicyBean()? I have a feeling that whatever name you choose for this
generic method, it's going to sound a little flat; it'll never have the
resonance of a more specific method like getHTTPServerPolicy(). But
then, that's the trouble of any generic API...

Cheers,
Ade.

-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED] 
Sent: 18 January 2007 22:29
To: [email protected]
Subject: Configuration

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);

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.

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. Additionally it requires code customization for the beans which is
a
pain. This would be easier for people writing extensions to CXF to use.

The getConfigurationValue() method would delegate to a
ConfigurationManager
interface which would contain this method and allow people to plug in
different ways of doing resolution. For instance, by having the bus
always
override values.

Spring can actually take configuration from the database and properties
files, so I think this covers all our bases. And if the container can't
cover some edge case I think people can pretty easily override the
default
ConfigurationManager with their own.

(BTW, I'm not too keen on the getConfigurationValue name, so if you have
suggestions let me know)

Thoughts?
Cheers,

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Reply via email to