Bug 174844 - startconsole should auto-detect correct version of java on the system
Summary: startconsole should auto-detect correct version of java on the system
Alias: None
Product: 389
Classification: Retired
Component: Directory Console (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: All Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 152373 240316
TreeView+ depends on / blocked
Reported: 2005-12-02 18:07 UTC by Rich Megginson
Modified: 2015-01-04 23:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-27 18:09:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rich Megginson 2005-12-02 18:07:20 UTC
A suggestion - since Red Hat packages and distributes RHEL with Java RPMs from
IBM, and since jpackage-utils puts some nice reasonable defaults in
/etc/java/java.conf for Java variables, and since Red Hat now has a directory
server that uses Java for management, how about modifying startconsole to check
/etc/java/java.conf first?  :)

The following should hold true:

The startconsole script didn't work for me to automatically detect
LIB{JAVA,JVM}_DIR, based on the output of find/sed, so I just hardcoded to the
above, which is what they would have ended up as anyway.  But after just digging
a little bit, the reason appears to be that "find /usr/lib/jvm/java -name
'libjvm.s[ol]'" returns nothing.

cd $JAVA_HOME (or /usr/lib/jvm/java)
find . -name 'libjvm.s[ol]' returns ./bin/classic/libjvm.so

or probably better,

find $JAVA_HOME/ -name libjava\.s[ol]

works too, so I think the trailing slash after JAVA_HOME is needed.

> Sounds good.  Will this work on Fedora Core or other linux distros?

I'm not sure how portable it would be with other distros (it should definitely
work on FC), but here was what I was thinking:

Check /etc/java/java.conf and if it exists try using the values there.  Maybe
tickle to see if /etc/{redhat,fedora}-release exists first.  I'd vote for a
"assume nothing but the known distributions/environments where this works
approach" (which is to say that if say a /etc/java/java.conf file exists on a
Solaris install, don't blindly assume that the values in it are anywhere near or
even related to what exists in a Red Hat java.conf file).  For binary packages,
this probably means including a RPM dependency for jpackage-utils (which in and
of itself could still lead to problems, since you could have that installed but
have no JRE installed..).

The more ways there are to find where the JRE might be (which may amount to
figuring out what the clues are on each distro/OS), the lower the bar to entry
becomes and Things Just Work.

Note You need to log in before you can comment on or make changes to this bug.