Icetea exception

[Jiri Vanek]

On 07/01/2016 12:10 AM, Jacob Wisor wrote:
> 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



oook.
>
>>> 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.

I agree on this.
>
>>>
>>>>                             <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.


With exception of host.
First may be that unisgned appelts may access only to the host.
Second is that they have information about the host. If you launch it locally, host will be your 
machine instead of server, so any host operations will fail. In this case the hsot is camera, so I 
guess it is via some api reading from it, and sending to...client. If you launch it from local, it 
will not have an info where to read the picture.
>
>> 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.

Yes I recall that. It is just sad that more correct behavior caused regression.


J.