Hi, I'm using the java plugin version 1.5.0_5 and every time I go from my
web page that has the applet to another web page the applet.destroy() method
occurs and all my resources are closed. My threads are closed, my JFrames
are closed and my PipedInputStream and PipledOutputStream are closed. I
tried storing these resouces in a static field which does keep the objects
but the objects are still dead. Is there any way to keep these resources
alive? Here is a simple test:
public class AppletBase extends JApplet {
public void init() {
JButton button = new JButton("Push me2");
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
JFrame frame = new JFrame("Title");
frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
frame.getContentPane().add(new JTree());
frame.pack();
frame.setVisible(true);
}
});
getContentPane().setLayout(new FlowLayout());
getContentPane().add(button);
}
}
In the above example, that frame will close when the browser with the applet
goes to another web page. How can I get the frame to stay?
If I can't do it within the applet sandbox how about if I sign the applet?
Troy
Troy
Andrew Thompson - 07 Oct 2005 04:20 GMT
> If I can't do it within the applet sandbox how about if I sign the applet?
No. Browsers (should) destroy the applet and resources
on page exit, though the *browser* should also cache
classes and images etcetera.
You might play tricks with putting the series of pages in
'frames' and placing a 'storage applet' in a hidden frame,
but..
When dealing with applets, there is only one thing you can
rely on. Even if you found a way that worked in one browser,
there would be another browser in which it breaks.
troy makaro - 07 Oct 2005 04:33 GMT
I think the only way to do it is to sign the applet and then create the
resources in a different thread group. I tried this and it does work.
Troy
> Hi, I'm using the java plugin version 1.5.0_5 and every time I go from my
> web page that has the applet to another web page the applet.destroy()
[quoted text clipped - 31 lines]
>
> Troy
Andrew Thompson - 07 Oct 2005 07:25 GMT
> I think the only way to do it is to sign the applet and then create the
> resources in a different thread group. I tried this and it does work.
<zen question>
In which browser, running which VM?
<zen question>
Where is your page* where I can test that concept
with 4 different browsers running 3 different VM's?
* URL..
Roedy Green - 07 Oct 2005 09:45 GMT
>Is there any way to keep these resources
>alive? Here is a simple test:
Put them in a static. That should survive anything but the
classloader being nullified.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Roedy Green - 07 Oct 2005 09:47 GMT
>In the above example, that frame will close when the browser with the applet
>goes to another web page. How can I get the frame to stay?
>If I can't do it within the applet sandbox how about if I sign the applet?
This is a completely different question from how to hold onto loaded
resources. A Frame is not a resource. Even if I knew, I would not
tell you. That would be the Applet from hell.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
troy makaro - 07 Oct 2005 16:46 GMT
I actually don't want a JFrame. I used it as an example that was small. I'm
more concerned with threads and input/output streams. These die even if they
are in a static field as you suggested in a previous post. I am writing a
terminal emulator that I want imedded in an applet not a frame and if a user
goes from one page and to another page and then returns, I want the terminal
emulator to be exactly where it left off.
Troy
>>In the above example, that frame will close when the browser with the
>>applet
[quoted text clipped - 4 lines]
> resources. A Frame is not a resource. Even if I knew, I would not
> tell you. That would be the Applet from hell.
Roedy Green - 07 Oct 2005 23:11 GMT
>I actually don't want a JFrame. I used it as an example that was small. I'm
>more concerned with threads and input/output streams. These die even if they
>are in a static field as you suggested in a previous post. I am writing a
>terminal emulator that I want imedded in an applet not a frame and if a user
>goes from one page and to another page and then returns, I want the terminal
>emulator to be exactly where it left off.
If your app is independent of the browser, perhaps you should cut the
apron strings and allow the browser to terminate without affecting
you.
See http://mindprod.com/jgloss/javawebstart.html

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Andrew Thompson - 08 Oct 2005 08:00 GMT
..
> If your app is independent of the browser, perhaps you should cut the
> apron strings and allow the browser to terminate without affecting
> you.
> See http://mindprod.com/jgloss/javawebstart.html
That's a good idea. I do not think this would be practical
as an applet or series of applets.