On Wednesday 24 January 2007 14:23, Dan Diephouse wrote:
> 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:
Out of curiosity, could this just moved into the model directly? Basically,
add a method to AbstractPropertiesHolder like:
public <T> T traverseAndGetExtensor(T defaultValue, Class<T> type) {
T t = getExtensor
if (t == null) {
t = defaultValue;
}
return t;
}
and then override it in EndpointInfo and any of the other servicemodel
components that may need to do so.
Would that work?
Dan
>
> 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
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
