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.