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.
* 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(). 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.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
