Folks,
A quick warning on some surprising Exchange.remove() semantics. The following code doesn't work as you'd expect: exchange.put(MyClass.class, myObject); // do some stuff exchange.remove(MyClass.class); specifically the remove doesn't actually have any effect. This bit me big-time earlier today. The problem is that the org.apache.cxf.message.StringMapImpl.put(Class<T> key, T value) inherited by ExchangeImpl does a Map.put() on key.getName(), not the key itself. So in order to actually remove the entry from the Exchange map, you'd need to call exchange.remove(MyClass.class.getName()), i.e. use a different key to the one originally passed to Exchange.put(). Now I guess we could override remove(Class<T> key) on StringMapImpl also, so that exchange.remove(MyClass.class) would work as expected, but do we really need to do that for every Map method that depends on the key, e.g. containsKey(), keySet(), entrySet(), putAll() etc. But I wonder why Exchange even implements org.apache.cxf.message.StringMap, when clearly we're using it to set non-string properties, i.e. those keyed on Class. Maybe instead Exchange should revert to just implement java.util.Map directly? Or have Exchange implement a generic Map sub-interface with T get(Class<T> key) and void put(Class<T> key, T value) overrides (to avoid having to cast the exchange.get(MyClass.class) return value), but without the <String, Object> restriction? Thoughts? /Eoghan
