Hi Dale, Dale Ellis wrote:
> I was having a look in the JConsole at the stack of the hanging thread, I > think the issue is to do with my abstractEntity class (which all the JPA > entity objects extend) overrides the hascode with this... > > public int hashCode() { > if(getId() != null) > { > return new HashCodeBuilder().append(getId()).toHashCode(); > } > else > { > return HashCodeBuilder.reflectionHashCode(this); > } > > When I remove this, the fromXML() works The reflectionHashCode is a *very* dangerous tool (I don't give a bad mouth here, I am committer to Apache Commons Lang myself). In your case you might even break the hashCode contract. The hashCode is meant to be a *constant* unique identifier, i.e. if you use your object as key in a HashMap, the hash value should never change afterwards. Is getId() a pure getter or will it also access other complex objects in the graph to get one? >From the XML structure I can see that some of your objects deep down in the object graph contain back references to parents or siblings. A reflection- based hash code builder will normally silently introduce an endless recursion here - it just works, because the Apache implementation keeps track of the accesses objects. However, this calculation is in any case expensive. BTW: Are you also sure you fullfill another hash code contract, i.e. equal equal objects (calling equals()) means also equal hash codes (the reverse is not guaranteed though)? Apart from this, I still wonder, why TreeMap.putAll adds all elements individually instead of using the optimized method that does not sort the elements again and therefore omit all calls to compareTo ... :-/ Cheers, Jörg --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email