JDK-4692415 : Jaws application freezing if you launching it as a root,throught browser on Sol
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: jaws-1.0,1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_2.4,solaris_8
  • CPU: x86,sparc
  • Submitted: 2002-05-28
  • Updated: 2002-12-17
  • Resolved: 2002-11-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
Description
Jaws application freezing if you launching it through browser as a root on both (IA,Sparc) Solaris platform, Linux is Ok.
tested on SolarisSparc8 and SolarisIA8
j2re1.4.1(build13), jaws1.2 (build10)

Steps:
- login as a root
- install jre with javaws
- try to launch any demo application
- application freezing
you only can launch application from Application Manager

This is log file:
Java Web Start 1.2-beta Console, started Fri May 24 16:18:28 PDT 2002
Java 2 Runtime Environment: Version 1.4.1-beta by Sun Microsystems Inc.
Logging to file: /javawsDTF.log
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.com.sun.
javaws)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
        at java.security.AccessController.checkPermission(AccessController.java:401)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
        at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1513)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:262)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        at com.sun.javaws.Launcher.continueLaunch(Launcher.java:573)
        at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:352)
        at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:177)
        at com.sun.javaws.Launcher.run(Launcher.java:145)
        at java.lang.Thread.run(Thread.java:536)
java.lang.SecurityException: Unable to create temporary file
        at java.io.File.checkAndCreate(File.java:1310)
        at java.io.File.createTempFile(File.java:1401)
        at com.sun.javaws.SplashGenerator.create(SplashScreen.java:338)
        at com.sun.javaws.SplashGenerator$1.finishedLoadingImage(SplashScreen.java:224)
        at com.sun.javaws.cache.CacheImageLoader$1.run(CacheImageLoader.java:71)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
Java Web Start 1.2-beta Console, started Fri May 24 16:22:57 PDT 2002
Java 2 Runtime Environment: Version 1.4.1-beta by Sun Microsystems Inc.
Logging to file: /javawsDTF.log
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.com.sun.
javaws)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
        at java.security.AccessController.checkPermission(AccessController.java:401)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
        at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1513)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:262)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        at com.sun.javaws.Launcher.continueLaunch(Launcher.java:573)
        at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:352)
        at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:177)
        at com.sun.javaws.Launcher.run(Launcher.java:145)
        at java.lang.Thread.run(Thread.java:536)

Bug exist on all jaws1.2 builds from 5-10.
If necessary I will investigate deeper.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08 VERIFIED IN: mantis-beta
31-08-2004

EVALUATION I cannot reproduce the problem using the procedure described. However the same stack trace can be reproduced if I start javaws with a extra slash "/" in front. We suspect this bug is the same instance as 4494155. ###@###.### 2002-05-28 There are 2 problems at work here: 1. The install script does not correctly construct the path to the javaws directory if javaws is installed in the root directory on Unix. In this case, it will think the path to the javaws script is //javaws/javaws, this is the path that is used when an app is started through the browser. Because of this, apps started through the browser encounter the problem in 2. 2. If a javaws app is invoked on Unix with an extra slash at the beginning of the path (e.g. "//javaws/javaws app.jnlp"), the javaws system code itself will not be assigned the correct permissions resulting in lots of AccessControlExceptions and a hung app. When javaws is invoked, the shell script takes the invocation command ("//javaws/javaws"), and passes it to the native code. The native code constructs a file URL from this, which points to the security policy file, and passes this to java code. (The policy file gives javaws system code all permissions). The extra slash causes the URL to be malformed and javaws system code ends up not being assigned all-permissions, causing the ACExceptions. I think we should fix both 1 and 2. 1 is easily fixed by special casing an install in the root directory in the install script. 2 is fixed by checking the invocation command in the install script for double slashes, and changing them to a single slash. ###@###.### 2002-05-29
29-05-2002

WORK AROUND Install in a directory other than the root directory. ###@###.### 2002-05-29
29-05-2002