On Mon, 2003-02-17 at 04:31, Leo Sutic wrote: > Berin, > > this sounds like an issue with proxies. The StaticBucketMap should > be able to handle proxies, as long as the key being put == the > key being get. > > I'm not that keen on the solution applied - it assumes that a > component's > toString() method returns the same value all the time. This may be true > for > any sensible component implementation, but: > > 1. It is a hack. toString () returns <className>@<hashCode>, > which isn't guaranteed not to lead to collisions. > > 2. The requirement on toString() isn't specified anywhere. > > I'd say we should go fix the "root bug" here. I'm grabbing the > current Fortress CVS, it shouldn't be too hard to duplicate the > bug... > > /LS
If toString() will cause collisions then this won't work correctly. The other day I was just looking for anything that would at least temporarily fix the problem. One thing you might want to know is that I did try changing it from a StaticBucketMap to a normal Hashtable and still had the same issue. So apparently, the key that's being put is NOT the key that is being "get" even though the toString() returns the same value. This is rather troubling since in this bit of code, all I do is get the component from the service manager, call some methods and store it in a Hashtable. Then later I retrieve it and release it. Why would it be different? If it's not equal, then how else can can I release this component? I agree that the "root bug" needs fixed, but I'm not certain that storing the component itself is the solution. Perhaps there is some other way to create a unique identifier? -- jaaron <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
