55109 - Missing libliveconnect.so causes liveconnect pages to fail.

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[edburns]

Reproducible: always.

Install today's PR3 and JPI.

Visit
http://lonely.eng/Blackwood/src/OJI/PluginTest/sunw/LiveConnect/html/LCJavaToJS.html 

You'll see this console message:

**************************************************
nsNativeComponentLoader: GetFactory(libliveconnect.so) Load FAILED with
error: ld.so.1: ./mozilla-bin: fatal: libliveconnect.so: open failed: No
such file or directory
**************************************************

This happens when GetFactory is called with:

debug: joechou:
GetFactory(lib:libliveconnect.so,application/x-mozilla-native)

Comment 1

[edburns]

On windows, this file is jsj3250.dll.  This library is built from sources in 
js/src/liveconnect.

For some reason, on unix, the call to GetFactory is looking for 
libliveconnect.so.

Comment 2

[edburns]

I don't know how this got resolved fixed.

Comment 3

[edburns]

The call to nsNativeComponentLoader::GetFactory() with jsj3250.dll originates 
in jpins32.dll.  I think it originates in CPluginServiceProvider::QueryService
():

NS_METHOD
CPluginServiceProvider::QueryService(/*[in]*/  const nsCID& clsid, 
				     /*[in]*/  const nsIID& iid,
				     /*[out]*/ nsISupports* *result) 
{
//...
    if (mService != NULL)
    {
	// We are running inside Mozilla and have nsIServiceManager
	err = mService->GetService(clsid, iid, result, NULL);
    }
//...
}
the clsid is b8f0cef0-3931-11d2-97f0-00805f8a28d0, which is the clsid for 
nsILiveconnect, found in mozilla/js/src/liveconnect/nsILiveconnect.h.

I need to know if the same clsid is used in the java plugin on both windows and 
solaris.

Ed

Comment 4

[edburns]

Added CC.

Comment 5

[edburns]

Added rogerl.

Comment 6

[edburns]

It looks like both the win32 and unix Sun Java Plugin Implementations use 
NS_CLIVECONNECT_CID from nsILiveconnect.h.  THIS MEANS THE PROBLEM IS IN 
MOZILLA.  At this point NO CODE CHANGE seems NECESSARY in Sun's Java Plugin.   
Somehow NS_CLIVECONNECT_CID is getting turned into libliveconnect.so on unix 
and jsj3250.dll on win32.

Comment 7

[edburns]

A HA!  The reason the code is looking for libliveconnect.so on unix and 
jsj3250.dll on win32 is here:

http://lxr.mozilla.org/mozilla/source/webshell/tests/viewer/nsSetupRegistry.cpp#
84

So, to solve this bug, we need to do two things:

1. Find out what the "right way" to build liveconnect for mozilla on unix is.

2. perhaps modify the above file so the right library is loaded.

I'm posting a modified nsComponentManager.cpp for Joe Chou to look at to see 
how I discovered the above information.  It's a good debugging tip.  Joe, diff 
this file with the tree to see what I did.

Ed

Comment 8

[edburns]

Attachment: Modified mozilla/xpcom/components/nsComponentManager.cpp to help me figure out what the hell was going on.

Comment 9

[edburns]

It looks like the necessary symbols are in libjsj.so on unix.  This seems to be 
the same as jsj3250.dll on win32.  I've compared dumpbin and nm output like 
this:


mozilla\dist\WIN32_D.OBJ\bin>dumpbin -exports jsj*.dll | grep JSObject
         22   17 00001113 _Java_netscape_javascript_JSObject_call@16
         23   18 0000103C _Java_netscape_javascript_JSObject_equals@12
         24   19 00001244 _Java_netscape_javascript_JSObject_eval@12
         25   1A 000012DA _Java_netscape_javascript_JSObject_finalize@8
         26   1B 00001212 _Java_netscape_javascript_JSObject_getMember@12
         27   1C 0000109B _Java_netscape_javascript_JSObject_getSlot@12
         28   1D 0000117C _Java_netscape_javascript_JSObject_getWindow@12
         29   1E 0000105F _Java_netscape_javascript_JSObject_initClass@8
         30   1F 000010B4 _Java_netscape_javascript_JSObject_removeMember@12
         31   20 000012CB _Java_netscape_javascript_JSObject_setMember@16
         32   21 000011E0 _Java_netscape_javascript_JSObject_setSlot@16
         33   22 00001037 _Java_netscape_javascript_JSObject_toString@8

arago 65 %nm libjsj.so | grep JSObject
00022adc T FinalizeJSObject__14nsCLiveconnectP7JNIEnv_l
0000e98c T Java_netscape_javascript_JSObject_call
0000f414 T Java_netscape_javascript_JSObject_equals
0000ed64 T Java_netscape_javascript_JSObject_eval
0000f2fc T Java_netscape_javascript_JSObject_finalize
0000e244 T Java_netscape_javascript_JSObject_getMember
0000e458 T Java_netscape_javascript_JSObject_getSlot
0000f154 T Java_netscape_javascript_JSObject_getWindow
0000e228 T Java_netscape_javascript_JSObject_initClass
0000e800 T Java_netscape_javascript_JSObject_removeMember
0000e578 T Java_netscape_javascript_JSObject_setMember
0000e740 T Java_netscape_javascript_JSObject_setSlot
0000f02c T Java_netscape_javascript_JSObject_toString
00016e9c t convert_js_obj_to_JSObject_wrapper
0000cdb0 T jsj_UnwrapJSObjectWrapper
0000cc80 T jsj_WrapJSObject
00038c30 B njJSObject
00038c0c B njJSObject_JSObject
00038c08 B njJSObject_internal
00038c60 B njJSObject_long_internal

The only question is: why is it jsj.so on unix and jsj3250.dll on win32?  Why 
no version number on unix?

I just talked to Roger Lawrence on the phone about this.  He recommend trying 
it without renaming the .so on unix.

Comment 10

[edburns]

Attachment: cvs diff -u of fix for this bug, first iteration.

Comment 11

[edburns]

I have tested this on Solaris and it works!  I need approval.

Comment 12

[Phil Peterson]

Marking [rtm need info] until code reviews are done

Comment 13

[rogerl (gone)]

r=rogerl

Comment 14

[Brendan Eich [:brendan]]

a=[e-mail].

/be

Comment 15

[edburns]

Per Phil Peterson's recommendation, marking rtm+ after securing r=rogerl and 
a=brendan.

Comment 16

[Phil Peterson]

PDT marking [rtm++]

Comment 17

[edburns]

Fix checked in to branch and trunk.

Comment 18

[shrirang khanzode]

I am rubberstamping this as verified since i do not have access to the test url 
posted here and also no solaris environment. VERIFIED.