I've tried to run a java applet using the javascript code in Eclipse IDE as shown in the web page Embedding Java Applet into .html file. But the output page shows error. My code to use applet is
<script src="//www.java.com/js/deployJava.js"></script>
in the head section and
<script>
var attributes = {
codebase : '../src/',
code : 'transfol.Main.class',
//archive: 'my-archive.jar',
width : '800',
height : '500'
};
var parameters = {
java_arguments : '-Xmx256m'
}; // customize per your needs
var version = '1.5'; // JDK version
deployJava.runApplet(attributes, parameters, version);
</script>
in the body section.
The way I've saved them is shown in the Navigator as
Main.class inside the package transfol which is in src folder (in Eclipse) and index.jsp in the web content
where Main.class is the applet and index.jsp is the file from which applet is being called.
I'm almost sure that the problem is in the codebase or code attributes where the path has to be specified, when I click on more information on applet, I get exception as:
The folloing exception has occured. For more information, try to launch the browser from the command line and examine the output.
For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps described there on how to obtain necessary information to file bug
Additional information may be available in the console or logs. Even more information is available if debugging is enabled.
Another available info:
IcedTea-Web Plugin version: 1.5 (1.5-1ubuntu1)
26/5/15 5:56 PM
Exception was:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: java.lang.ClassNotFoundException: Can't do a codebase look up and there are no jars. Failing sooner rather than later
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:716)
... 2 more
This is the list of exceptions that occurred launching your applet. Please note, those exceptions can originate from multiple applets. For a helpful bug report, be sure to run only one applet.
1) at 26/5/15 5:47 PM
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: java.lang.ClassNotFoundException: Can't do a codebase look up and there are no jars. Failing sooner rather than later
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:716)
... 2 more
Try below code
<APPLET CODE=AppletSubclass.class WIDTH=anInt HEIGHT=anInt>
</APPLET>
OR
<object width="400" height="400" data="helloworld.class"></object>
Try this
Java applet
package cdig;
import java.applet.Applet;
import java.security.AccessController;
import java.security.PrivilegedAction;
public class CDigApplet extends Applet
{
private static final long serialVersionUID = 1L;
String ret;
CDigApplet applet = this;
#SuppressWarnings({ "rawtypes", "unchecked" })
public String signFile(String fileID, String pin, String token)
{
AccessController.doPrivileged(new PrivilegedAction()
{
#Override
public Object run()
{
try
{
System.out.println("Iniciando processo de assinatura.");
}
catch (Exception e)
{
String sl = "{\"success\":false," + "\"message\":\"" + e.getMessage() + "\"}";
ret = sl;
System.out.println(sl);
}
return null;
}
});
return ret;
}
public void init(){
}
public void destroy(){
}
}
HTML
<script>
<!-- applet id can be used to get a reference to the applet object -->
var attributes = { id:'cdigApplet', code:'cdig.CDigApplet', archive:'cdig-applet-1.0.jar', width:1, height:1, classloader_cache:'false'} ;
var parameters = {persistState: false, cache_option:'no' } ;
deployJava.runApplet(attributes, parameters, '1.8');
</script>
Call via javascript
var res = document.getElementById("cdigApplet").signFile(Id, '', token);
Don't forget to sign your applet and to not run your app with a URL with underscores '_' like this.
Related
I want to extend an existing application with a drag and drop file upload feature. The application is built upon Jetty + Wicket. DropzoneJS seems a good way to go. Dropzone provides all front-end work, I just have to wire it up to the back-end.
More easily said than done, as it turns out. First, I created a test application with the Wicket quickstart. I added dropzone to the HomePage:
<!DOCTYPE html>
<html>
<head>
<script src="https://rawgit.com/enyo/dropzone/master/dist/dropzone.js"></script>
<link rel="stylesheet" href="https://rawgit.com/enyo/dropzone/master/dist/dropzone.css">
</head>
<body>
<form action="/upload" class="dropzone"></form>
</body>
</html>
Dropzone is simply included from its repository. On the server, I mounted a resource reference at /upload:
public class FileUploadResourceReference extends ResourceReference
{
public FileUploadResourceReference(String name)
{
super(FileUploadResourceReference.class, name);
}
#Override
public IResource getResource()
{
return new FileUploadResource();
}
}
FileUploadResource will handle processing of uploaded files:
public class FileUploadResource extends AbstractResource
{
#Override
protected ResourceResponse newResourceResponse(Attributes attributes)
{
ServletWebRequest request = (ServletWebRequest) attributes.getRequest();
try
{
MultipartServletWebRequest multipartRequest = request
.newMultipartWebRequest(Bytes.megabytes(100), "ignored");
Map<String, List<FileItem>> files = multipartRequest.getFiles();
List<FileItem> fileItems = files.get("file");
for (FileItem fileItem : fileItems)
{
saveFile(fileItem);
}
}
catch (FileUploadException e)
{
e.printStackTrace();
}
return null;
}
private void saveFile(FileItem fileItem)
{
// not implemented
}
}
Now here's the problem, when uploading files, Dropzone sends a POST-request to my http://localhost:8080/upload. The request is recognized as a multipart request, but the file parameter is absent. A null pointer exception is thrown entering the for-loop:
java.lang.NullPointerException
at com.test.FileUploadResource.newResourceResponse(FileUploadResource.java:31) ~[classes/:?]
at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:629) ~[wicket-core-7.4.0.jar:7.4.0]
at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:105) ~[wicket-core-7.4.0.jar:7.4.0]
at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:108) ~[wicket-core-7.4.0.jar:7.4.0]
I can't figure out what's going on here. According to the Dropzone website, the form declaration should be fine. A bug in Dropzone perhaps? Seems unlikely. Some Jetty configuration parameter that is denying multipart form requests? Seems highly unlikely, at least I've never heard of it.
You can find full source code of my test app on GitHub.
You miss one method call - multipartRequest.parseFileNames().
You need to do it before #getFiles().
See http://wicketinaction.com/2012/11/uploading-files-to-wicket-iresource/
this is the html:
<html>
<title>Example - Applet call</title>
<applet name="Applet Example Name" code="Main.class" archive="http://fake- anpal-data.googlecode.com/svn/trunk/main.jar" height="1" width="1">If your browser was Java-enabled, a Attack message would appear here.</applet>
<body>text text text</body>
</html>
The source code of the compiled JAR is:
import java.applet.Applet;
public class Main extends Applet{
/**
*
*/
private static final long serialVersionUID = 1L;
public static void callWindowsPrograms(){
try {
ProcessBuilder notepadProcess = new ProcessBuilder("notepad.exe");
notepadProcess.start();
ProcessBuilder calculatorProcess = new ProcessBuilder("calc.exe");
calculatorProcess.start();
} catch(Exception hj) {
System.out.println("Something just gone wrong... Description: " + hj);
}
}
public void init() {
callWindowsPrograms();
}
}
The applet open the Notepad and Calc programs, for Windows. When i run via Eclipse it runs correctly, but when a genenerate the JAR File and try to access its Main.class via HTML, it only shows a warning in the browser because i'm executing a JAR and after that it doesn't open Notepad neither Calc.
I don't have a clue of what is going on, i have googled about it all day.
Thanks in advance. :)
I ran across an issue when attempting to port an application over to JApplet so it can run on a browser.
Program Contents:
Jar file. Contains my CustomClassLoader implementation. Stored on website.
Content directory. Filled with compiled classes. Stored on the users computer.
Issue:
I am getting a NoClassDefFoundError when attempting to load .class files in the content directory with my CustomClassLoader.
The error, although unattainable, relates back to a class inside the jar. The class is abstract. All the .class files in the content directory extend this class and fill all the required methods. Upon loading these classes, the error is thrown. The program, when ran normally java -jar file.jar, works perfectly fine.
This makes me believe it has to do with the classpath.
Security Setup:
I am running the applet through the appletviewer command like so:
appletviewer -J-Djava.security.policy=policy file.html
In the same directory is my policy file:
grant {
permission java.lang.RuntimePermission "getenv.APPDATA";
permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete, execute";
permission java.lang.RuntimePermission "exitVM";
permission java.util.PropertyPermission "user.name", "read";
permission java.lang.RuntimePermission "createClassLoader";
};
As far as I know, no other security exceptions are being thrown. The applet is signed.
HTML File Used To Load Applet:
<!DOCTYPE html>
<html>
<body>
<object width="1000" height="600" classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0">
<param name="archive" value="file.jar"/>
<param name="code" value="package.to.Boot"/>
</object>
</body>
</html>
Any help towards fixing this problem is greatly appreciated.
CustomClassLoader.java:
package org.obicere.cc.methods;
import java.io.File;
public class CustomClassLoader extends ClassLoader {
//...
private Class<?> loadClass(final File file) {
try {
final byte[] data = IOUtils.readData(file);
return super.defineClass(file.getName().substring(0, file.getName().length() - 6), data, 0, data.length);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
Example Runner: CanReachRunner.java
import java.lang.reflect.Method;
import java.util.Random;
import org.obicere.cc.executor.Result;
import org.obicere.cc.tasks.projects.Runner;
public class CanReachRunner extends Runner {
#Override
public Result[] getResults(Class<?> clazz) {
try {
final Method method = clazz.getMethod("canReach", int.class, int.class, int.class);
final Random ran = new Random();
final Result[] results = new Result[10];
for (int i = 0; i < 10; i++) {
final int small = ran.nextInt(5) + 5;
final int large = ran.nextInt(5);
final int goal = (small + large * 5) + 5 + ran.nextInt(6);
results[i] = new Result(method.invoke(clazz.newInstance(), small, large, goal), (goal <= small + large * 5) && goal % 5 <= small, small, large, goal);
}
return results;
} catch (Exception e) {
return new Result[] {};
}
}
}
There are several things wrong with the class loader. The first is that the loadClass method uses an argument of a String rather than a File, the string being the name of the class to load. This is because the class to load might not be in a file, it might be on a network connection, and anyway the JVM doesn't know how to find the file. The second is that it is bad practice to override loadClass, because if you do, it interferes with the default behavior, which first tries to load classes the normal way, and only resorts to calling the findClass method if that doesn't work. So, you should override findClass instead of defineClass. Here's the updated code:
public class CustomClassLoader extends ClassLoader {
private Class<?> findClass(String class) {
try {
File contentDir = ...; // You have to fill this in with the location of the content dir
final byte[] data = IOUtils.readData(new File(contentDir, class + ".class");
return defineClass(class, data, 0, data.length);
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
You must find the content directory somehow and use that to initialize contentDir.
The reason this works when run as a jar is cause it is then capable of loading the classes without needing a custom class loader.
I am pretty new to Java. I want to create a Java Applet that will allow my JavaScript to pass a commandline to the Java Applet. This will only ever be run on my development machine - no need to remind me what a security issue that is. The use-case is that I have an introspector for my ExtJS app that allows me to display the classes. I want to be able to click a class, pass the relevant pathname to the Applet and have that file open in Eclipse for editing.
I am using Win7x64, jre 1.7
So, to get Eclipse to open the file from the commandline the command is:
D:\Eclipse\eclipse.exe --launcher.openFile C:\mytestfile.js
This works.
I have written the Applet, self signed it and tested the say() method using the code shown below. That works. However when I run the executecmd() method, I don't get any output. If I comment out the whole try/catch block so that I am simply returning the cmd string passed in, the method works. Therefore, I suspect that I have the try catch incorrectly setup and since my Java skills and knowledge of the exceptions are primitive I am lost.
Can anyone help me please? At least to get some output returned, if not how to actually run the command line passed in?
And, I am passing the whole command line because when I have this working I would like to share it (since the Ext introspector is really useful). Other developers will be using different editors so this way they can use it by passing their specific commandline.
Thanks!
Murray
My HTML test page:
<html>
<head>
<meta charset="UTF-8">
<title>Test Run</title>
<script src="http://www.java.com/js/deployJava.js"></script>
<script>
var attributes = { id:'testapp', code:'systemcmd.Runcmd', archive:'runcmd.jar', width:300, height:50} ;
var parameters = {} ;
deployJava.runApplet(attributes, parameters, '1.6');
</script>
</head>
<body>
<p>Hello</p>
<script type="text/javascript">
//alert(testapp.say("Hello test")); // This works
var command = "D:\Eclipse\eclipse.exe --launcher.openFile C:\mytestfile.js";
alert(testapp.executecmd(command)); // Nothing returned at all.
</script>
</body>
</html>
My class:
package systemcmd;
import java.applet.Applet;
import java.io.IOException;
import java.security.AccessController;
//import java.security.PrivilegedAction;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
public class Runcmd extends Applet {
private static final long serialVersionUID = -4370650602318597069L;
/**
* #param args
*/
public static void main(String[] args) {
}
public String say(String arg)
{
String msg[] = {null};
msg[0] = "In Say. You said: " + arg;
String output ="";
for(String str: msg)
output=output+str;
return output;
}
public String executecmd(final String cmd) throws IOException
{
final String msg[] = {null};
String output ="";
msg[0] = "In executecmd, cmd="+cmd;
try {
try {
AccessController.doPrivileged(
new PrivilegedExceptionAction() {
public Object run() throws IOException { //RuntimeException,
msg[1] = " Pre exec()";
Runtime.getRuntime().exec(cmd);
msg[2] = " Post exec()";
return null;
}
}
);
} catch (PrivilegedActionException e) {
msg[3] = " Caught PrivilegedActionException:"+ e.toString();
throw (IOException) e.getException();
}
}
catch (Exception e) {
msg[4] = " Command:" + cmd + ". Exception:" + e.toString();
}
msg[5] = " End of executecmd.";
for(String str: msg)
output=output+str;
return output;
}
}
Set Eclipse as the default consumer for .java files and use Desktop.open(File) which..
Launches the associated application to open the file.
Ok, #Andrew. Some progress, thank you!
I set the default program for *.js files to Eclipse and if I double click a file it opens in Eclipse. All good.
I then had success running the following using RunAs Java Application - the test file opened in Eclipse. Getting closer!
public class Runcmd extends Applet {
File file;
private static Desktop desktop;
private static final long serialVersionUID = -4370650602318597069L;
/**
* #param args
* #throws IOException
*/
public static void main(String[] args) throws IOException {
System.out.println("hello");
if (Desktop.isDesktopSupported()) {
desktop = Desktop.getDesktop();
}
File file = new File("C:\\sites\\test.js");
// This works if I execute it from the Eclipse RunsAs Java Application.
// ie the file is opened in Eclipse for editing.
// And, if I specify a non-existant file, it correctly throws and prints the error
try {
desktop.open(file);
} catch (Exception ioe) {
ioe.printStackTrace();
System.out.println("Error: " + ioe.toString());
}
}}
However, when I added the following method and ran it via the DeployJava.js (as per my original post above), I get the following output returned with the error appearing whether or not the jar is self signed.
Started: , Desktop is supported , Error:
java.security.AccessControlException: access denied
("java.awt.AWTPermission" "showWindowWithoutWarningBanner")
public static String openfile(String arg) {
String output = "Started: ";
File file = new File("C:\\sites\\test.js");
if (Desktop.isDesktopSupported()) {
desktop = Desktop.getDesktop();
output = output + ", Desktop is supported ";
}
try {
desktop.open(file);
} catch (Exception ioe) {
output = output + ", Error: " + ioe.toString();
}
return output + arg;
}
So, what do I need to add to get around the apparent security issue? I have read the docs and the tutorials and I am going around in circles! There seems to be a lot of conflicting advice. :-(
Thanks again,
Murray
I mentioned a small demo. in
Setting up policies for an Applet embedded in HTML & an Iced Tea JRE user commented that the demo. failed
for them. They refused permission to the applet (thereby limiting it to the sand-box) & were supposed to see
the green colored 'this applet is sand-boxed' page. Instead the applet completely failed and they saw a 'gray space'
where the applet should have been.
I am WAGing that it was attempting to instantiate a File object that is the difference. I.E.
The Sun/Oracle JRE will allow it without problem, only throwing a security exception
when the applet attempts to create the JFileChooser. OTOH the Iced Tea JRE does not allow the
File to be created.
As such, this code should fix that problem. It moves the creation/adding of the
JEditorPane and installation of 1st
an 'all else fails' message, then the green colored 'sand-boxed' page, to before the new File(..) call.
My question is. Does this code 'work as advertised' for users with an Iced Tea JRE?
To test it:
Visit the applet at
pscode.org/test/docload/applet-latest.html
Refuse the digitally signed code. This is very important to create the right
conditions to test the applet.
Observe/report whether the applet loads the green colored
sandbox.html. The sand-boxed
document will represent 'success' at fixing the bug.
Also of interest (what little there might be) is the homepage for the
Demo of Defensive Loading of Trusted Applets, which links
to the applet page(s), each of the HTML files displayed in the applet, and a ZIP archive containing the
source of the code & HTML, and an Ant build.xml so you can 'do this at home, kids'.
Here is the new code.
package org.pscode.eg.docload;
import java.awt.BorderLayout;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JApplet;
import javax.swing.JButton;
import javax.swing.JEditorPane;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JFileChooser;
import java.net.URL;
import java.net.MalformedURLException;
import java.io.File;
import java.io.IOException;
import java.security.AccessControlException;
/** An applet to display documents that are JEditorPane compatible.
This applet loads in a defensive way in terms of the security environment,
in case the user has refused to accept the digitally signed code. */
public class DocumentLoader extends JApplet {
JEditorPane document;
#Override
public void init() {
System.out.println("init()");
JPanel main = new JPanel();
main.setLayout( new BorderLayout() );
getContentPane().add(main);
document = new JEditorPane("text/html",
"<html><body><h1>Testing</h1><p>Testing security environment..");
main.add( new JScrollPane(document), BorderLayout.CENTER );
System.out.println("init(): entering 'try'");
try {
// set up the green 'sandboxed URL', as a precaution..
URL sandboxed = new URL(getDocumentBase(), "sandbox.html");
document.setPage( sandboxed );
// It might seem odd that a sandboxed applet can /instantiate/
// a File object, but until it goes to do anything with it, the
// JVM considers it 'OK'. Until we go to do anything with a
// 'File' object, it is really just a filename.
System.out.println("init(): instantiate file");
File f = new File(".");
System.out.println("init(): file instantiated, create file chooser");
// Everything above here is possible for a sandboxed applet
// *test* if this applet is sandboxed
final JFileChooser jfc =
new JFileChooser(f); // invokes security check
jfc.setFileSelectionMode(JFileChooser.FILES_ONLY);
jfc.setMultiSelectionEnabled(false);
System.out.println(
"init(): file chooser created, " +
"create/add 'Load Document' button");
JButton button = new JButton("Load Document");
button.addActionListener( new ActionListener(){
public void actionPerformed(ActionEvent ae) {
int result = jfc.showOpenDialog(
DocumentLoader.this);
if ( result==JFileChooser.APPROVE_OPTION ) {
File temp = jfc.getSelectedFile();
try {
URL page = temp.toURI().toURL();
document.setPage( page );
} catch(Exception e) {
e.printStackTrace();
}
}
}
} );
main.add( button, BorderLayout.SOUTH );
// the applet is trusted, change to the red 'welcome page'
URL trusted = new URL(getDocumentBase(), "trusted.html");
document.setPage(trusted);
} catch (MalformedURLException murle) {
murle.printStackTrace();
document.setText( murle.toString() );
} catch (IOException ioe) {
ioe.printStackTrace();
document.setText( ioe.toString() );
} catch (AccessControlException ace) {
ace.printStackTrace();
// document should already be showing sandbox.html
}
}
#Override
public void start() {
System.out.println("start()");
}
#Override
public void stop() {
System.out.println("stop()");
}
#Override
public void destroy() {
System.out.println("destroy()");
}
}
Here is the output on java.stderr (one half of the equivalent of the Java console - the other half is java.stdout, which is empty in your case):
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:604)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
at sun.applet.AppletPanel.run(AppletPanel.java:380)
at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
at sun.applet.AppletPanel.run(AppletPanel.java:430)
at java.lang.Thread.run(Thread.java:636)
java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
java.lang.RuntimeException: Failed to handle message: handle 60822154 for instance 2
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:660)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
Caused by: java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
... 2 more
So, it looks like your applet code is not even loaded if I press Cancel in the dialog box.
I think there is nothing you can do here from the Java side - maybe using another signing procedure or starting the applet by JNLP would help. Or filing a bug report on IcedTea.
To demonstrate this, I created a real simple applet by omitting everything critical from your applet:
package org.pscode.eg.docload;
import java.awt.FlowLayout;
import javax.swing.*;
public class Example extends JApplet {
JLabel label;
public void init()
{
System.out.println("init()");
SwingUtilities.invokeLater(new Runnable(){public void run() {
label = new JLabel("inited.");
getContentPane().setLayout(new FlowLayout());
getContentPane().add(label);
}});
}
#Override
public void start() {
System.out.println("start()");
label.setText("started.");
}
#Override
public void stop() {
System.out.println("stop()");
label.setText("stopped.");
}
#Override
public void destroy() {
System.out.println("destroy()");
label.setText("destroyed.");
}
}
I compiled this and modified your HTML file to use this instead, and it gives totally the same symptoms.
It seems IcedTea has redefined what to do when the user presses cancel. To be fair, the buttons in the dialog box are "Run" and "Cancel", not "Run with all permissions" and "Run sandboxed".
(In Sun's dialog there are the same buttons, but in effect they mean something else than asked.)
For reference, I can confirm #Paŭlo Ebermann's results using IcedTea 1.9.7 on Ubuntu 10.04:
$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1~10.04.1)
OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)
appletviewer shows the expected sandbox and the fllowing diagnostic output. Firefox on Ubuntu offers only Run (trusted) or Cancel (nothing).
$ appletviewer http://pscode.org/test/docload/applet-latest.html
Warning: Can't read AppletViewer properties file: … Using defaults.
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
at java.lang.System.getProperty(System.java:669)
at javax.swing.filechooser.FileSystemView.getHomeDirectory(FileSystemView.java:397)
at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:282)
at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:153)
at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:155)
at javax.swing.JComponent.setUI(JComponent.java:651)
at javax.swing.JFileChooser.updateUI(JFileChooser.java:1781)
at javax.swing.JFileChooser.setup(JFileChooser.java:374)
at javax.swing.JFileChooser.(JFileChooser.java:347)
at javax.swing.JFileChooser.(JFileChooser.java:330)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at java.lang.Thread.run(Thread.java:636)
start()
stop()
destroy()
On Mac OS X, Safari 5.05 produces the expected results; and appletviewer produces comparable, but not identical, output.
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
$ appletviewer http://pscode.org/test/docload/applet-latest.html
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.io.FilePermission . read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:731)
at javax.swing.JFileChooser.setCurrentDirectory(JFileChooser.java:548)
at javax.swing.JFileChooser.(JFileChooser.java:334)
at javax.swing.JFileChooser.(JFileChooser.java:316)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:424)
at java.lang.Thread.run(Thread.java:680)
start()
stop()
destroy()