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

Tuesday, 23 September 2014

    [
https://issues.jboss.org/browse/JBIDE-18411?page=com.atlassian.jira.plugi...
] 

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)

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006