🚀 go-pugleaf

Here's a snippit from : <http://java.sun.com/products/jfc/tsc/swingdoc-current/911.html>



Q: Why does my applet cause a warning message to be printed  on the browser's
"Java Console?"

A: Most browsers unconditionally print a console message when  Swing makes its on-
time AWT system event queue check; IE4 prints a backtrace,  and Navigator prints a
short message.

If you're deploying an applet that does not serve double duty as part  of an application,
you can short-circuit the event-queue check by setting  a special property on the
 JApplet's root pane, using a technique similar  to this:

                /* This will prevent the "SystemEventQueue"
                * access message from appearing in the Java console
                * when this applet is run in a browser. */
                applet.getRootPane().putClientProperty
                   ("defeatSystemEventQueueCheck", Boolean.TRUE);


ken wrote:

> I know I'm wrong, I just want someone to TELL me I'm wrong - and to show
> me why.
>
> I'm having trouble getting a response to the following observation that
> I've posted about a few times.
> It appears to me that if you write APPLETS  in Swing, then even if you
> DON'T attempt to escape the sandbox, you still have to take on all the
> painful, browser-specific security measures (such as applet-signing and
> the inclusion of calls to various incompatible security packages.) And I
> find
> this outrageous, if it's really true.
>
> I'm forced to this conclusion by the fact that I decided some time ago
> that the whole security thing was a mess, and I decided to take every
> measure necessary to avoid it for as long as I could. Functionally, my
> applet did not require me to escape the sandbox to do its job.
>
> Because I had a background in Swing application development, I decided
> to implement my applets in Swing. I discovered that the architecture of
> Swing is such that ANY applet (that fires an event - and what
> non-trivial applets don't?) MUST exceed the constraints normally placed
> on applets, and therefore, you cannot deploy applets written in Swing
> without having to take these extra security measures.
>
> I posted the following angry  rant to JDC's GroupReader/Toolbar. To date
> it has generated (0) responses. There are two short messages, followed
> by my (probably erroneous) reasons for
> stating the above.
>
> kbarclay
> kebarcla@hotmail.com
>
> Path: developer.java.sun.com!unseng
> From: unseng
> Newsgroups: swing
> Subject: Swing: checked access to system event queue.
> Date: Mon Aug 03 13:41:15 PDT 1998
> Organization: Java Developers Connection
> Message-ID: <289024973$815@developer.java.sun.com>
> JDC-state: closed
> JDC-points: 1
> JDC-notify: true
> NNTP-Posting-Host: developer.java.sun.com
>
> Hi:
>
> Does Anyone know that what is that means? "Swing: checked access to
> system event queue."
> That is generated by initialization of my JApplet. Is that related to
> signed and unsigned applet?
> My program also threw a AppletSecurityException as
> "checkawteventqueueaccess". This exception is
> thrown when the program tried to pop-up a dialog box.
>
> The Dialog box is created by below code:
>
>  int userAnswer = JOptionPane.showInternalConfirmDialog(
>     this,
>     "Save the changes to this window?",
>                            "Save Changes",
>                            JOptionPane.YES_NO_CANCEL_OPTION,
>     JOptionPane.WARNING_MESSAGE);
>
> Is anyone known how to work around with it???
>
> Thanks in Advance
>
> Seng
>
> Answers
> ======
>
> ** From: heyhey
> Replied: Tue Aug 04 00:04:08 PDT 1998
>
> This is known behaviour.
> Read swing's file
>
>   CHANGES.TXT
>
>  section
>
> ==============
>  Applet Changes
> ==============
>
> ** From: kbarclay
> Replied: Tue Aug 04 09:56:36 PDT 1998
>
> heyhey suggests the old "hack" of putting
>
> applet.getRootPane().putClientProperty("defeatSystemEventQueueCheck",
> Boolean.TRUE);
>
> in your applet code to subdue the security exceptions. I found this 100%
> ineffective in solving the
> security problems; in fact, it doesn't even quiet the salacious little
> warning that says:
>
> "Swing: checked access to system event queue."
>
> Maybe I'm not placing it in the correct location? I tried the init
> method, and ...and  the little test applet
> I put this in is only a dozen lines long, so there aren't many other
> places to put it.
>
> This applet comes with the Swing release: it's called SwingApplet.java.
> I pared it down to a bare
> minimum and pasted it below so you can see that this applet really does
> almost nothing except
> put a button onto the page. Yet when you put the little applet on a
> webserver and deploy it, when
> you stab the little button, you get (in IE4.0) the stack trace that I've
> pasted below the code.
>  (It runs fine in NS4.05/preview release.)
>
> Since IE4 was written by the Evil Empire I looked in The Java Class
> Libraries Vol 1 by Chan and Lee
> to see what behavior is specified in these circumstances. From what Sun
> says should be happening,
> it appears that Microsoft's VM is doing what it should, and Netscape's
> is failing to throw an
> exception. On page 1485 it says:
>
> "Gaining a reference to the system event queue has security
> implications. This is because with
> the reference, you can read the queue's contents or post events to it."
>
> That makes sense. You obviously can't have any old applet posting events
> to your event queue.
>
> Let me see if I understand correctly the implications of this.
>
> 1) Swing is written in such a way that, as a matter of fact, when an
> event is fired, it needs to get a
> reference to the event queue.
> 2) Getting such a reference is a *privileged* operation - like making a
> socket connection to a
> computer other than the applet's host, or reading/writing files on the
> user's computer.
> 3) Therefore, any applet written in Swing, no matter how trivial,
> requires that one go through all
> the contortions that are necessary when you're trying to produce an
> applet that can "break out of
> the sandbox."
>
> Because this is insane, I KNOW I must be wrong.
>
> I just know that any day now, someone  at the forefront of Swing
> development is going to tell me that
>  I can write applets in Swing that don't try to escape the sandbox
> without having to go through the
> SOLID NIGHTMARE of having to sign my applets using two (or is it three?)
> incompatible applet
> signing tools, and/or download two incompatible sets of security classes
> (Microsoft's
> com.ms.Security classes from SDK 3.0, or Netscape's security classes)
> and then keep two
> completely separate sets of code for each of the two predominant
> browsers.
>
> It doesn't seem reasonable to me that my users can't just hit a page
> with an applet embedded
> in it and have it download and run. It's not reasonable that I have to
> go through Security Hell in
> my applet development process if I'm not trying to escape the sandbox.
>
> My users should not have to download a five-meg plugin to run my applet.
> They shouldn't have
> to copy jar files to some directory that's visible to their browser, or
> tweak security settings in
> various dialogs in their browser. And they are, as a matter of fact,
> evenly divided between
> IE4 and Netscape! To me that means avoiding RMI and any other package
> Microsoft doesn't
> want to support. Users don't care if you use sockets and streams or if
> you use RMI. They DO
> care if they have to download a giant plugin before running your applet.
>
> I'm running Swing 1.0.3/jdk 1.1.6 on an NT Box.
> If anyone knows how to run the following 12 lines of code in IE4 without
> throwing security
> exceptions, please email me or post.
>
> Thanks,
>
> Ken
> kebarcla@hotmail.com
>
> /*
>  * @(#)SwingApplet.java 1.9 98/02/23
>  */
>
> import java.awt.*;
> import java.awt.event.*;
> import java.net.*;
> import java.applet.*;
> import com.sun.java.swing.*;
>
> /**
>  * A very simple applet.
>  */
> public class SwingApplet extends JApplet {
>
>     JButton button;
>
>     public void init() {
>
>         getRootPane().putClientProperty("defeatSystemEventQueueCheck",
> Boolean.TRUE);
>
>         getContentPane().setLayout(new FlowLayout());
>         button = new JButton("Hello, I'm a Swing Button!");
>         getContentPane().add(button);
>     }
>
>     public void stop() {
>         if (button != null) {
>             getContentPane().remove(button);
>             button = null;
>         }
>     }
> }
>
> The stack trace is:
>
> com.ms.security.SecurityExceptionEx[com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue]:
>
>  Event queue access denied.
>  at com/ms/security/permissions/UIPermission.check
>  at com/ms/security/PolicyEngine.deepCheck
>  at com/ms/security/PolicyEngine.checkPermission
>  at com/ms/security/StandardSecurityManager.chk
>  at com/ms/security/StandardSecurityManager.checkAwtEventQueueAccess
>  at java/awt/Toolkit.getSystemEventQueue
>  at com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue
>  at com/sun/java/swing/SystemEventQueueUtilities.postRunnable
>  at com/sun/java/swing/SwingUtilities.invokeLater
>  at com/sun/java/swing/RepaintManager.queueWorkRequest
>  at com/sun/java/swing/RepaintManager.addDirtyRegion
>  at com/sun/java/swing/JComponent.repaint
>  at java/awt/Component.repaint
>  at java/awt/Component.repaint
>  at com/sun/java/swing/plaf/basic/BasicButtonListener.stateChanged
>  at com/sun/java/swing/AbstractButton.fireStateChanged
>  at com/sun/java/swing/AbstractButton$ButtonChangeListener.stateChanged
>  at com/sun/java/swing/DefaultButtonModel.fireStateChanged
>  at com/sun/java/swing/DefaultButtonModel.setRollover
>  at com/sun/java/swing/plaf/windows/WindowsButtonListener.mouseEntered
>  at java/awt/Component.processMouseEvent
>  at java/awt/Component.processEvent
>  at java/awt/Container.processEvent
>  at java/awt/Component.dispatchEventImpl
>  at java/awt/Container.dispatchEventImpl
>  at java/awt/Component.dispatchEvent
>  at java/awt/LightweightDispatcher.retargetMouseEvent
>  at java/awt/LightweightDispatcher.setMouseTarget
>  at java/awt/LightweightDispatcher.processMouseEvent
>  at java/awt/LightweightDispatcher.dispatchEvent
>  at java/awt/Container.dispatchEventImpl
>  at java/awt/Component.dispatchEvent
>  at java/awt/EventDispatchThread.run
> Swing: checked access to system event queue.
> Microsoft (R) VM for Java (tm), 4.0 Release 4.79.0.2339
>
> POSTSCRIPT:
>
> In the readme.txt file that comes with SwingApplet.java, it says:
>
> "When you successfully run the applet, you might see a message about a
> security exception.  It starts like this:
>
>    sun.applet.AppletSecurityException: checkawteventqueueaccess
>
> Please ignore this exception."
>
> And I most willingly DO ignore the exception when it's put out by the
> appletviewer. When I actually
> try to do stuff in a more sophisticated applet, though, and try to run
> it off my webserver, it throws
> the exception above and chokes.

I've gotten it to work. You just need to make sure you are using the newest
version of SWING. 1.0 DIDNT work with applets, but 1.0.1 and later will.

In my latest applet, I've been using the Java plugin and that works quite
well in both browsers...

--Jason Cwik

ken wrote in message <35C76F4B.EEC8C141@hotmail.com>...
>I know I'm wrong, I just want someone to TELL me I'm wrong - and to show
>me why.
>
>I'm having trouble getting a response to the following observation that
>I've posted about a few times.
>It appears to me that if you write APPLETS  in Swing, then even if you
>DON'T attempt to escape the sandbox, you still have to take on all the
>painful, browser-specific security measures (such as applet-signing and
>the inclusion of calls to various incompatible security packages.) And I
>find
>this outrageous, if it's really true.
>
>I'm forced to this conclusion by the fact that I decided some time ago
>that the whole security thing was a mess, and I decided to take every
>measure necessary to avoid it for as long as I could. Functionally, my
>applet did not require me to escape the sandbox to do its job.
>
>Because I had a background in Swing application development, I decided
>to implement my applets in Swing. I discovered that the architecture of
>Swing is such that ANY applet (that fires an event - and what
>non-trivial applets don't?) MUST exceed the constraints normally placed
>on applets, and therefore, you cannot deploy applets written in Swing
>without having to take these extra security measures.
>
>I posted the following angry  rant to JDC's GroupReader/Toolbar. To date
>it has generated (0) responses. There are two short messages, followed
>by my (probably erroneous) reasons for
>stating the above.
>
>kbarclay
>kebarcla@hotmail.com
>
>
>Path: developer.java.sun.com!unseng
>From: unseng
>Newsgroups: swing
>Subject: Swing: checked access to system event queue.
>Date: Mon Aug 03 13:41:15 PDT 1998
>Organization: Java Developers Connection
>Message-ID: <289024973$815@developer.java.sun.com>
>JDC-state: closed
>JDC-points: 1
>JDC-notify: true
>NNTP-Posting-Host: developer.java.sun.com
>
>Hi:
>
>
>Does Anyone know that what is that means? "Swing: checked access to
>system event queue."
>That is generated by initialization of my JApplet. Is that related to
>signed and unsigned applet?
>My program also threw a AppletSecurityException as
>"checkawteventqueueaccess". This exception is
>thrown when the program tried to pop-up a dialog box.
>
>The Dialog box is created by below code:
>
> int userAnswer = JOptionPane.showInternalConfirmDialog(
>    this,
>    "Save the changes to this window?",
>                           "Save Changes",
>                           JOptionPane.YES_NO_CANCEL_OPTION,
>    JOptionPane.WARNING_MESSAGE);
>
>Is anyone known how to work around with it???
>
>Thanks in Advance
>
>Seng
>
>
>
>
>Answers
>======
>
>
>** From: heyhey
>Replied: Tue Aug 04 00:04:08 PDT 1998
>
>This is known behaviour.
>Read swing's file
>
>  CHANGES.TXT
>
> section
>
>==============
> Applet Changes
>==============
>
>
>** From: kbarclay
>Replied: Tue Aug 04 09:56:36 PDT 1998
>
>heyhey suggests the old "hack" of putting
>
>applet.getRootPane().putClientProperty("defeatSystemEventQueueCheck",
>Boolean.TRUE);
>
>in your applet code to subdue the security exceptions. I found this 100%
>ineffective in solving the
>security problems; in fact, it doesn't even quiet the salacious little
>warning that says:
>
>"Swing: checked access to system event queue."
>
>Maybe I'm not placing it in the correct location? I tried the init
>method, and ...and  the little test applet
>I put this in is only a dozen lines long, so there aren't many other
>places to put it.
>
>This applet comes with the Swing release: it's called SwingApplet.java.
>I pared it down to a bare
>minimum and pasted it below so you can see that this applet really does
>almost nothing except
>put a button onto the page. Yet when you put the little applet on a
>webserver and deploy it, when
>you stab the little button, you get (in IE4.0) the stack trace that I've
>pasted below the code.
> (It runs fine in NS4.05/preview release.)
>
>Since IE4 was written by the Evil Empire I looked in The Java Class
>Libraries Vol 1 by Chan and Lee
>to see what behavior is specified in these circumstances. From what Sun
>says should be happening,
>it appears that Microsoft's VM is doing what it should, and Netscape's
>is failing to throw an
>exception. On page 1485 it says:
>
>"Gaining a reference to the system event queue has security
>implications. This is because with
>the reference, you can read the queue's contents or post events to it."
>
>That makes sense. You obviously can't have any old applet posting events
>to your event queue.
>
>Let me see if I understand correctly the implications of this.
>
>1) Swing is written in such a way that, as a matter of fact, when an
>event is fired, it needs to get a
>reference to the event queue.
>2) Getting such a reference is a *privileged* operation - like making a
>socket connection to a
>computer other than the applet's host, or reading/writing files on the
>user's computer.
>3) Therefore, any applet written in Swing, no matter how trivial,
>requires that one go through all
>the contortions that are necessary when you're trying to produce an
>applet that can "break out of
>the sandbox."
>
>Because this is insane, I KNOW I must be wrong.
>
>I just know that any day now, someone  at the forefront of Swing
>development is going to tell me that
> I can write applets in Swing that don't try to escape the sandbox
>without having to go through the
>SOLID NIGHTMARE of having to sign my applets using two (or is it three?)
>incompatible applet
>signing tools, and/or download two incompatible sets of security classes
>(Microsoft's
>com.ms.Security classes from SDK 3.0, or Netscape's security classes)
>and then keep two
>completely separate sets of code for each of the two predominant
>browsers.
>
>It doesn't seem reasonable to me that my users can't just hit a page
>with an applet embedded
>in it and have it download and run. It's not reasonable that I have to
>go through Security Hell in
>my applet development process if I'm not trying to escape the sandbox.
>
>My users should not have to download a five-meg plugin to run my applet.
>They shouldn't have
>to copy jar files to some directory that's visible to their browser, or
>tweak security settings in
>various dialogs in their browser. And they are, as a matter of fact,
>evenly divided between
>IE4 and Netscape! To me that means avoiding RMI and any other package
>Microsoft doesn't
>want to support. Users don't care if you use sockets and streams or if
>you use RMI. They DO
>care if they have to download a giant plugin before running your applet.
>
>I'm running Swing 1.0.3/jdk 1.1.6 on an NT Box.
>If anyone knows how to run the following 12 lines of code in IE4 without
>throwing security
>exceptions, please email me or post.
>
>Thanks,
>
>Ken
>kebarcla@hotmail.com
>
>/*
> * @(#)SwingApplet.java 1.9 98/02/23
> */
>
>import java.awt.*;
>import java.awt.event.*;
>import java.net.*;
>import java.applet.*;
>import com.sun.java.swing.*;
>
>/**
> * A very simple applet.
> */
>public class SwingApplet extends JApplet {
>
>    JButton button;
>
>    public void init() {
>
>        getRootPane().putClientProperty("defeatSystemEventQueueCheck",
>Boolean.TRUE);
>
>        getContentPane().setLayout(new FlowLayout());
>        button = new JButton("Hello, I'm a Swing Button!");
>        getContentPane().add(button);
>    }
>
>    public void stop() {
>        if (button != null) {
>            getContentPane().remove(button);
>            button = null;
>        }
>    }
>}
>
>The stack trace is:
>
>com.ms.security.SecurityExceptionEx[com/sun/java/swing/SystemEventQueueUtil
ities.initSystemEventQueue]:
>
> Event queue access denied.
> at com/ms/security/permissions/UIPermission.check
> at com/ms/security/PolicyEngine.deepCheck
> at com/ms/security/PolicyEngine.checkPermission
> at com/ms/security/StandardSecurityManager.chk
> at com/ms/security/StandardSecurityManager.checkAwtEventQueueAccess
> at java/awt/Toolkit.getSystemEventQueue
> at com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue
> at com/sun/java/swing/SystemEventQueueUtilities.postRunnable
> at com/sun/java/swing/SwingUtilities.invokeLater
> at com/sun/java/swing/RepaintManager.queueWorkRequest
> at com/sun/java/swing/RepaintManager.addDirtyRegion
> at com/sun/java/swing/JComponent.repaint
> at java/awt/Component.repaint
> at java/awt/Component.repaint
> at com/sun/java/swing/plaf/basic/BasicButtonListener.stateChanged
> at com/sun/java/swing/AbstractButton.fireStateChanged
> at com/sun/java/swing/AbstractButton$ButtonChangeListener.stateChanged
> at com/sun/java/swing/DefaultButtonModel.fireStateChanged
> at com/sun/java/swing/DefaultButtonModel.setRollover
> at com/sun/java/swing/plaf/windows/WindowsButtonListener.mouseEntered
> at java/awt/Component.processMouseEvent
> at java/awt/Component.processEvent
> at java/awt/Container.processEvent
> at java/awt/Component.dispatchEventImpl
> at java/awt/Container.dispatchEventImpl
> at java/awt/Component.dispatchEvent
> at java/awt/LightweightDispatcher.retargetMouseEvent
> at java/awt/LightweightDispatcher.setMouseTarget
> at java/awt/LightweightDispatcher.processMouseEvent
> at java/awt/LightweightDispatcher.dispatchEvent
> at java/awt/Container.dispatchEventImpl
> at java/awt/Component.dispatchEvent
> at java/awt/EventDispatchThread.run
>Swing: checked access to system event queue.
>Microsoft (R) VM for Java (tm), 4.0 Release 4.79.0.2339
>
>POSTSCRIPT:
>
>In the readme.txt file that comes with SwingApplet.java, it says:
>
>"When you successfully run the applet, you might see a message about a
>security exception.  It starts like this:
>
>   sun.applet.AppletSecurityException: checkawteventqueueaccess
>
>Please ignore this exception."
>
>And I most willingly DO ignore the exception when it's put out by the
>appletviewer. When I actually
>try to do stuff in a more sophisticated applet, though, and try to run
>it off my webserver, it throws
>the exception above and chokes.
>
>
>
>

Jason Cwik wrote:

> I've gotten it to work. You just need to make sure you are using the newest
> version of SWING. 1.0 DIDNT work with applets, but 1.0.1 and later will.
>
> In my latest applet, I've been using the Java plugin and that works quite
> well in both browsers...
>

Thanks, Jason. I think a lot of people missed my point because of the subject
string.

I already know Swing applets will work if they're signed and we use the Java
plug-in. The whole point of my posting was that with the release of Swing,
JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
WHAT. Remember, before, we only had to sign applets if they attempted to leave
the sandbox. That's no longer true! Now, anytime you write an applet, if you use
Swing to do the interface, you have to sign it - period.

To me, this is a hassle. It means I'm not going to use Swing for my applets: I'm
going to get some GUI toolkit of lightweight components so I don't have to roll
my own. My applets don't write or read files on the client machine or connect to
some random host, and applet security is a screaming nightmare if you want to
support both browsers (which I do.) I should not have to sign my applets, or use
the Java plug-in; my customers have browsers that can run 1.1 code.

It just seems a little unforthcoming on the part of JavaSoft to make such a
significant change without clearly stating they were doing so, especially when
you consider that they were earlier touting Swing as a replacement for the AWT
and asserted quite loudly that there is now no need whatsoever to use the older
components.

Cheers,

Ken

I haven't used swing much
but had on problems (other than speed) running the big JFC swing demo within
NN w/ the plug-in......
(All the controls seemed to work)
Do you mean they eventually cause errors?

>I already know Swing applets will work if they're signed and we use the
Java
>plug-in. The whole point of my posting was that with the release of Swing,
>JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO
MATTER
>WHAT. Remember, before, we only had to sign applets if they attempted to
leave
>the sandbox. That's no longer true! Now, anytime you write an applet, if
you use
>Swing to do the interface, you have to sign it - period.
>

Yes, you are quite right! Signing is an absolute horror, I do intranet stuff
and it drives me up the wall, all my applets are locally installed and I
still have hours/days of hassle with the signing stuff for all those various
VM's. Do continue to complain...

ub

ken wrote in message <35C8AF2E.BA414C1D@hotmail.com>...
[snip]
>I already know Swing applets will work if they're signed and we use the
Java
>plug-in. The whole point of my posting was that with the release of Swing,
>JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO
MATTER
>WHAT. Remember, before, we only had to sign applets if they attempted to
leave
>the sandbox. That's no longer true! Now, anytime you write an applet, if
you use
>Swing to do the interface, you have to sign it - period.
>
[snip]

ken wrote:

> I already know Swing applets will work if they're signed and we use the Java
> plug-in. The whole point of my posting was that with the release of Swing,
> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
> WHAT. Remember, before, we only had to sign applets if they attempted to leave
> the sandbox. That's no longer true! Now, anytime you write an applet, if you use
> Swing to do the interface, you have to sign it - period.

That's just not true.  You don't have to sign applets which use Swing.  If you're
having problems with your applets then it might be a bug in Swing in which case you
should log it on the JDC.  However, I know lots of people who have successfully
deployed Swing-based applets without signing.

-Steve

Were they using IE4?

Steve Wilson wrote:

> ken wrote:
>
> > I already know Swing applets will work if they're signed and we use the Java
> > plug-in. The whole point of my posting was that with the release of Swing,
> > JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
> > WHAT. Remember, before, we only had to sign applets if they attempted to leave
> > the sandbox. That's no longer true! Now, anytime you write an applet, if you use
> > Swing to do the interface, you have to sign it - period.
>
> That's just not true.  You don't have to sign applets which use Swing.  If you're
> having problems with your applets then it might be a bug in Swing in which case you
> should log it on the JDC.  However, I know lots of people who have successfully
> deployed Swing-based applets without signing.
>
> -Steve

Steve Wilson <steve@emer.com> writes:

sorry, what do you mean by "signing" an applet?


>ken wrote:

>> I already know Swing applets will work if they're signed and we use the Java
>> plug-in. The whole point of my posting was that with the release of Swing,
>> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
>> WHAT. Remember, before, we only had to sign applets if they attempted to leave
>> the sandbox. That's no longer true! Now, anytime you write an applet, if you use
>> Swing to do the interface, you have to sign it - period.

>That's just not true.  You don't have to sign applets which use Swing.  If you're
>having problems with your applets then it might be a bug in Swing in which case you
>should log it on the JDC.  However, I know lots of people who have successfully
>deployed Swing-based applets without signing.

>-Steve

--
*~~*.*~~*..*~~*.*~~*..*~~*.*~~*..*~~*.*~~*.
    H: samwun@yahoo.com
    W: SWun@vcomcss1.telstra.com.au 
    http://yallara.cs.rmit.edu.au/~twun

[This followup was posted to comp.lang.java.gui and a courtesy copy was sent
to the cited author, SAM]

On 19 Aug 1998 14:06:51 GMT, twun@cs.rmit.edu.au (SAM) wrote:

| Steve Wilson <steve@emer.com> writes:
| 
| sorry, what do you mean by "signing" an applet?

From the Java FAQ <http://www.afu.com/javafaq.html> Section 15:

"JDK 1.1 introduced the notion of a "trusted applet" which is one that has
been cryptographically signed to guarantee its origin and make it
tamper-resistant. Trusted applets can be granted more system access
privileges than untrusted applets."

HTH

davep
-- 
-- 
Dave Postill                Investment Intelligence Systems Corp
Galaxy Support Leader                +44 (0)171 628 6960 [voice]
davep@iisc.co.uk [business]          +44 (0)171 638 7528   [fax]
dave.postill@pobox.com [personal]          http://www.iisc.co.uk

>[This followup was posted to comp.lang.java.gui and a courtesy copy was
sent
>to the cited author, SAM]
>
>On 19 Aug 1998 14:06:51 GMT, twun@cs.rmit.edu.au (SAM) wrote:
>
>| Steve Wilson <steve@emer.com> writes:
>|
>| sorry, what do you mean by "signing" an applet?
>
>From the Java FAQ <http://www.afu.com/javafaq.html> Section 15:
>
>"JDK 1.1 introduced the notion of a "trusted applet" which is one that has
>been cryptographically signed to guarantee its origin and make it
>tamper-resistant. Trusted applets can be granted more system access
>privileges than untrusted applets."

Kind of like digitally signed ActiveX controls :)

Shaun

>
>HTH
>
>davep
>--
>--
>Dave Postill                Investment Intelligence Systems Corp
>Galaxy Support Leader                +44 (0)171 628 6960 [voice]
>davep@iisc.co.uk [business]          +44 (0)171 638 7528   [fax]
>dave.postill@pobox.com [personal]          http://www.iisc.co.uk

> > In my latest applet, I've been using the Java plugin and that works quite
> > well in both browsers...
> >
>
> I already know Swing applets will work if they're signed and we use the Java
> plug-in. The whole point of my posting was that with the release of Swing,
> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
> WHAT. Remember, before, we only had to sign applets if they attempted to leave
> the sandbox. That's no longer true! Now, anytime you write an applet, if you
> use Swing to do the interface, you have to sign it - period.

I've been using Swing 1.0.2 (JFC 1.1?) with IE4 and haven't need to sign
*anything*.  Everything works perfectly!  You do get a couple of stack traces
on the Java Console as Swing initializes but these can be ignored.  In fact,
I'm rather impressed with the speed of Swing once it is loaded.  All I do is
include the swingall.jar file in the archive part of the applet tag.

I do believe you're last sentance regarding Swing and signing is utter
nonsense.


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

sean.mcdermott@usa.net wrote in message <6ruu48$iid$1@nnrp1.dejanews.com>...
>
>
>> > In my latest applet, I've been using the Java plugin and that works
quite
>> > well in both browsers...
>> >
>>
>> I already know Swing applets will work if they're signed and we use the
Java
>> plug-in. The whole point of my posting was that with the release of
Swing,
>> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO
MATTER
>> WHAT. Remember, before, we only had to sign applets if they attempted to
leave
>> the sandbox. That's no longer true! Now, anytime you write an applet, if
you
>> use Swing to do the interface, you have to sign it - period.
>
>I've been using Swing 1.0.2 (JFC 1.1?) with IE4 and haven't need to sign
>*anything*.  Everything works perfectly!  You do get a couple of stack
traces
>on the Java Console as Swing initializes but these can be ignored.  In
fact,
>I'm rather impressed with the speed of Swing once it is loaded.  All I do
is
>include the swingall.jar file in the archive part of the applet tag.
>
>I do believe you're last sentance regarding Swing and signing is utter
>nonsense.


I agree. The last sentence is bunk. You only have to sign applets that
require trusted access to your local machine.

- Darryl

We are in an intranet envioronment and swing has done wonders for us.  We
haven't had to sign anything, although we have some times, but it has not
been required.  We do however, exclusively use Netscape 3 & 4.  As far as
the swing jar file, we have set up are netscape, which is served off of an
application server with the Java Plugin.  That way, no one has to download
and install the plug-in.  All they have to do is run the Control Panel and
set their plug-in preferences.

James Birchfield
BTG, Inc.

Darryl Pentz > wrote in message <6rv6f2$gk72@gcs.delta-air.com>...
>
>sean.mcdermott@usa.net wrote in message
<6ruu48$iid$1@nnrp1.dejanews.com>...
>>
>>
>>> > In my latest applet, I've been using the Java plugin and that works
>quite
>>> > well in both browsers...
>>> >
>>>
>>> I already know Swing applets will work if they're signed and we use the
>Java
>>> plug-in. The whole point of my posting was that with the release of
>Swing,
>>> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO
>MATTER
>>> WHAT. Remember, before, we only had to sign applets if they attempted to
>leave
>>> the sandbox. That's no longer true! Now, anytime you write an applet, if
>you
>>> use Swing to do the interface, you have to sign it - period.
>>
>>I've been using Swing 1.0.2 (JFC 1.1?) with IE4 and haven't need to sign
>>*anything*.  Everything works perfectly!  You do get a couple of stack
>traces
>>on the Java Console as Swing initializes but these can be ignored.  In
>fact,
>>I'm rather impressed with the speed of Swing once it is loaded.  All I do
>is
>>include the swingall.jar file in the archive part of the applet tag.
>>
>>I do believe you're last sentance regarding Swing and signing is utter
>>nonsense.
>
>
>I agree. The last sentence is bunk. You only have to sign applets that
>require trusted access to your local machine.
>
>- Darryl
>
>

My clients must use the Java Plug-In to access the program I'm
writing.  In all actuality, I notice the Java Plug-In is quite faster.
It seems to initialize and run faster..I'm impressed with it.
\/


On Tue, 25 Aug 1998 18:00:40 GMT, sean.mcdermott@usa.net wrote:

>
>
>> > In my latest applet, I've been using the Java plugin and that works quite
>> > well in both browsers...
>> >
>>
>> I already know Swing applets will work if they're signed and we use the Java
>> plug-in. The whole point of my posting was that with the release of Swing,
>> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO MATTER
>> WHAT. Remember, before, we only had to sign applets if they attempted to leave
>> the sandbox. That's no longer true! Now, anytime you write an applet, if you
>> use Swing to do the interface, you have to sign it - period.
>
>I've been using Swing 1.0.2 (JFC 1.1?) with IE4 and haven't need to sign
>*anything*.  Everything works perfectly!  You do get a couple of stack traces
>on the Java Console as Swing initializes but these can be ignored.  In fact,
>I'm rather impressed with the speed of Swing once it is loaded.  All I do is
>include the swingall.jar file in the archive part of the applet tag.
>
>I do believe you're last sentance regarding Swing and signing is utter
>nonsense.
>
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Darryl Pentz wrote:
> ...
> 
> I agree. The last sentence is bunk. You only have to sign applets that
> require trusted access to your local machine.
> 
> - Darryl

There is one scenario where I have found that you have trouble if you
don't sign the applet.  That is when you use Netscape (no problem with
IE) and you use a tool (like Sybase's PowerJ) that will build for you a
custom jar file with your applet code plus the pieces of swing that you
actually use.  That makes for a much shorter load time, but some pieces
of swing don't work well any more (other parts work fine).  In my case
the JMenu started adding a bar at the bottom of each tear-off menu with
something about signing.

bruno

I would like all the folks that replied to this one and solve this scenario.
The gentlemen that originally posted had a good point... here goes...

If my applet implements custom events and requires access to the system
event queue this causes a security breach. Does this breach not require us
to have the applet signed in order to properly run within the browser ?

Also, with SUN's signing model, how do i specifically allocate privileges to
print ? or are these privileges blanketed and allowed ??? VJ++ 6.0 permits
us to allocate specific privileges.

Also is Microsoft's CAB file usable with the JAVA plugin ? Are all the HTML
tags CABBASE, CODEBASE, ARCHIVE all usable with all the signing methologies?

My swing applet cannot run because it access the system event queue.


Thanks

I also get the following host exception...

java.net.UnknownHostException: F

 at java.lang.Throwable.<init>(Compiled Code)

 at java.net.InetAddress.getAllByName0(Compiled Code)

 at java.net.InetAddress.getByName(Compiled Code)

 at java.net.Socket.<init>(Socket.java:97)

 at sun.net.NetworkClient.doConnect(NetworkClient.java:62)

 at sun.net.NetworkClient.openServer(NetworkClient.java:50)

 at sun.net.ftp.FtpClient.openServer(FtpClient.java:200)

 at sun.net.ftp.FtpClient.<init>(FtpClient.java:314)

 at
sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:70)

 at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(Compiled Code)

 at
sun.net.www.protocol.http.HttpURLConnection.openConnectionCheckRedirects(Com
piled Code)

 at sun.applet.AppletResourceLoader.loadJar(AppletResourceLoader.java:140)

 at sun.applet.AppletPanel.loadJarFiles(Compiled Code)

 at sun.plugin.AppletViewer.loadJarFiles(Compiled Code)

 at sun.applet.AppletPanel.runLoader(Compiled Code)

 at sun.applet.AppletPanel.run(Compiled Code)

 at java.lang.Thread.run(Compiled Code)


BlkXtasy wrote in message <35e41490.89221140@news.boeing.com>...
>My clients must use the Java Plug-In to access the program I'm
>writing.  In all actuality, I notice the Java Plug-In is quite faster.
>It seems to initialize and run faster..I'm impressed with it.
>\/
>
>
>On Tue, 25 Aug 1998 18:00:40 GMT, sean.mcdermott@usa.net wrote:
>
>>
>>
>>> > In my latest applet, I've been using the Java plugin and that works
quite
>>> > well in both browsers...
>>> >
>>>
>>> I already know Swing applets will work if they're signed and we use the
Java
>>> plug-in. The whole point of my posting was that with the release of
Swing,
>>> JavaSoft has moved us to a new era. Now you have to SIGN ALL APPLETS TO
MATTER
>>> WHAT. Remember, before, we only had to sign applets if they attempted to
leave
>>> the sandbox. That's no longer true! Now, anytime you write an applet, if
you
>>> use Swing to do the interface, you have to sign it - period.
>>
>>I've been using Swing 1.0.2 (JFC 1.1?) with IE4 and haven't need to sign
>>*anything*.  Everything works perfectly!  You do get a couple of stack
traces
>>on the Java Console as Swing initializes but these can be ignored.  In
fact,
>>I'm rather impressed with the speed of Swing once it is loaded.  All I do
is
>>include the swingall.jar file in the archive part of the applet tag.
>>
>>I do believe you're last sentance regarding Swing and signing is utter
>>nonsense.
>>
>>
>>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>>http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
>