> -----Original Message----- > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > Sent: 11 April 2007 18:00 > To: [email protected] > Subject: Re: Bitten by StringMapImpl - odd semantics for > Exchange.remove() > > Glynn, Eoghan wrote: > > >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. > > > > > Nothing that we can or need to do for keySet(), entrySet(), > putAll() - just the convenience overrides for remove and containsKey.
I was thinking in say the case of keySet() we should like translate back (via Class.forName() I guess) from stringified-class keys back to the original Class type passed into Exchange.put() . But yeah, I see the prob where the original key type was actually String, but it looks and smells like a class name (e.g. "org.apache.cxf.message.inbound") > >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? > > > > > Personally, I prefer not being ultra flexible here. And > Message also extends StringMap, adding the get/setContent() methods. > But that's just my opinion. Grandeo, I'll leave well enough alone. Cheers, Eoghan
