Why oh why, when installing on Linux and it comes up with "A JVM was not detected", doesn't it tell us what JVM it is looking for so that we don't have to go grubbing through the docs to find what Java version goes with that Progress version.
If you need to start only a database server or a CHUI client, on linux/unix system
you can only create a litte script shell named /bin/java which send a echo of
java -version, like this, for OE v.10.1C.
#!/bin/sh
echo java version \"1.5.0\"
echo "Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)"
echo "Java HotSpot(TM) Server VM (build 1.5.0-b64, mixed mode)"
and chmod +x /bin/java
I have no problem with supplying the correct Java version ... it isn't hard to do. I just object to having to dig through a manual every time I do an update in order to find what Java version it wants. In the most recent case, it was a re-install, so the Java was already installed ... along with several other versions ... and all I needed to do was set the environment variables.
You can update the jre/jdk version and you have to modify the file:
$DLC/bin/java_env
search your OSNAME in the case and change the JDKHOME.
Yes, but my point is that the install will not work properly to install all components unless the Java is set up prior to proinst ... I get that ... it is simply that when it fails to find Java, I want it to tell me "I can't find Java x.y.z" so that I can go obtain that version or set up the environment variables for that version and try again. It should know what it wants. Why should I have to go dig it out of a manual?
I agree. The install process is brain-dead and needs a lot of work on the usability front. The Java related parts are some of the worst and most frustrating.
Finding which class files are missing ...
. $DLC/bin/slib_env
. $DLC/bin/java_env
ldd $DLC/bin/_sqlsrv
(From kCentre article P5892). In this case it is for the SQL92 server - basically acts in the same manner as the Win32 depends.exe. Would be nice to include a standard test based on the installed products - grep the output for 'not found' and fix the library path during the install (or copy required files into the derived library path). Often the java path/version errors present themselves as client 'bugs' (odbc failure, client appserver call failure) and can take some digging between the layers to find the final cause - better to resolve (or at least warn) of these issues during the install process.
Why oh why, when installing on Linux and it comes up
with "A JVM was not detected", doesn't it tell us
what JVM it is looking for so that we don't have to
go grubbing through the docs to find what Java
version goes with that Progress version.
I think this is because it is not that "fixed" and subject to change.
No, for any given release, one goes into the installation manuals and it specifies a version of Java. It might or might not work with another version, but one is specified. If they aren't going to bundle it, as they do with Windows (and why not all of them?), all that would be required is a value to be passed to the installer that says, if you don't find a version of Java, tell them the version that is expected. If you do find a version of Java and it isn't this one, then you might issue a warning.
Progress 9.1E on Red Hat Linux:
Manual: 1.3.1 SunJVM
Product avail guide: 1.3.1_10 and 1.4.1
The version I am using: 1.3.1_20
Current version: 1.3.1_??
Yes, they could be more helpful during the installation...
Maybe Progress is not allowed to bundle the SunJVM with anything else than Solaris? Don't know...