Safely convert URI to File #19
Conversation
ghost
assigned 
|
plugins » tfs-plugin #24 SUCCESS |
| @@ -76,8 +76,7 @@ static synchronized void ensureNativeLibrariesConfigured() { | |||
| // TODO: consider logging this situation if it ever happens | |||
| return; | |||
| } | |||
| final String stringPathToJar = locationUri.getPath(); | |||
| final File pathToJar = new File(stringPathToJar); | |||
| final File pathToJar = new File(locationUri); | |||
There was a problem hiding this comment.
Just beware that there is no documented standard format for CodeSource.location. URLClassLoader actually accepts two formats: file:…/code.jar and jar:file:…/code.jar!/. The second one is more logical—code sources ought to be directory URLs to which you can append resource URIs, creating a URL such as jar:file:…/code.jar!/pkg/Some.class. But both forms are found “in the field”, so you should explicitly check for the one using the jar URL protocol and strip off the jar: prefix and !/ suffix before trying to call File.<init>(URI) (which will throw an IllegalArgumentException if given the jar-protocol form), though currently Jenkins uses AntClassLoader whose defineClassFromData uses the file-protocol form, or PluginFirstClassLoader whose addPathFiles does the same. See this code for example.
|
plugins » tfs-plugin #25 SUCCESS |
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
@jglick, unless you have any more comments/objections, I will merge this in the afternoon (eastern time) today. |
|
Looks good to me. |
Safely convert URI to File
Addressing @jglick's comment on f4e33a2 regarding the unsafe conversion of
URItoFile.