[jbosstools-issues] [JBoss JIRA] (JBIDE-18411) DownloadRuntimesWizard shouldn't need to parse the d/l url to infer the file name

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-18411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005020#comment-13005020 ] 

Rob Stryker commented on JBIDE-18411:
-------------------------------------

The API we've designed takes only an outputstream, and would require a complete rewrite of the public API, or at the very least, lots of new additional API while leaving the old API unused / dead code for backwards compatibility purposes. 

Ignoring that, though, As far as I can tell, the ECF code we use does not have access to the response headers in any fashion at all. So on a technical level, I'm not even sure it's possible. I can continue to dig, but my gut tells me this is a dead end without some strange code.   Even if I did get proper response headers somehow, we'd only be able to do that AFTER initiating the ECF request and passing in an already-created output stream...  we'd basically need to initiate the ECF request with a bytearrayoutputstream, and then later, copy it to a file of  name provided in the response headers.  This seems like a very strange circular workflow to me, transfering the data first to a temporary output stream, and then copying it into a file.  We'd also need to rewrite all callers (stacks, central, others) to use the new API which doesn't take an output stream. 

Or, on the other hand, I can just fix the incorrect string parsing ;) 



> DownloadRuntimesWizard shouldn't need to parse the d/l url to infer the file name
> ---------------------------------------------------------------------------------
>
>                 Key: JBIDE-18411
>                 URL: https://issues.jboss.org/browse/JBIDE-18411
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: runtime-detection
>    Affects Versions: 4.2.0.CR1
>         Environment: JBT 4.2.0.CR1, JBDS 8.0.0.CR1
>            Reporter: Radim Hopp
>            Assignee: Rob Stryker
>             Fix For: 4.3.0.Alpha1
>
>
> JBIDE-18393 showed that parsing d/l urls was fragile :
> {noformat:title=An internal error occurred during: "Download 'JBoss 6.0.0".}java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> 	at java.lang.String.substring(String.java:1954)
> 	at org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeOperationUtility.getNextUnusedFilename(DownloadRuntimeOperationUtility.java:56)
> 	at org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeOperationUtility.getDestinationFile(DownloadRuntimeOperationUtility.java:89)
> 	at org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeOperationUtility.downloadRemoteRuntime(DownloadRuntimeOperationUtility.java:194)
> 	at org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeOperationUtility.downloadAndInstall(DownloadRuntimeOperationUtility.java:155)
> 	at org.jboss.tools.runtime.ui.internal.wizard.FinalizeRuntimeDownloadFragment$9.run(FinalizeRuntimeDownloadFragment.java:588)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54){noformat}
> [~maxandersen] suggested to get the filename from the d/l response header instead



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)