Dan Diephouse wrote:
Hi Andrea,
On 1/24/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
To sum up, my main concerns are:
* Use of static APIs (I don't see how this can get around keeping
references to the bus all over the place as the bus itself is not
static).
I meant something like this:
public static <T> T getConfiguration(AbstractPropertiesHolder props, T
defaultValue, Class<T> type);
The point of the getConfiguration method isn't to introduce a
Configuration
type interface, its merely to encapsulate the logic which traverses the
service model. For example:
public <T> T getConfiguration(AbstractPropertiesHolder props, T
defaultValue, Class<T> type) {
T value = props.getExtensor(type);
if (value == null) {
if (props instanceof EndpointInfo) {
value = getServiceModelValue((EndpointInfo) props, type);
}
if (value == null) {
value = defaultValue;
}
}
return value;
}
private <T> T getServiceModelValue(EndpointInfo info, Class<T> type) {
T value = null;
BindingInfo b = info.getBinding();
if (value == null && b != null) {
value = b.getExtensor(type);
}
ServiceInfo s = info.getService();
if (s != null && value == null) {
value = s.getExtensor(type);
}
return value;
}
Ideally there would be support for getting properties from Messages and
Operations as well though.
My impression was that bus.getConfiguration(...), or something else,
was supposed to do all of what you listed earlier:
>The resolution order would be like this:
>1. The default value - i.e. new HTTPServerPolicy();
>2. The value found on the service model - this would potentially be
from the WSDL.
>3. The value set on the bean in the config file
>4. The value set on the bean via "other stuff" aka
BeanFactoryPostProcessors/BeanPostProcessors
But I realise it's really only seaching the service model (and as such
there is no need for it to be static), and that there will be no
mechanism in place to ensure that steps 1. to 3. are done consistently
every time a property is needed (4. is not an issue as it happens in the
background).
* Reintroduction of configuration APIs - although IMO this would not be
so bad, Celtix has lived with cfg APIs long enough. I just find the
idea surprising after the discussions that took place on this mailing
list half a year earlier.
I view this as quite different from the Configuration APIs. The
Configuration APIs were basically a hierarchical tree of values.
getConfiguration().getChild(...).getValue().
No - the hierarchy was gone by the time code was dropped into the apache
repository. It was instead like:
getConfiguration().getValue(...)
The proposed solution is just a
convenience method for finding values in the service model. This
allows the
containers to do their thing (xml/db/properties config, wiring) and still
allows us to get values from the service model.
The method really might be better named "getServiceModelExtensor"
instead of
getConfigurationValue...
* If configuration APIs are reintroduced I would like to see them used
consistently. If bean clients end up doing this:
T t = bean.getTValue();
in some places and:
T t = bus.getConfiguration(endpointInfo, defaultT, T.class);
or:
T t = bus.getConfiguration(endpointInfo, bean.getTValue(), T.class);
in others places I'd consider that a source of
problems/inconsistencies. But maybe others don't think it's as big
problem as I think it is?
I think the same consistencies arise with the current approach. I can
easily forget or not realize that I have to have a ConfigurationProvider
check for a value in the service model. Both approaches require some
manual
wiring.
No - this is one of the main advantages of the current/previous
approaches: clients only ever make *one call* to the bean's getter/to
the component'ss configuration object. The traversal of the service
model, and the precedence between default, injected and service model
value need were never of concern to the client.
Do you not think that instead of repeat coding steps 1. to 3. above,
people end up writing wrappers that do just that (effectively making up
for what was previously hidden in the the 'extended getters'/the
configuration API)? I would.
Andrea.
- Dan
