Stephen,
When you implement a custom hashCode, you must make sure that it always
returns the same value any time the method is called during an single
instance of an application. The value can change each time the
application is executed, but during a particular instance, the value
returned needs to be the same.
If the ipAddress or hostName changes at all, then your hashCode method
will end up returning a different value and therefore cause hashtable to
be looking in the "wrong" bucket for the object.
Try changing your code as such:
private int _hashCode = 0;
public int hashCode() {
if (_hashCode == 0) {
//-- use tmp variable during calculation
//-- so that we can assign _hashCode in one statement
int tmpHash = /* hashcode algorithm */
_hashCode = tmpHash;
}
return _hashCode;
}
This will always return the same hashCode once computed and now the
Hashtable will be able to search the correct bucket each time.
--Keith
Stephen Ince wrote:
>
> I have found an issue with implementing the _object member as a
> SequenceHashtable. In one of my objects I override the hashCode method. For
> some reason that was wrecking havac with the object lookup. Castor kept
> throwing the following exception, IllegalArgumentException("ObjectEntry to
> be rehash is not found!") in org.exolab.castor.persist.TransactionContext.
> Does anyone have any ideas why? I guess my hashcode is not valid. Should I
> also override the equals method.
>
> public int hashCode() {
> return ( ((this.ipAddress == null)? "" : this.ipAddress )
> +((this.hostName == null)? "" : this.hostName )).hashCode();
> }
>
> >
> >
> > Bruce Snyder wrote:
> > >
> > > This one time, at band camp, Stephen Ince said:
> > >
> > > SI> I just included one file
> org.apache.turbine.util.SequencedHashtable. It
> > > SI>didn't have any dependencies. I didn't use a SequencedHashMap because
> it
> > > SI>uses Iterator and not an Enumeration. I wanted to minimize the code
> impact.
> > > SI>I also didn't know if it had to be thread safe or not.
> > > SI>
> > > SI> For complex dependencies I will normally use genjar to figure that
> out.
> > >
> > > I'm actually leaning toward bringing the SequencedHashtable directly
> > > into The Castor Project under org.exolab.castor.util. The ASL actually
> > > allows for this type of behavior. Of course, full credit for the class
> > > would be given to the ASF.
> >
> > Just make sure you leave the original header in the source class.
> >
> > Also it might be good to do the following:
> >
> > 1. Add it to the CVS under it's original package name.
> >
> > 2. Create an org.exolab.castor.util.SequenceHashtable that simply
> > extends the Turbine one. This would allow us to change the underlyling
> > implementation if we ever desired to do so without having to change code
> > in the future.
> >
> >
> > --Keith
> >
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
> >
> >
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
