Icetea exception

[Jacob Wisor]

Hello guys!

On 06/28/2016 at 09:23 AM Jiri Vanek wrote:
> On 06/27/2016 05:49 PM, Jacob Wisor wrote:
> Hi Jacob!
>
> Where have you get this file?

Cezar sent it to me. Unfortunately, perhaps he forgot to add the mailing list 
onto the list of recipients? :-o

>> Bingo! Like I have assumed. The OBJECT element in the HTML document has been
>> authored incorrectly.
>> Look here:
>>
>>>                         <object
>>>                             classid =
>>> "clsid:CAFEEFAC-0015-0000-0012-ABCDEFFEDCBA"
>>>                             codebase =
>>> "http://java.sun.com/update/1.5.0/jinstall-1_5_0_12-windows-i586.cab#Version=5,0,120,4"
>>>
>>>                             WIDTH = "640" HEIGHT = "480" NAME = "ucx" >
>>>                             <PARAM NAME = CODE VALUE = "ultracam.class" >
>>
>> First, "class" is a reserved keyword in the Java programming language and
>> therefore must not be a
>> package name. Second, the ultracam class has not been specified with its fully
>> qualified name. The
>> VALUE attribute of the PARAM element must state the fully qualified name of
>> the applet's main class.
>
> The ultracam class may stand in default package.

Sure, however the value must not contain a package or class named "class" 
(because, as already said, it is a reserved keyword). In this example "ultracam" 
is interpreted as a valid package name, then "class" is interpreted as a class 
name, which of course is an invalid name. This is why a ClassNotFoundException 
is thrown.

>>
>>>                             <PARAM NAME = ARCHIVE VALUE = "ultracam.jar" >
>>>                             <PARAM NAME = NAME VALUE = "ucx" >
>>>                             <param name = "type" value =
>>> "application/x-java-applet;jpi-version=1.5.0_12">
>>>                             <param name = "scriptable" value = "false">
>>>                             <PARAM NAME = "accountcode"
>>> VALUE="YWRtaW46emd1cmFUTnc=" />
>>>                             <PARAM NAME = "codebase"
>>> VALUE="http://10.1.1.1:80/admin" />
>>>                             <PARAM NAME = "mode" VALUE="0" />
>>>
>>>                             <comment>
>>>                             <embed
>>>                                     type = "application/x-java-applet" \
>>>                                     CODE = "ultracam.class" \
>>
>> Essentially, the same applies here too.
>>
>>>                                     ARCHIVE = "ultracam.jar" \
>>>                                     NAME = "ucx" \
>>>                                     WIDTH = "640" \
>>>                                     HEIGHT = "480" \
>>>                                     accountcode ="YWRtaW46emd1cmFUTnc=" / \
>>>                                     codebase ="http://10.1.1.1:80/admin" / \
>>>                                     mode ="0" / \
>>>                                 scriptable = false
>>>                                 pluginspage =
>>> "http://java.sun.com/products/plugin/index.html#download">
>>>                                 <noembed>
>>>
>>>                                     </noembed>
>>>                             </embed>
>>>                             </comment>
>>>                         </object>
>>
>> So, what can you do now? a) You should report this bug do the camera vendor
>> and wait for a firmware
>
> Its hardly to happen:(
>> update. b) In the meantime, you can download the ultracam.jar JAR file, find
>> the fully qualified
>> name of the ultracam class, put it into the HTML document and launch it from
>> your local computer.
>
> I doubt it will work like this. The jar should run on device where it is doing
> the job for the ITW user.

Err..., I do not think so. Applets are, by design a piece of software that is 
meant to be downloaded "automagically" and run on the user's *local* machine. 
This is the core purpose of the Applet concept. Applets are not an extension to 
the terminal concept (with remote execution) but a concept for a distributed 
(fat) client application. Hence, you may also call it "dynamic web content", if 
you want. So, applets *always* run locally.

> But to follow this advice - you can check the communication between the cam and
> browser/javaws --html  and remove .class on the fly
>
>> There is nothing IcedTea-Web developers can do here.
>>
>
> Actually - this is reported as regression. I guess 1.5 was previous ITW on his
> box. Why it was working?
> So maybe add stripping of .class is the bugfx to go?

AFAIR, you have committed a fix to relax main class name parsing for applets 
embedded on web pages. We have discussed this at lengths on the mailing list. 
The fix should have dealt with trimming and ignoring white spaces outside of 
compound literal characters only. So, maybe this fix introduced other new but 
also equally valid parsing restrictions? Both of which is good. This example 
could be given more investigation but the current code - obviously - does reject 
the given example correctly, hence no real need for a deeper investigation in my 
view.

> Jacob - thank you very much for investigations. *really* thanx!

No problem. ;-) I appreciate I could help.

Regards

Jacob