JDK-4902922 : Fix for 4506751 causes failure of remote scripting application
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.1_04
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-08-07
  • Updated: 2003-08-12
  • Resolved: 2003-08-12
Related Reports
Duplicate :  
Description
Customer's application uses Microsoft's Remote Scripting (MSRS).  MSRS uses JavaScript on the client side to communicate with an applet (RSProxy.class, Microsoft's applet).  The applet is then used to invoke methods on a server-side ASP and send the server's response back to the client.  The issue is that the Sun JVM prevents their application from receiving Windows messages off the message queue.  They are trying to run a script that will bring up a new native window, but that window never appears.

The application works with the Microsoft JVM.  It also worked up to 1.3.1_02 and 1.4.0, but is broken from 1.3.1_03 and 1.4.0_01 onwards.  I believe this is related to the fix for bug 4506751.  This fix involved adding the WaitWithMessageLoop function to CDispatch.cpp, which calls PeekMessage with a NULL window handle.  In bug 4802147, the NULL handle was changed to the handle for the control window.  However, the problem still exists in 1.3.1_08.

The customer's code also contains a function which calls PeekMessage with a NULL window handle.  It appears that since the JVM retrieves the Windows messages off the queue, the customer's app just sits in an infinite loop waiting for a message which it never receives.  The customer's app is waiting for messages in their application's COM control which is inside a browser frame.  They don't believe this should be the same as the JVM's control window since the JVM is not used within this frame, but somehow the JVM seems to be interfering anyway.
 






Comments
WORK AROUND Use 1.3.1_02 or 1.4.0 (neither of which is supported), or the Microsoft JVM.
11-06-2004

SUGGESTED FIX The following suggested fix is for 1.3.1_10 if a fix is required for the 1.3.1_xx train: ------- CDispatch.cpp ------- *** /tmp/dW.ayLa Mon Aug 11 17:36:19 2003 --- CDispatch.cpp Thu Aug 7 16:35:55 2003 *************** *** 833,839 **** invokeData.pdispresult = pdispresult; invokeData.disp = this; HANDLE thread = CreateThread(NULL, 0, CDispatch::invokeMethodImpl, (LPVOID)&invokeData, 0, &tid); ! WaitWithMessageLoop(NULL, thread, INFINITE); return S_OK; } --- 833,839 ---- invokeData.pdispresult = pdispresult; invokeData.disp = this; HANDLE thread = CreateThread(NULL, 0, CDispatch::invokeMethodImpl, (LPVOID)&invokeData, 0, &tid); ! WaitWithMessageLoop(m_controlObject->getOuterWindow(), thread, INFINITE); return S_OK; }
11-06-2004

EVALUATION For 1.3.1_0x, the problem is because a NULL handle is being passed into the WaitWithMessageLoop function. A fix is to pass the handle to the control window to the WaitWithMessageLoop. See suggested fix for details. However, due to design changes in 1.4.1, the control window is being created in the jpiexp32.dll and the javascript to java method dispatching is being handled in the jpicom.dll. A 1.4.1 based fix will be more complicated and requires more investigations. ###@###.### 2003-08-11 The suggested fix may not work correctly with all scenarios for #4516042. The root cause of this and #4838960 is same. I am closing this as duplicate of #4838960 ###@###.### 2003-08-11
11-08-2003