Dan Diephouse wrote:
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);
Do you want to reintroduce configuration APIs - what about testability?
It looks like every bean client will need access to the bus ...
Also not sure how this API is to be used, specifically
a) when should a bean client use the bean's getter only/when should it
use the bean's getter and/or the above API?
b) where does the default value come from? In order to distinguish
default value from in injected value (i.e. value coming from sources 1.
and 3. above) and value coming from service model it looks like every
bean should have a
T getTProperty();
and a
// no (public) setter for this one
T getDefaultTProperty(); ?
Where is the preference of injected value vs. default value vs. obtained
from service model determined? IMO it's important this happens in one
place only, and if it's in bus.getConfigurationValue(...) we need to
pass both the default and the injected value.
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.
What do you mean with searching through the Bus?
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.
One generic ConfigurationProvider can be used in most if not all cases,
and there would be no more code to that than there would be to the
implementation of the above getConfigurationValue - in fact they'd be
pretty much the same thing.
Andrea.
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
