Closed Bug 61049 Opened 24 years ago Closed 24 years ago

Java 2 Plugin "successful" but doesn't take

Categories

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

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 62324

People

(Reporter: shochat, Assigned: xiaobin.lu)

References

(
URL
)

Details

Attachments

(2 files)

Try this - it worked for me, though it's brute force
1.20 KB, text/plain
Details
On RedHat 6.1, try linking to /usr/X11R6/lib/libXt.so.6 as libXt.so
542 bytes, text/plain
Details
This supersedes 60685. The behavior I reported there is gone since building from CVS as of 11/22/2000 10:32:14 PST. Now when visiting java.sun.com the following occurs: 1. Get the dialog saying I need the plugin. Ok. 2. Get a page with 2 options (Windows and Linux). Choose Linux 3. Get a page proposing the FTP download from ftp.netscape.com. Ok. 4. The download proceeds without any apparent error. 5. The install phase proceeds without any apparent error. 6. A page appears bearing good news: "Java 2 Plug-in for Linux: Successful" 7. Returning to java.sun.com (even after restarting Mozilla), brings back the original dialog of step 1. Furthermore, the demo applets don't work. The java2 directory appears to have been built successfully in mozilla/dist/bin/plugins, but something is obviously still broken.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug appears to be semi-fixed in the just-released mozilla 0.6. Using this (Linux), I attempted to install the jre using the link on the Release Notes page for 0.6. This brings up the page from step #2 above. Steps #3, #4, and most of #5 are as before. But instead of completing successfully, it ends with mozilla 0.6 crashing. However, after restarting, Java applets work! This is with a binary (CVS is currently dead).
OS needs to be changed to "ALL", I don't have permission. I can not install the Java Plugin with WinNT 4.0sp5 and 0.6. I have also been trying to get the Java plugin to work with almost every daily build for the last 3 months on both RH7 Linux and NT with no luck. This is not a proxy/firewall problem as I have tried both behind and in front of our proxy/firewall. Also, even if this worked, the userinterface for installing the plug-in is horid. It launches 3 windows which do nothing but sit there.
I just got it working... Download the jre.xpi file from ftp.netscape.com, run mozilla as root (eek). Here the dialog disappeared but the throbber didn't finish, indicating that part of the installation somehow didn't complete. I closed mozilla, and chmod -R o+w /usr/local/mozilla (bad), re-ran mozilla and went to two urls: http://news.bbc.co.uk/ has a news ticker immediately above the top headline. That does not start. http://java.sun.com/ has a ticker on the top right. That does start and work. I think this is a problem which affects people in different ways caused by a number of issues such as the permissions of the target installation directory files and also the fact that there may be problems with the html code used to call the Java applets on certain pages (perhaps Mozilla has bugs in this respect too). It really needs someone with knowledge of how all this stuff works to tell us exactly what permissions on the files are needed (PSM for example needs write permissions), and to identify sites such as http://news.bbc.co.uk/ don't work when others don't. In the meantime I'm marking this bug OS->All per Greg's comments (could easily be a Linux-specific problem though), and can confirm that this is not a proxy/firewall dependant problem. I have seen another bug which is also ambiguous as to the exact fault, but shares the general problem of Java not installing correctly or not working properly.
OS: Linux → All
I just tried again (using a build from CVS with CO date 2000-12-08 17:02:21) and it STILL fails. Which is to say that it says it has succeeded but then when you try to view a page that contains an applet, you get the original dialog again. The test that I'm currently using is to go to the Mozilla Debug menu and select Debug->Verification->Applets [with succeeds on Mozilla 0.6 after installing the jre]. NOTE: I am doing the entire test as root, so there can be no issue of permission problems, right? Only after I finally succeed doing it as root will I attempt running an applet as a normal user. I should also point out that for mozilla 0.6 (for which the jre installation process did work if you ignore the final crashing), there was no need to modify any permissions to get it to work for a normal user. James Green wrote: > Download the jre.xpi file from ftp.netscape.com Can you please supply complete details (such as the full URL and what to do with the file once you've downloaded it, and any final configuration actions that must be taken)? I have tried two methods: 1. Just click ok when you get the initial dialog and follow through as I documented originally. 2. Use the java link on the Mozilla 0.6 Release Notes page (which may not really be any different from method 1). The result is always the same: It says it has succeeded, but then when you come back and try it out, it acts as if you had not installed the jre at all! Again, I'm doing the entire test as root.
There seem to be many bugs related to this problem or blocking this bug. Bug: 48336 - Java proxy settings not picked up from mozilla. Bug: 60213 - Installing Java Plugin hangs Linux Bug: 55757 - Dll's installed to incorrect place on Windows.
The plugins file name have changed. They are called: NPJava130_01.dll NPjava130_01a.dll NPJava130_01b.dll NPJava130_01c.dll they used to be called: NPJava11.dll NPJava12.dll NPJAva32.dll
I confirm this on a standard Linux Mandrake 7.1, on the Dec 25 08:24 binary build and on mozilla 0.6. After I install jre.xpi I get the original dialog again when visiting a page with an applet.
attachment 12 [details] [diff] [review]/30/00 06:21 - did not work for me. I'm using rh7 Linux only on 2 686 and 2 586. The i686 work with java and shockwave, but the i586 do not.
The solution Christiano posted worked for me. In addition to copying libXt.so.6 to the place where I installed mozilla, I also had to rename it to libXt.so. After this on startup mozilla registers the plugins that where aready installed but did not work. I also did an strace and apperently it can't find this lib. Thank you very much Christiano
This bug appears to be fixed in 0.7. This time there was no crash at the end of the install, and after restarting, the JRE worked fine. This is the Linux version.
The JRE plugin didn't work for me "out of the box" (build 2001012806, on Linux RedHat 6.1). I didn't try Cristiano's suggestion. However, what I did try was to make a symbolic link from within mozilla/plugins to plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so, and that seemed to do the trick; I guess there needs to be a plugin .so/.dll right in the plugins directory/folder, not just any old place in that subtree. I guess that either the XPI file that JRE is delivered has to be changed, or Mozilla should be changed so that it recursively searched all subdirs of plugins looking for plugin dynamic libraries.
Seems partially fixed - for some systems. Using 0.7 on RH6.2, the std install seems to work (navigate from Release notes to the netscape download page and select the Linux option). Still does not work with Mandrake 6 or Mandrake 7. Have also tried manually creating a symlink in plugins to plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so without success. Have not tried Christianos suggestion yet, but will - however, other plugins (DjVu for instance) are registering properly when Mozilla (or Netscape6) starts.
Thanks to Cristiano & Johan This seems to be the solution for at least some distributions. I created a symlink in my mozilla directory (ln -s /usr/X11R6/lib/libXt.s0.6.0 libXt.so) and Java now works (Mandrake6). I haven't tried N6, cos I plan to deinstall it and stick to mozilla.
I see a regression in 0.8. As I reported above, the install worked (but with a crash) in 0.6 and worked flawlessly in 0.7 but now it is broken again. The behavior I got when I tried to install the jre to 0.8 was exactly as I described originally on 2000-11-22 (that was with a CVS version). This is the linux binary tar version.
Keywords: mozilla1.0
Nominating for mozilla1.0, since Mozilla really needs to be able to Java without a hitch.
I tried Doug's suggestions and now Build 2001021503 works perfect in my RH7 box. Thanks, Doug
Doug's suggestion to create the symlink for libjavaplugin_oji.so *worked* for the binary 0.8 version. For 0.7, the corresponding symlink had been created automatically during the install. However, doing this does not work for the CVS version, even though the two libjavaplugin_oji.so's are identical. When mozilla (CVS version) is starting up, I see this: Registering plugin 0 for: "*","All types",".*" IsPluginFile(/usr/local/mozilla/mozilla/dist/bin/plugins/java2) LoadPlugin() /usr/local/mozilla/mozilla/dist/bin/plugins/java2 returned 0 IsPluginFile(/usr/local/mozilla/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so) LoadPlugin() /usr/local/mozilla/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so returned 0 I think that means it found something wrong with the plugin. Even though the same one works on the binary 0.8 version!
I'll add my newsgroup posting from 18/02, with the remark that all proposed solutions don't work for me. .... Folks, Just downloaded and compiled Moz 0.8. I tried installing the java plugin, but it still is not working allright. Here's what I did: 1. Compiled Moz0.8 from source using the following options "'./configure --with-x --with-gtk --disable-debug --enable-optimize=-O2 --disable-mailnews" 2. Downloaded jre.xpi from ftp.netscape.com. Used the file from the NS6.01 directory. 3. Copied jre.xpi to /usr/local/share/mozilla/bin/plugins (my install directory) 4. Opened Mozilla as root, went to above directory. Moz installed plugin, then showed me a busy icon (that little wristwatch) 5. Closed and restarted. Went to Debug->Applets, and was greeted with the download dialog again. 6. Somebody told me as answer to an earlier query to create a symlink to the plugin in the plugins directory. Did that, still no Java support. Here's a listing of my plugins directory: drwxr-xr-x 6 root root 4096 Feb 17 19:33 java2 -rw-r--r-- 1 mvdwege mvdwege 15514743 Feb 7 16:15 jre.xpi lrwxrwxrwx 1 root root 44 Feb 17 19:37 libjavaplugin_oji.so -> java2/plugin/i386/ns600/libjavaplugin_oji.so -rwxr-xr-x 1 root staff 19288 Feb 17 18:56 libnullplugin.so ..... My system info: Distribution: Debian GNU/Linux Operating System: Linux Distribution Version: testing/ Operating System Version: #8 Sun Feb 4 14:38:47 CET 2001 Operating System Release: 2.2.18 Processor Type: i686 Mart
I have made further investigation of this. In (today's) CVS build, when a call to dlopen() is made for libjavaplugin_oji.so at line 740 of prlink.c (in prLoadLibraryByPathname() ), this call fails. Calling dlerror() inside gdb at this point indicates that the problem is an undefined symbol: _._13nsCOMPtr_base I searched all .so files in the tree and indeed none of them define this symbol. The question is, why does it load successfully in the 0.8 binary build.
Redhat 6.2 with all errata updates. mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; 0.9) Gecko/2001022 jre.xpi install created symlink fine but still not registered as plugin unpon restart the manual addition of the ibXt.so -> /usr/X11R6/lib/libXt.so.6 symlink fized the probelm.java in mozilla yeah! BTW the installation in 0.8talkback binary did not work either. It did mot even create the libjavaplugin_oji.so symlink.
Ok I am still fooling around with this. This time I downgraded to 0.7, both because Galeon currently does not play nice with 0.8, and because some proposed solutions were suggested with 0.7. I offer the following observations: 1. Creating the link (or copying the library in my case) to libXt.so.6 appears to help. However visiting a javadependent page leaves me with a blank grey area on the page. Using Debug->Verification->applets gives me a crash with the following error: "Error: Object "drawingArea" does not have windowed ancestor". 2. After clearing out my plugins and .mozilla directories, and removing the libXt.so copy, I tried reinstalling, and got the following error: "Error loading URL file:///home/mvdwege/jre.xpi: 804b0002" (this was while running as root). I do not have the programming experience yet to do a full debug on this, but I hope these observations help shedding a little light. (Oh BTW, does running XFree86 4.02 make a difference?) Mart
Confirmed Java still broken in the 20010223 nightlies for both Windows and Linux. I do not want to critize and I know the developers are very busy, but this is absurd. Except for initial load time and broken Java, Mozilla is actually better than IE5.5sp1. I am also following the improvements in load time and it will eventually come around. However, I do not think this bug will ever get fixed. I have been followling the bug for almost 3 months now and neither the assigned QA contact nor the developer has even said one word about it. I would think this would be dogfood++, Most requested, etc. bug. Am I wrong? I don't want to be an ass and reasign the priority, but shouldn't this bug be P1? Why the M1.0 keyword? Java can cause lots of problems so it should be fixed so we can test each build and make sure it does not cause blocking situations. I can just see it now. This bug gets fixed about a month before Mozila1.0 is released and once a lot of people start using the Java plugin, it cause about 1000 bugs.
Assignee: dveditz → edburns
Component: Installer: XPInstall Engine → OJI
QA Contact: jimmylee → shrir
Not an install engine problem since the JRE contains its own installer
This continues my comments of 2/17 and 2/24. The answer to my last question is that the symbol _._13nsCOMPtr_base *is* defined in the particular version of libxpcom.so that is contained in the 0.8 binary build (I had to use readelf to see this). But this symbol *is not* defined in the libxpcom.so that I get when building from CVS (using all default compile options). So either there has been a change to one of the source files that goes into this lib or there is some other difference (build options?) in how it was built for 0.8 binary. Also, libjavaplugin_oji.so is being loaded with the RTLD_LAZY flag which is supposed to mean that no attempt is made to resolve symbols until execution time. So maybe this means it is during the _init call (in libjavaplugin_oji.so) that the failure is occurring? One more thing: By doing nm libjavaplugin_oji.so with and without --demangle, it looks like our problem symbol (demangled) is in fact: nsCOMPtr_base::~nsCOMPtr_base(void) [class destructor]. The plot thickens: In the class definition, the destructor is surrounded like so:#ifdef NSCAP_FEATURE_FACTOR_DESTRUCTOR NS_EXPORT ~nsCOMPtr_base(); #endif So maybe the key is simply to compile with that set?
Please make sure you don't mix a debug build of mozilla (remember, debug is the default unless you configure --disable-debug) with a non-debug build of the java plugin (which you can't get unless you're a liscensee). Such a mix will surely result in much wailing and gnashing of teeth.
Well, I have never seen it stated anywhere that the Java plugin (or any other key Mozilla functionality, for that matter) is supposed to be broken by a doing a debug build. Anyway, it works now! By unmasking the nsCOMPtr_base destructor (in both the header and .cpp file), the problem has been solved. I now have Java working for the first time (other than with a binary build). I don't see why a debug version of the java plugin would no longer require that destructor. Why should it only need to call the destructor in a non-debug environment?
This was supposedly fixed in bug 68039, but apprently not totally. I also still get questions on IRC about this bug (though I can't tell for sure whether they're using 0.8 or a nightly). Also now we only get this problem on Linux. Even though someone here commented that it's broken on windows, I suspect it's really another bug. For all the IRC requests, I propose the symlink workaround, and it always works on linux. I never get any windows/mac problem with java install. CC'ing sgehani@netscape.com who fixed bug 68039.
If a build that does not contain the fix for bug 68356 is used to XPInstall/ update jre.xpi from the browser itself, then the symlink won't be created. The fix is to use a newer build of mozilla to instyall the jre.xpi. The regression occured sometime during mozilla0.8 development and got fixed after mozilla0.8, IIRC. So the symlink problem should not be an issue for released builds other than mozilla0.8. Please enumerate specific questions and scenarios if users are still having trouble that you feel is unrelated to the above explanation. Thanks.
Using 0.8 on Debian 2.2, the "symlink trick" worked for me: $ cd /usr/local/mozilla/plugins/ $ ln -s /usr/local/mozilla/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so libjavaplugin_oji.so
*** Bug 70856 has been marked as a duplicate of this bug. ***
Xiaobin, can you please investigate?
Assignee: edburns → xiaobin.lu
I am actually crashing while inside the "Downloading..." dialog using today's bild on linux, changing severity to critical.
Severity: normal → critical
stack: Call Stack: (Signature = nsXPInstallManager::OnProgress() 29d9dca5) nsXPInstallManager::OnProgress() XPTC_InvokeByIndex() EventHandler() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4056852a) libglib-1.2.so.0 + 0xfbe6 (0x40569be6) libglib-1.2.so.0 + 0x101a1 (0x4056a1a1) libglib-1.2.so.0 + 0x10341 (0x4056a341) libgtk-1.2.so.0 + 0x8c209 (0x40494209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x4023f1eb)
Shrirang, Please file a separate bug against the "Installer: XPInstall Engine" component (leave default owner please) with the stack trace you have pasted above. I believe that the issue you have cited is separate from the one being addressed by this bug. Thanks.
thx, filed 71119
*** Bug 71161 has been marked as a duplicate of this bug. ***
*** Bug 69183 has been marked as a duplicate of this bug. ***
Ok, I think on Linux (Debian 2.2 sid-unstable) this could be an issue with the c++ library. Trying to install the 0.8 binary, I got an error about libstdc++-libc6.1.so not being available. I downloaded the library (it's in Debians oldlibs section), and all of a sudden Java works (still using Moz0.7 though, as it plays nicer with my current build of Galeon). Mart
*** Bug 71804 has been marked as a duplicate of this bug. ***
*** Bug 69266 has been marked as a duplicate of this bug. ***
*** Bug 70247 has been marked as a duplicate of this bug. ***
Attempted the 'ln -s java2/plugin/i386/ns600/libjavaplugin_oji.so libjavaplugin_oji.so' hack with build 2001031812 [ latest nightly, as of this time ] on RH 6.1 intel. Result: 'Registering plugin' messages for java mime types start appearing, but, after the line Registering plugin 20 for: "application/x-java-bean;jpi-version=1.3.0_01","Java(tm) Plug-in","" I get the wonderfully informative: INTERNAL ERROR on Browser End: Could not read initial ack over the new fd System error?:: Resource temporarily unavailable and the process crashes. I remove the symlink, Mozilla starts fine. I'll attach the stack trace. I agree with [2001-02-25 13:47] that the current situation is absurd. The bug is underprioritized, it has not accepted, the responsilble party has said nothing.... How does one interpret this?
*** This bug has been marked as a duplicate of 62324 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: