Bug 428520

This is likely best solved by changing /etc/sysconfig/hsqldb to read:
  JAVA_EXECUTABLE=/usr/lib/jvm/java/bin/java

or (equivalently, "/usr/lib/jvm" is a symlink):
  JAVA_EXECUTABLE=/etc/alternatives/java_sdk/java/bin/java

Thoughts?

/usr/lib/jvm/java is the default jvm set by alternatives. I would propose that
we add a line in /etc/sysconfig/hsqldb:

JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/java}

right above JAVA_EXECUTABLE=${JAVA_HOME}/bin/java

This will ensure that the alternatives-set jvm gets used each time -- be it
Icedtea or GCJ (or any other jpp compliant jvm installation)

> Thoughts?
Count me "Java naive".  Any reasonable default for $JAVA_EXECUTABLE
is fine with me.  OTOH I looked at two different F8 installations,
one done "from scratch" and the other with a long history of
upgrades, and on none of those /usr/lib/jvm/java exists.  I know
that in both cases nobody was messing up with java installations.

OTOH a link /usr/lib/jvm/jre/ does exist, it goes through alternatives,
and it looks like a reasonable candidate for JAVA_HOME.
/usr/lib/jvm/jre/bin/java is indeed some executable.

Any F8 system with a proper jvm installation (i.e. gcj, or icedtea) should have
/usr/lib/jvm/java ... if that dir doesn't exist, it is a bug. Which jvm is
installed on the system where that dir doesn't exist?

> Which jvm is installed on the system where that dir doesn't exist?

$ grep java /var/log/rpmpkgs
java-1.5.0-gcj-1.5.0.0-17.fc8.i386.rpm
java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8.i586.rpm
java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8.i586.rpm
java_cup-0.10-0.k.6jpp.1.i386.rpm
tzdata-java-2007k-1.fc8.noarch.rpm

This is on a system installed "from scratch".  Looking at 'install.log',
which is still there, all five packages were installed by anaconda
while building up an initial system and some updated afterfwards.

Definitely no /usr/lib/jvm/java although one can find
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/

On a system which went through updates there is also
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/
with no files in it but a bunch of links pointing to files
from libgcj-4.1.2-33.x86_64 package and one dangling link
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/security/java.security
to /usr/lib/security/classpath.security (which does not exist).
This is x86_64 installation so that link really should be to
an existing /usr/lib64/security/classpath.security but it is not.

Does the file /var/lib/alternatives/java exist on your system?

Created attachment 291909 [details]
a content of /var/lib/alternatives/java on F8 "from scratch" installation

> Does the file /var/lib/alternatives/java exist on your system?

That system is not precisely "mine" but I have an access to it. :-)

A content of this file, not edited in any way, is attached.

Michal, is /etc/alternatives/java a valid symlink (to a Java binary) on either
of the systems?

In both cases /etc/alternatives/java is a link to 'java':
/usr/lib/jvm/jre-1.7.0-icedtea/bin/java on one system and to
/usr/lib/jvm/jre-1.7.0-icedtea.x86_64/bin/java on another.

Anyone object to my setting "JAVA_EXECUTABLE=/etc/alternatives/java"?

(In reply to comment #10)
> Anyone object to my setting "JAVA_EXECUTABLE=/etc/alternatives/java"?

OK, I think I know what the problem is.  Michal, do you have a -devel Java
package installed?  Either java-1.5.0-gcj-devel or java-1.7.0-icedtea-devel? 
/usr/lib/jvm/java is an alternatives-installed symlink, installed by the -devel
post script.

If hsqldb requires only a runtime environment, then the correct fix is to set
JAVA_EXECUTABLE=/usr/lib/jvm/jre/bin/java.  This will always point to the
currently-selected alternative's java command.  /usr/lib/jvm/jre is an
alternatives-installed symlink installed by the base packages'
(java-1.7.0-icedtea and java-1.5.0-gcj) post scripts.

> Michal, do you have a -devel Java package installed?

Nope.  See comment #5 for a full list of packages present.

> then the correct fix is to set JAVA_EXECUTABLE=/usr/lib/jvm/jre/bin/java

That is what I suggested in comment #3.  It looks that
JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/jre}
in /etc/sysconfig/hsqldb would solve the issue.

Michal, the new package is pending to go into F8's testing repo.

(It's also here: http://koji.fedoraproject.org/koji/buildinfo?buildID=32395)

hsqldb-1.8.0.9-1jpp.1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update hsqldb'

hsqldb-1.8.0.9-1jpp.1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update hsqldb'

Hi Michal, did the fix work?

> Hi Michal, did the fix work?

One would think that you can check that as trivially as I can.

On F9 installation with hsqldb-1.8.0.9-2jpp.1.fc9 updated on "Fri 13 Jun 2008" and with '/etc/sysconfig/hsqldb' coming from that package:

# /etc/init.d/hsqldb status
JAVA_EXECUTABLE or HSQLDB_JAR_PATH in '/etc/sysconfig/hsqldb' is set to a non-file.

This is what this fragment of /etc/sysconfig/hsqldb is roughly trying to do:

. /etc/java/java.conf

JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/jre}
JAVA_EXECUTABLE=${JAVA_HOME}/bin/java

echo $JAVA_HOME $JAVA_EXECUTABLE

The last line prints "/usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java" and
none of these exists.  The following are present, though:

/usr/lib/jvm/jre-1.5.0
/usr/lib/jvm/jre-1.5.0-gcj
/usr/lib/jvm/jre-1.6.0
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64
/usr/lib/jvm/jre-gcj
/usr/lib/jvm/jre-openjdk

BTW - '/etc/java/java.conf' comes from jpackage-utils-1.7.5-1jpp.2.fc9
installed on "Wed 23 Jul 2008"

This has nothing to do with hsqldb.  /usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java  must exist if java is properly installed in your system.  They are alternatives symlinks that point to the highest priority Java in your system.  If neither gcj nor openjdk are providing it you should open a bug against those components.  But check if nothing went wrong when installing those.

> This has nothing to do with hsqldb.

Well, if you think so then reassign the report appropriately instead of wrongly closing it.  So far I see that hsqldb is broken.

> /usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java must exist

Maybe.  Only postinstall scripts for java-1.6.0-openjdk-1.6.0.0-0.18.b09.fc9
and for java-1.5.0-gcj-1.5.0.0-21.fc9 do not create anything of that
sort.  I just checked.  I do see there:

  --slave /usr/lib/jvm/jre jre /usr/lib/jvm/jre-1.6.0-openjdk.x86_64 \

but when I am trying to run the whole script which included the above then it prints "numeric priority expected in /var/lib/alternatives/java".  I have no idea what that is supposed to mean. Again - if you think that something else is responsible then change that bug to that something else.  I have no idea what that may be.

I forced somehow alternatives to create /usr/lib/jvm/jre and /usr/lib/jvm/jre/bin/java.

# ls -l /usr/lib/jvm/jre
lrwxrwxrwx 1 root root 21 2008-10-22 14:11 /usr/lib/jvm/jre -> /etc/alternatives/jre
# rpm -qf /usr/lib/jvm/jre/bin/java
java-1.6.0-openjdk-1.6.0.0-0.18.b09.fc9.x86_64

and the later is a file 38616 bytes in size.

'/etc/init.d/hsqldb status' still says "JAVA_EXECUTABLE or HSQLDB_JAR_PATH in '/etc/sysconfig/hsqldb' is set to a non-file". This time this turns out to
be hsqldb package postinstall script which failed to make links in hsqldb.jar and servlet.jar in /var/lib/hsqldb/lib.  That depends on build-classpath from jpackage-utils but the current version of jpackage-utils was installed roughly a month after hsqldb update.  Re-executing that script eventually kills a "non-file" message.  All that seems to be extremely fragile.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug is still present on Fedora 15. 

One have to make the symlink by hand in /var/lib/hsqldb/lib.

hsqldb.jar -> /usr/share/java/hsqldb.jar

Before it was (re-installed, force upgrading do not change anything) 

hsqldb.jar -> hsqldb.jar (symlink to self). 

Cheers.