Looks like the problem was in the AggregateFactoryImpl - it was trying to test on CoordinateReferenceSystem identity (ie == operator) rather than CRS.equalsIgnoreMetadata.
Thanks Jesse for finding this one. How were we getting two equals but not identical CoordinateReferenceSystem objects in our JVM (especially after Martin goes to so much trouble to "intern" them in a WeakHashMap?) Serialization between client and server. Option: - store the identifier, mark the crs field as transient and look it up as needed? Only works if the client has access to the same authorities - store WKT? We just proved that that is lossy Probably another argument for Martins idea of using XML. For now we will just gobble up memory. Cheers, Jody > The relationship between CRS.equals and FactoryRegistry may be a bit odd > (we understand the WKT example in the test cases is not the best as it > snips out some of the metadata). The real problem is a race condition > we are seeing between some code using GeometryFactoryFinder and some > code using GeometryBuilder (that uses GeometryFactoryFinder). This is > the kind of race condition that only maven multi threaded test cases can > show; leaving us a bit stuck on the debugging side of things. > > We would like to trust GeometryFactoryFinder to handle things correctly; > it is using FactoryRegistry to handle synchronization; I checked that > the code is done in the same way as ReferencingFactoryFinder. > > Jesse will be looking into this for a bit; I am changing GeometryBuilder > to be a bit more greedy (looking up factories during construction rather > than lazy, and having it manually check the hints for provided instances > - so it can avoid FactoryRegistry use at all) - so strictly a hack. > > Jody > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
