JDK-6678349 : Regression: speed-trap.com dashboard doesn't load
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-21
  • Updated: 2010-09-08
  • Resolved: 2008-04-22
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.
JDK 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-6668033 - New plugin applet freezes the browser occasionally
Relates :  
JDK-6676489 - Java/JavaScript string handling changes break ESPRE Solutions videos in IE with new plug-in
Description
During regression testing of the fix for 6676489, it was discovered that the speed-trap.com dashboard was broken with the fix for 6668033, in which a level of indirection was added to the JnlpLookupStub to delegate through the current JNLP class loader / JNLPClassLoaderIf. It turns out the speed-trap applet tries to call into the JNLP services and expects either that ClassNotFoundException will be thrown, or that a query to fetch a given service will return null. Throwing SecurityException breaks their applet. Currently the following NullPointerException is thrown, which also breaks their applet:

java.lang.NullPointerException
	at com.sun.jnlp.JnlpLookupStub.findService(JnlpLookupStub.java:45)
	at com.sun.jnlp.JnlpLookupStub.access$000(JnlpLookupStub.java:18)
	at com.sun.jnlp.JnlpLookupStub$1.run(JnlpLookupStub.java:25)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.jnlp.JnlpLookupStub.lookup(JnlpLookupStub.java:22)
	at javax.jnlp.ServiceManager.lookup(ServiceManager.java:42)
	at com.speed_trap.applet.JNLPBridgeImpl.getJNLPCodeBase(Unknown Source)
	at com.speed_trap.data.olap.CodeBaseCategoryResourceProvider.getInstance(Unknown Source)
	at com.speed_trap.dashboard.DataAccessorApplet.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:2582)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1189)
	at java.lang.Thread.run(Thread.java:619)

We need to fail more gracefully. The best solution appears to be to simply return null from the JnlpLookupStub if there's no current JNLPClassLoaderIf.
Yes, the JNLP lookup shall just return NULL, 
if the service is not available - due to the spec.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6678349.0
21-03-2008
EVALUATION The speed-trap.com applet attempts to call into the JNLP services and expects either that ClassNotFoundException will be thrown, or that a query to fetch a given service will return null. The fix for 6668033, in which a level of indirection was added to the JnlpLookupStub to delegate through the current JNLP class loader / JNLPClassLoaderIf, causes a NullPointerException to be thrown which causes the speed-trap dashboard to break. Fixed the JnlpLookupStub to fail more gracefully. Tested manually with the speed-trap.com dashboard in IE. No other test case feasible at this time due to time constraints.
21-03-2008
EVALUATION Let JNLP lookup return null, even though JNLP is not initialized.
21-03-2008