[Geotools-devel] Answered: CoordinateReferenceSystem serialization combined with a bad identity check

[Jody G. <jga...@re...>]

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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>