Great, all passing now, thanks. On 22 May 2011 08:18, Valentin Mahrwald <[email protected]> wrote: > I hit that as well and checked a partial fix in under ARIES-562, which does > not change the IDirectory.toString but the code that does the decoding. The > thing is that code does not even need a File object or a path on disk. All it > cares for is opening the IFile ... for which there is a different method. > > Regards, > > Valentin > > On 21 May 2011, at 23:17, 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] > >
-- Alasdair Nottingham [email protected]
