[fredatwork]

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)

[Scott Anderson]

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

[fredatwork]

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)

[Scott Anderson]

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

[Scott Anderson]

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

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

[Michael Dickson]

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

[Scott Anderson]

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

[Michael Dickson]

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

Mike

[Scott Anderson]

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.

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 ‘:’ ‘\012’| sort | uniq”
III. Choose
a. Checks to see if LAX_VM is set, if so uses
b. Uses value listed in lax.nl.current.vm property
c. Finds first vm in ordered list that fits lax.nl.valid.vm.list criteria

Current Shortcomings

When choosing a vm to run against, the launcher will choose the first valid vm it can find in the ordered list. If you have 1.3.1 and 1.4 installed, the launcher will typically run against the 1.3.1 vm even though it is not the latest vm on the system. This occurs because the latest version does not get presidence when the list is ordered.
You can also limit what the launcher can choose from by setting the lax.nl.valid.vm.list variable. The format of this property is listed in the InstallAnywhere User Guide. There is no way to specify that you want to run against a specific Java 1 or Java 2 vm. So while you can specify that you want to run against a Java 2 vm, you cannot tell the launcher to run only against 1.3.1 vm’s or 1.4.1 vm’s.
We are looking into correcting these shortcomings in the near future. There are different ways to work around these issues, and most of the require tweaking the PATH environment variable. Since the UNIX launcher is essentially a shell script you can modify it to fit your needs, but once it has been modified we can no longer support it. You can find the shell script for LaunchAnywhere in \resource\launchanywheres\unix.

Recommendations
We recommended always bundling a virtual machine with your application to avoid any of these problems. The main reason is that each Java virtual machine behaves differently, and there is no guarantee that your application will run the same way on all the vm’s. While it may make your installer a bit larger, you will be saving your QA department a considerable amount of time because they will not have to test how your application runs against different vm’s.

–Scott
MyEclipse Support

[Author]

Posts