RFC: Netx - Use version based download protocol for JNLP files

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2009-07-13 14:47]:
> Deepak Bhole wrote:
>> * Omair Majid <omajid at redhat.com> [2009-07-10 11:51]:
>>> Hi,
>>>
>>> This patch makes Netx use the version based download protocol for 
>>> JNLP  files.
>>>
>>> Netx tries to use the version based download protocol whenever 
>>> possible  to download files. This wasn't being done for JNLP file 
>>> that were  specified as extensions by other JNLP files. This patch 
>>> fixes the issue  making JNLP applications like aerith[1] work. This 
>>> is also required to  run JavaFX applications.
>>>
>>> While adding that support, I noticed that function arguments that   
>>> involved Urls and versions were inconsistent: some used function(URL, 
>>>  Version, blah) while others used function(URL, blah, Version). I 
>>> have  tried to fix them to be function(URL, Version, blah) 
>>> consistently.
>>>
>>> ChangeLog:
>>> 2009-07-10  Omair Majid  <omajid at redhat.com>
>>>
>>>   * rt/net/sourceforge/jnlp/JNLPFile.java
>>>   (JNLPFile): Delegate to the Version-based constructor.
>>>   (JNLPFile): New constructor.
>>>   (JNLPFile): Modified to take an additional version argument used in
>>>   downloading the JNLP file.
>>>   (openURL): Take an additional version argument and use when
>>>   downloading the URL.
>>>   * rt/net/sourceforge/jnlp/Launcher.java
>>>   (toFile): Use the new JNLPFile constructor.
>>>   * rt/net/sourceforge/jnlp/cache/Resource.java
>>>   (Resource): Rearrange argument order.
>>>   (getResource): Likewise. Fix parameters to constructor.
>>>   * rt/net/sourceforge/jnlp/cache/ResourceTracker.java
>>>   (addResource): Fix arguments to Resource.getResource.
>>>   * rt/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
>>>   (getInstance): Take additional version argument and useit when
>>>   creating a JNLPFile.
>>>   (initializeExtensions): Use the extension version when requesting a
>>>   JNLPClassLoader.
>>>
>>>
>>
>> Looks good. One question though.. why are the order of arguments to
>> Resource() and getResource() being changed?
>>
>
> Obviously I didnt do a good job explaining this in the original email.  
> There are many functions in Netx that require a URL, a Version and an  
> UpdatePolicy:
>
> $ find -iname '*java' | xargs grep 'URL.*Policy'
> ./cache/ResourceTracker.java:    public void addResource(URL location,  
> Version version, UpdatePolicy updatePolicy) {
> ./cache/CacheUtil.java:    public static URL getCachedResource(URL  
> location, Version version, UpdatePolicy policy) {
> ./cache/Resource.java:    private Resource(URL location, UpdatePolicy  
> updatePolicy, Version requestVersion) {
> ./cache/Resource.java:    public static Resource getResource(URL  
> location, UpdatePolicy updatePolicy, Version requestVersion) {
> ./Launcher.java: resourceTracker.addResource(splashImageURL, 
> file.getFileVersion(), updatePolicy);
>
> These functions dont have a consistent argument order. Some take (URL,  
> Version, UpdatePolicy) while others take (URL, UpdatePolicy, Version). I  
> wanted to make the order consistent. To me, URL and Version are much  
> more strongly related than URL and UpdatePolicy, so I tried to fix  
> everything to be (URL, Version, UpdatePolicy). Is that a sensible change  
> to make?
>

Fair enough. Okay, looks good. Assuming you have tested it, go ahead and
commit.

Deepak

> Cheers,
> Omair