Hi Lou,
I'm delighted that you got it working, and yeah, I've had similar problems with products installing 'private' versions of java that then mess other things up. Sometimes it can be really tricky tracking the problem down too - well done :-)
No, I hadn't heard of the Confluence wiki, but I'm delighted they're using JXplorer :-)!
cheers,
Chris On 27/05/2006, at 5:40 PM, LJP wrote: After I looked into it, your initial evaluation proved to be right - my java environnment was messed up. I think you might be interested how: As you're probably aware, your JXplorer is pretty much a requirement to get ldap working on a wiki called Confluence. They link to your site and strongly suggest that the customer use it - they want screenshots of what your software is doing in order to support customers trying to implement LDAP authentication. Anyhow, they've got a standalone version of their product, and I'm not sure if it's exclusive to this packaging, but when it's installed, it installs the java virtual machine as well. I install my own JDK as a matter of course on my Linux servers that will run Java. I didn't remember that Confluence installed its own JVM, and the thought of a mess-up between them didn't occur to me until late in the troubleshooting process. For some reason, probably in an attempt to ensure that my PATH environment variable was correct, I typed the simple command which java. It returned /usr/bin. I knew that my JDK was in /usr/java/. Uh-oh. Well, this product stuck a softlink in /usr/bin named java that pointed to an executable in /usr/lib. So I had this half-assed unknown java version out there that I was using and didn't even know it. When I deleted that softlink, both JXplorer and confluence suddenly used the JDK that I installed, and both programs were happy. Sorry about the long email, but I can see how other users of confluence might be similarly confused. Their troubleshooting, as yours does, suggests that one check the PATH variable by issuing the command java -version, but in a situation like mine, that wouldn't help. The expensive software I just installed had me fooled for awhile. I'll post this detail on the Confluence site, but I thought I'd let you know. BTW, your JXplorer is great. Thanks again, Lou Poulos
On 5/26/06, Chris Betts <[EMAIL PROTECTED]> wrote: Hi Lou, I'm glad you finally got it working! I'm afraid your java environment must have been messed up; the earlier version of JX are known to be o.k... maybe the linux java version you were using got muddled or something. Anyway, I'm glad it's sorted now - here's hoping the new Sun licencing system makes it easier for linux distros to include java now! cheers, On 27/05/2006, at 4:36 AM, LJP wrote: Chris,
I got it working. I uninstalled my JDK and installed the new 1.5 version, and the software works. Not really sure what the diff is, but I'm just glad it's working.
Thanks very much for your help!
Best regards,
Lou Poulos
On 5/26/06, Chris Betts <[EMAIL PROTECTED]> wrote: Hi Lou, I've stuck a new version up on sourceforge, so you can use that if you like. The problem was indeed that my build script was picking up java 1.5 instead of the older java 1.4 install it was supposed to. Now that I've learnt about the 'source' and 'target' compiler options, we shouldn't see this problem again! I'm having a little trouble with sourceforge and the new 'easy install' packages, but the basic deploy.zip/bz2 files seem to work fine. The install package issue may resolve once the sourceforge cache catches up! cheers, - Chris On 25/05/2006, at 11:02 PM, LJP wrote: Thanks for your reply.
I took as much care as I could getting my JVM in the path, and the shell can find it off the command line: <snip> [EMAIL PROTECTED] ~]# java -version java version "1.4.2_11 " Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06) Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode) <snip>
Yet the binary installation stil fails as follows: <snip> [EMAIL PROTECTED] tmp]# ./JXv3.1_install_linux.bin Preparing to install... Extracting the installation resources from the installer archive... Configuring the installer for this system's environment... awk: cmd. line:6: warning: escape sequence `\.' treated as plain `.'
Launching installer...
Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)
Stack Trace: java.lang.UnsatisfiedLinkError: /usr/java/j2sdk1.4.2_11/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load (Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) at java.lang.System.loadLibrary(System.java:834) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38) at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29) at java.awt.Component.<clinit>(Component.java:506) at com.zerog.ia.installer.LifeCycleManager.f (DashoA8113) at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113) at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113) at com.zerog.ia.installer.Main.main(DashoA8113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java :25) at java.lang.reflect.Method.invoke(Method.java:324) at com.zerog.lax.LAX.launch(DashoA8113) at com.zerog.lax.LAX.main(DashoA8113) This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX) <snip>
Even the zipped "deploy" package won't do a thing for me: <snip> [EMAIL PROTECTED] jxplorer]# ./jxplorer.sh console starting JXplorer...
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/ca/directory/jxplorer/JXplorer (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100 (URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java :187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
========================= JXplorer failed to start ========================= Please ensure that you have appropriate "xhost" access to the machine you are running this from. Make sure the DISPLAY environment variable is set correctly. Otherwise, ask your Unix Systems Administrator for more information on running X Windows applications.
If you require more information run "./jxplorer.sh console" and check the error produced. <snip>
Here's my Fedora Core 4 system info: <snip> [EMAIL PROTECTED] jxplorer]# uname -a Linux intraprodwiki1.tcu.ad.local 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux <snip>
Hopefully this will give you the necessary hints as to why I can't run this java application. Please let me know if I can provide any additional information.
Thanks again,
Lou Poulos
On 5/24/06, Chris Betts <[EMAIL PROTECTED] > wrote: Hi,
this normally means that it can't find it in the path (as opposed to looking for JAVA_HOME). Can you type 'java -version' and get a reasonable response from the command line?
If you can, then the installer is fritzed and you'll need to install manually from one of the 'deploy' packages from sourceforge, but I suspect it's actually your path that needs work. If it's not your path, write back and tell us what system you're using, and what the response to 'java -version' is :-)!
cheers,
Chris
On 24/05/2006, at 11:42 PM, LJP wrote:
> I've got an easy one for you! > > When I run the install binary, it complains that it can't find my JVM: > > Preparing to install... > Extracting the installation resources from the installer archive... > Configuring the installer for this system's environment... > No Java virtual machine could be found from your PATH > environment variable. You must install a VM prior to > running this program. > > Yet I've got the JDK installed and the path configured under the > variable JAVA_HOME: > > set | grep -i java > JAVA_HOME=/usr/java/jdk > > So what variable name is the install binary looking for when trying > to locate the JVM? > > Thanks! >
|