[icedtea-web] RFC: Patch to check the manifest file for main class

[Jiri Vanek]

On 02/28/2012 02:01 AM, Omair Majid wrote:
> On 02/27/2012 05:42 PM, Deepak Bhole wrote:
>> Hi,
>>
>> This commit introduced a check for main in HEAD:
>> http://icedtea.classpath.org/hg/icedtea-web/rev/bd59947fa857
>>
>> However it causes an error if the main method is listed in the manifest
>> rather than JNLP (e.g.: http://pardemo02.ilog.fr/mapviewer/mapviewer.jnlp)
>>
>
> Thanks for catching this.
>
>>
>> diff -r 4d7bddf0d4de netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Mon Feb 27 21:58:41 2012 +0100
>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Mon Feb 27 17:40:45 2012 -0500
>> @@ -593,6 +593,22 @@
>>               mainClass = ad.getMainClass();
>>           } else
>>               return;
>> +
>> +        // The main class may be specified in the manifest
>> +        if (mainClass == null) {
>> +            JARDesc mainJarDesc = file.getResources().getMainJAR();
>> +            File f = CacheUtil.getCacheFile(mainJarDesc.getLocation(), null);
>
> A couple of lines below,
>
> tracker.getCacheFile(jars.get(i).getLocation());
>
> is used instead of CacheUtil.getCacheFile. The javadoc of
> CacheUtil.getCacheFile notes that "This method returns the file location
> only and does not download the resource". Is there any reason to use
> CacheUtil over ResourceTracker?

Definitely resource tracker.
>
>> +            if( f != null) {
>> +                try {
>> +                    JarFile mainJar = new JarFile(f);
>> +                    mainClass = mainJar.getManifest().
>> +                            getMainAttributes().getValue("Main-Class");
>> +                } catch (IOException ioe) {
>> +                    return;
>> +                }
>> +            }
>> +        }
>> +
>
> Just throwing this one out there: if there is no jar marked main, should
> we try and iterate over all jars to find a jar with a Main-Class in the
> manifest file?

I thing so.  I have not seen many jnlps with main jar specified. But, in case you will iterate through all of them, you will very probably found more main classes. What then?

The specification is clear - "The main-class attribute can be omitted if the first JAR file specified in the JNLP file contains a manifest file containing the main class. "
So if there is no main, then just first shoul;d be used.
Still I think it is worthy to iterate, and if only one manifest is found then use it.

So there should be  three steps
1)main jar
2)first jar
3)iterate and if only one

But the last one is discutable

The same fix should be also aplied for to applet loading (Does not look like this patch do.....):

"applet-desc Element

"
     Java Web Start has support for launching Java applets. This support provides easy migration of existing code to Java Web Start.

     An applet is launched using the applet-desc element instead of the application-desc element. For example:

       <applet-desc
           documentBase="http://..."
           name="TimePilot"
           main-class="TimePilot.TimePilotApp"
           width="527"
           height="428">
         <param name="key1" value="value1"/>
         <param name="key2" value="value2"/>
       </applet-desc>

     The JAR files that make up the applet are described using the resources element as for applications. The documentBase must be provided explicitly since a JNLP file is not embedded in an HTML page. The rest of the attributes correspond to the respective HTML applet tag elements.

     The main-class attribute is used instead of the code attribute.  The main-class attribute is assigned the name of the Applet class (without the .class extension).  This attribute can be omitted if the Applet class can be found from the Main-Class manifest entry in the main JAR file.
"



Best regards
     J.




>
> Cheers,
> Omair