I wish people would read the javadoc for URLDecoder before using it for this.
It clearly states that it's not for decoding url paths, its for decoding form
content in a url query string.
The only reliable ways I know of to encode/decode url paths involve URI. If
you're careful you can use the appropriate URI constructor that does the path
encoding and decode using one of the accessor methods. If you don't want to
figure out which constructors/method are correct you can crib the code from
Harmony.
unfortunately I don't remember what the correct methods are....
thanks
david jencks
On May 21, 2011, at 3:17 PM, Alasdair Nottingham wrote:
> Hi,
>
> None of the application itests run on the mac anymore. This seems to
> be as a result of the following code added to the
> ModelledResourceManagerImpl:
>
> try {
> bundleFile = URLDecoder.decode(bundle.toString(), "UTF-8");
> } catch (UnsupportedEncodingException uee) {
> ModellerException me = new
> ModellerException(MessageUtil.getMessage("INVALID_BUNDLE_LOCATION",
> bundle));
> _logger.debug(LOG_EXIT, "getModelledResource", me);
> throw me;
> }
>
> the problem is that bundle.toString returns a file url for the
> following directory:
>
> /var/folders/LV/LVuEEG-GGE8d9XrtRZh-hU+++TQ/-Tmp-
>
> when the url is decoded the + char is converted to a single space. So
> it becomes:
>
> /var/folders/LV/LVuEEG-GGE8d9XrtRZh-hU TQ/-Tmp-
>
> which doesn't exist.
>
> I'm not sure what the right fix is, but I suspect it would be better
> to call toURL().toExternalForm() on the IDirectory rather than relying
> on toString returning a URL which isn't defined in the javadoc.
>
> Thoughts?
> Alasdair
>
> --
> Alasdair Nottingham
> [email protected]
