[jbosstools-issues] [JBoss JIRA] (JBIDE-17148) Improvements needed (regarding caching) in the URLTransport* API

[Rob Stryker (JIRA)]

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

Rob Stryker commented on JBIDE-17148:
-------------------------------------

Unfortunately the way to test this now depends on who is calling it. We know that both central and stacks use this api, and also download runtimes (when downloading a jboss server). 

Essentially, each caller can pass in a custom folder to store and cache the downloaded file. Each folder is given an index file, as well, to keep track of which files in the folder are actually in the cache vs which ones are not.  And the names given to the downloaded files are now more representative of their urls, so instead of a random tmp8235478345734.tmp file, the downloaded file's name is now more similar to a url (such has http___www.x.com_someFolder_file.jar.tmp.  

Much of this is internal implementation details, though you can still search at least for URLTransportCache.cacheIndex.properties somewhere in your metadata folder after  stacks, runtimes, or central download any remote web file for use.  

I'm not re-opening the issue, because there's no clear steps to check, but, if you wanted to look into it, I'd suggest finding folders that have URLTransportCache.cacheIndex.properties as a file, looking at the contents of the folder and the contents of the file, and verifying that 1) The file names are easily readable, and 2) the index file contains whatever is in the folder.   I would also try canceling a download and verifying that the index file does not contain that file (that the object is only added to the cache index AFTER the download completes). 

I will not re-open this issue, though you can if you intend to verify. 

> Improvements needed (regarding caching) in the URLTransport* API
> ----------------------------------------------------------------
>
>                 Key: JBIDE-17148
>                 URL: https://issues.jboss.org/browse/JBIDE-17148
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: common/jst/core
>    Affects Versions: 4.2.0.Beta1
>            Reporter: Fred Bricon
>            Assignee: Rob Stryker
>             Fix For: 4.2.0.Beta2
>
>
> There are a few things I'd like to see improved in the URL Transport API, wrt caching.
> Currently :
> * all files are downloaded and cached under <workspace>/.metadata/.plugins/org.jboss.tools.foundation.core/ECF_REMOTE_CACHE, using a cryptic name
> * Cache doesn't survive JVM restart
> What I need/expect :
> * ability to set custom cache folder 
> * store files under <cache.folder>/requested.url. eg. : if I request https://foo.bar.org:8080/some/location/file.txt, it'll be stored under  <workspace>/.metadata/.plugins/my.plugin/cache/http_foo.bar.org_8080/some/location/file.txt
> * restarting the IDE will be able to read the cached file
> Currently URLTransportCache is a singleton. We could change that and add the cache location as a constructor argument, have a URLTransportCache.DEFAULT instance, used by URLTransportUtility and probably override 
> {quote}
> public File getCachedFileForURL(String url, String displayName, int lifespan, IProgressMonitor monitor) 
> {quote}
> with 
> {quote}
> public File getCachedFileForURL(String url, String displayName, URLTransportCache transportCache, IProgressMonitor monitor) 
> {quote}
> Or if you have any better idea, be my guest :-)



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)