Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: UDIG 1.3.1
-
Fix Version/s: UDIG 1.3.2
-
Component/s: catalog, metadata and search
-
Labels:None
Description
Matt Willis on udig-devel has turned up a corner case for the ID + Canonical File resolving code added at the start of uDig 1.3.0.
I have attached Matthew's files to aid in testing:
Example: "Hasson BW and CM Hasson Wheat 2012.shp"
Initial investigation shows:
1) ShpServiceExtension URL cleaning code was unable to produce a valid File reference from this URL.
The provided patch makes use of URLUtils; and includes a check to ensure the File exists
2) CatalogImpl.find( ID id, IProgressMonitor monitor ) was unable to correctly match the child GeoResource with the Parent; and thus failed to find the resource when adding the layer to the map.
This method responsible was URLUTils.urlEquals( URL, URL, boolean ) where the flag is used to perform a relaxed match (allowing us to identify the service matching the child GeoResource).
The provided patch adds ID.equals( ID, boolean ) as an alternative; it performs both checks and will proceed if either returns true.
3) Finally this method trips up the canocalization attempt in ID; triggering some system outs that look alarming.
Summary: It is my intension to retire the use of URL checking and matching in the catalog code as it is driving me crazy.
