285591 - [extension/java/xpcom] classloader problems

Status: RESOLVED FIXED

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.3; Linux) KHTML/3.3.2 (like Gecko)
Build Identifier: 

I've a this code for listening to mouse events inside of the 
gecko widget 
 
org.swt.Browser gecko = ... 
long p = gecko.getnsIWebBrowserPointer(); 
nsIWebBrowser brow = 
  (nsIWebBrowser) 
  XPCOM.importInstance(p, nsIWebBrowser.NS_IWEBBROWSER_IID); 
nsIDOMWindow w1 = 
  (nsIDOMWindow) 
  brow.getContentDOMWindow().queryInterface(nsIDOMWindow.NS_IDOMWINDOW_IID); 
nsIDOMWindowInternal w2 =  
  (nsIDOMWindowInternal) 
  w1.queryInterface(nsIDOMWindowInternal.NS_IDOMWINDOWINTERNAL_IID); 
nsIDOMWindowInternal w3 = w2.getWindow(); 
nsIDOMEventTarget t = 
  (nsIDOMEventTarget)  
  w3.queryInterface(nsIDOMEventTarget.NS_IDOMEVENTTARGET_IID); 
this.h = new Handler(); 
t.addEventListener("mousemove", h, true); 
 
class Handler implements nsIDOMEventListener { 
  public nsISupports queryInterface(String iid) { 
    return XPCOM.queryInterface(this, iid); 
  } 
  public void handleEvent(nsISupports arg0) { 
    System.err.println("hura"); 
  } 
} 
 
the callback (handleEvent) is never called 

Reproducible: Always

Comment 1

[Michal Ceresna]

The whole code is running inside of Eclipse 
(in an editor plugin) 
 
the problem occurs in the nsJavaWrapper::CreateJavaProxy 
where it fails at the line: 
 
jclass ifaceClass = env->FindClass(class_name.get());  
 
while handling the method: 
---> (Java) nsIDOMEventListener::handleEvent() 
 
the variable class_name has value 
"org/mozilla/xpcom/nsIDOMEvent" 
 
Interestingly, the other classes were loaded successfully 
at the same line: 
org/mozilla/xpcom/nsIDOMJSWindow 
org/mozilla/xpcom/nsIDOMWindowInternal 
org/mozilla/xpcom/nsIDOMEventTarget 
 
 
I assume, the problem occurs, because there is no context classloader. 
The handleEvent is an async-callback from mozilla, therefore there is 
no context classloader associated. 
Because the editor code is started as an eclipse plugin,  
org.mozilla.xpcom.nsIDOMEvent it is not part of CLASSPATH and 
therefore, it is not visible by the fallback SystemClassLoader. 
 
Any hint how to fix this nicely? 
(E.g. In the worstcase, I could preload all the classes in 
InitializeJavaGlobals) 
 
 

Comment 2

[Michal Ceresna]

Attachment: proposed fix

I had to solve it somehow to proceed with my app,
this is the fix I've written.

Comment 3

[jhp (no longer active)]

Michal, two things:
1) Can you see if the callback is called on a different thread?  That is, can
you check (in native code) if the thread you are in when |t.addEventListener()|
is called is the same as when the callback function gets called through
|nsJavaXPTCStub|?

2) Does the following code help (with your patch removed)?
  +++ nsJavaXPCOMBindingUtils.cpp 2 May 2005 23:04:36 -0000
  @@ -95,4 +95,19 @@ PRLock* gJavaXPCOMLock = nsnull;
  
   /******************************
  + *  JNI Load & Unload
  + ******************************/
  +extern "C" JX_EXPORT jint JNICALL
  +JNI_OnLoad(JavaVM* vm, void* reserved)
  +{
  +  // Let the JVM know that we are using JDK 1.2 JNI features.
  +  return JNI_VERSION_1_2;
  +}
  +
  +extern "C" JX_EXPORT void JNICALL
  +JNI_OnUnload(JavaVM* vm, void* reserved)
  +{
  +}
  +
  +/******************************
    *  InitializeJavaGlobals
    ******************************/

Comment 4

[jhp (no longer active)]

Attachment: patch v2 (checked in)

Michal, try this one (again, without your changes).  I was incorrectly caching
the JNIEnv variable, and I think that may have caused your class loader issues.
 Let me know if this works.

Comment 5

[jhp (no longer active)]

Comment on attachment 182508 [details] [diff] [review]
patch v2 (checked in)

I checked this in, since it is the correct thing to do.  Just tell me if this
fixed your issue, Michal.

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[jhp (no longer active)]

Never got a response from Michal, so closing this out as FIXED.