cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Bitten by StringMapImpl - odd semantics for Exchange.remove()
Date Wed, 11 Apr 2007 18:46:47 GMT


Hmmm, the different classloaders => non-singleton class instance case
hadn't occurred to me. 

In any case, I've a simple work-around for the basic issue.

As the general feeling seems to be to maintain the StringMapImpl
extension in ExchangeImpl, my work-around will do the job for now.

Cheers,
Eoghan

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 11 April 2007 18:21
> To: cxf-dev@incubator.apache.org
> Subject: Re: Bitten by StringMapImpl - odd semantics for 
> Exchange.remove()
> 
> 
> If I recall correctly (I believe I may be partially 
> responsible), the StringMap type was introduced as a factor 
> of common functionality in the Exchange and Message types; 
> these types (and their associated
> impls) had identical get(Class<T>) and put(Class<T>, T) 
> operations, and it just made sense to pull these out into a 
> common base type.  So not to sound too defensive, but this 
> behavior has probably been in the Exchange and Message all along.
> 
> \end{disclaimer}
> 
> But to get to your real question, which I take to be, "Should 
> we remove the String -> Object restriction on the map type?", 
> my only question is, are there any cases in which there could 
> be two Class instances that represent the same type?  I.e., 
> given the fact that you can have multiple class loaders, 
> Foo.class is not necessarily a singleton, right?  If so, then 
> exchange.remove(Foo.class) may be idempotent on exchange.[1]  
> I'm guessing here, and I guess I was assuming all along that 
> that was the real reason that types were being keyed off 
> their names, as opposed to themselves, directly.  But I was 
> not involved in the start of the Message and Exchange types, 
> so I don't know if this was a use-case envisioned in the 
> initial design.  (If not, I don't see any reason not to 
> remove the restriction, as you propose)
> 
> -Fred
> 
> [1] Class inherits equals and hashCode from Object.
> 
> On Apr 11, 2007, at 11:52 AM, Glynn, Eoghan wrote:
> 
> > 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?
> 
> 

Mime
View raw message