Hello,

I wanna install the trial version of the workbench and get the yearly sunscription (99 % sure).

But I cannot run the installer without an exception (cannot find javax.swing.JDialog class !!!).

I do not know what is wrong with my installation. I run Eclipse 2.1 with no problem, create classes and so on, view applets etc. I also run JBoss 3.0 with no pb.

I have installed on my platform JRE 1.4.2, J2SE SDK 1.4.2 and J2EE SDK 1.3.1. Here are my environnement variables related to java :

Below are described my environnement variables and the trace of the exception.

Please let me know what are the env. variables required.

Thanks in advance for any tip.

Fred


# Java JRE
PATH=/usr/java/j2re1.4.2/bin:$PATH

#Java SE SDK
export JAVA_HOME=/usr/java/j2sdk1.4.2
PATH=/usr/java/j2sdk1.4.2/bin:$PATH

# Java EE SDK
export J2EE_HOME=/usr/java/j2sdkee1.3.1
PATH=/usr/java/j2sdkee1.3.1/bin:$PATH

# Eclipse
export ECLIPSE_HOME=/opt/eclipse
export PATH=$PATH:/opt/eclipse

# Ant
export ANT_HOME=/opt/ant
PATH=/opt/ant/bin:$PATH

# JBoss
export JBOSS_HOME=/opt/jboss
export JBOSS_DIST=/opt/jboss
PATH=$PATH:/opt/jboss/bin

# Tomcat
export TOMCAT_HOME=/opt/jboss/tomcat-4.1.x
PATH=$PATH:$TOMCAT_HOME/bin

# CLASSPATH
export CLASSPATH=.:/opt/ant/lib:/opt/junit:/opt/xdoclet/lib:/opt/jboss/lib:/opt/jboss/client:/opt/jboss/tomcat-4.1.x/common/lib



[root@localhost workbench]# ./EnterpriseWorkbenchInstaller_020501.bin
Preparing to install...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

Warning: -Xmx50331648 not understood. Ignoring.
Warning: -Xms16777216 not understood. Ignoring.
Exception in thread "main" java.lang.InternalError: Unexpected exception while defining class ZeroGs: java.lang.ClassNotFoundException: javax.swing.JDialog
at 0x4028115f: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x4027408e: java.lang.Error.Error(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40281542: java.lang.VirtualMachineError.VirtualMachineError(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40275a92: java.lang.InternalError.InternalError(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40272ff2: java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) (/usr/lib/libgcj.so.3)
at 0x40272dbb: java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int) (/usr/lib/libgcj.so.3)
at 0x4030b29b: java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x402606d7: gnu.gcj.runtime.VMClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40272cac: java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.3)
at 0x40260dcc: _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x4025d1fd: java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x40253809: _Jv_BytecodeVerifier.verify_instructions_0() (/usr/lib/libgcj.so.3)
at 0x40249697: _Jv_VerifyMethod(_Jv_InterpMethod) (/usr/lib/libgcj.so.3)
at 0x40241a24: _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x40260568: java.lang.ClassLoader.linkClass0(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x40273073: java.lang.ClassLoader.resolveClass0(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x4025e99c: java.lang.Class.initializeClass() (/usr/lib/libgcj.so.3)
at 0x4025d224: java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x4025d2bf: java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x402c60a0: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.3)
at 0x40267fdc: _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.3)
at 0x4023478c: _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/usr/lib/libgcj.so.3)
at 0x08048900: __gcj_personality_v0 (java.compiler=NONE)
at 0x420158d4: __libc_start_main (java.compiler=NONE)
at 0x080486c1: _Jv_RegisterClasses (java.compiler=NONE)

Well, this looks like a straightforward "can't find your JDK" problem. Here's what I'd check:
When you run 'java -version' what to you get?
On the classpath, explicity add /usr/java/j2sdk1.4.2/jre/rt.jar to the front of it.
Echo the environment to make sure the change was accepted and run the installer again.

If none of that works, it may be a new issue with the installer and JDK 1.4.2 on Linux. We test against RedHat 9 / JDK 1.4.1. Which version of Linux are you on? I recall a post regarding Suse Linux that ended with the user needing to install a new set of patches, but you'll have to search for that post.

Please let us know what you determine.

--Scott
MyEclipse Support

My Java version is 1.4.2. See below.

My Linux is RH 8.0, kernel 2.4.18.

For you info, I started all JFC samples with no pb (with instructions like 'java -jar sample.jar').

I updated my CLASSPATH env. variable as advised and the same problem still happens ((note that the path to the rt.jar is /usr/java/j2sdk1.4.2/jre/lib/rt.jar). See below.

Is the commercial version installed the same way ? If you garantee a (modified) commercial version works for RH 8.0, I guess I have to buy it.

Best regards,

Fred



[fredd@localhost fredd]$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)



[fredd@localhost workbench]$ echo $CLASSPATH
.:/opt/ant/lib:/opt/junit:/opt/xdoclet/lib:/opt/jboss/lib:/opt/jboss/client:/opt/jboss/tomcat-4.1.x/common/lib:/usr/java/j2sdk1.4.2/jre/lib/rt.jar
[fredd@localhost workbench]$ ls
EnterpriseWorkbenchInstaller_020501.bin
[fredd@localhost workbench]$ ./EnterpriseWorkbenchInstaller_020501.bin
Preparing to install...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

Warning: -Xmx50331648 not understood. Ignoring.
Warning: -Xms16777216 not understood. Ignoring.
Exception in thread "main" java.lang.InternalError: Unexpected exception while defining class ZeroGs: java.lang.ClassNotFoundException: javax.swing.JDialog
at 0x4028115f: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x4027408e: java.lang.Error.Error(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40281542: java.lang.VirtualMachineError.VirtualMachineError(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40275a92: java.lang.InternalError.InternalError(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40272ff2: java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) (/usr/lib/libgcj.so.3)
at 0x40272dbb: java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int) (/usr/lib/libgcj.so.3)
at 0x4030b29b: java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x402606d7: gnu.gcj.runtime.VMClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x40272cac: java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.3)
at 0x40260dcc: _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x4025d1fd: java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x40253809: _Jv_BytecodeVerifier.verify_instructions_0() (/usr/lib/libgcj.so.3)
at 0x40249697: _Jv_VerifyMethod(_Jv_InterpMethod) (/usr/lib/libgcj.so.3)
at 0x40241a24: _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x40260568: java.lang.ClassLoader.linkClass0(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x40273073: java.lang.ClassLoader.resolveClass0(java.lang.Class) (/usr/lib/libgcj.so.3)
at 0x4025e99c: java.lang.Class.initializeClass() (/usr/lib/libgcj.so.3)
at 0x4025d224: java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
at 0x4025d2bf: java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.3)
at 0x402c60a0: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.3)
at 0x40267fdc: _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.3)
at 0x4023478c: _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/usr/lib/libgcj.so.3)
at 0x08048900: __gcj_personality_v0 (java.compiler=NONE)
at 0x420158d4: __libc_start_main (java.compiler=NONE)
at 0x080486c1: _Jv_RegisterClasses (java.compiler=NONE)

Fred,

I'll post this to ZeroG's forums for InstallAnywhere support and see if this is a known issue on RH 8.0 or if there is a known workaround. I'll post followups to this thread.

--Scott
MyEclipse Support

Here's what ZeroG had to say about the issue:

Quote:

This appears to be a Java related issue as the exceptions thrown refer to Java classes. I would recommend re-installing Java 1.4.2 on this system, or bundling a VM with your installer.

Not overly helpful, but reinstalling Java would most likely correct it.

--Scott
MyEclipse Support

Actually I'm having the same problem (with RH9 and jdk.1.4.2) and its not related to a bogarted JVM. Look closely at the stack trace. For some reason the InstallAnywhere installer is finding /usr/bin/java (which is gcj and not the JDK) even though the Sun JDK is before it in the path. Since you support RH9 and 1.4.1 I may install 1.4.1 and try it but I suspect there's really a problem here with RH9 and 1.4.2 (possibly it doesn't like something about 1.4.2 during the search for a JVM).

Mike

Mike,

Thank you for this bit of insight. If you set the environment variable LAX_DEBUG=true and run the installer it should show you exactly how it is selecting the VM it uses. In Fred's case, /usr/bin/java was ahead of JDK 1.4.2 on the path, so this is most likely the cause of his installation problem. Could you try running with debug on your system and see what the output looks like?

--Scott
MyEclipse Support

I sent you a trace. Looks like they're sorting the path before they do the search for a VM!

Mike

I followed up with ZeroG and here's a document they sent me on how they select the VM to use. You'll see that they actually SORT THE PATH before they traverse it. Truly bizarre. They say there's already an open enhancement to adjust this. The doc below has workarounds for installs that are picking up the wrong VM, like reported by Fred and Mike.

Quote:

LaunchAnywhere VM selection This document describes how a LaunchAnywhere launcher created by an InstallAnywhere installer searches for and chooses a vm to run against. It outlines how it works, current shortcomings, and Zero G Software’s recommendations. VM Selection Windows I. Search a. Registry Search (in ascending order) i. JDK (1.1.'s then 1.2's etc) HKLM\SOFTWARE\JavaSoft\Java Development Kit\ ii. Java Plugin vm's (1.1.'s then 1.2's etc) HKLM\SOFTWARE\JavaSoft\Java Plug-in\ iii. JRE vm's (1.1.'s then 1.2's etc) HKLM\SOFTWARE\JavaSoft\Java Runtime Environment\ b. PATH Environment Variable Search i. Looks for jre, javasoft, or java folders II. Order a. Entries found both in path and registry b. Entries found only in the path c. Entries found only in the registry III. Choose a. Uses value listed in lax.nl.current.vm property b. Finds first vm in ordered list that fits lax.nl.valid.vm.list criteria Unix I. Searches the PATH Environment Variable II. Orders the path by using “echo $PATH | tr ':' ' _________________ --Scott MyEclipse Support