Bug 442402 - build-classpath cannot find jdbc-stdext unless -devel package is installed
build-classpath cannot find jdbc-stdext unless -devel package is installed
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: java-1.4.2-ibm (Show other bugs)
4.8
All Linux
medium Severity medium
: rc
: ---
Assigned To: jiri vanek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-14 13:35 EDT by Deepak Bhole
Modified: 2011-06-14 03:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-14 03:26:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Sample solution that makes build-classpath search jre exports if sdk is not installed (1.75 KB, patch)
2011-06-13 13:50 EDT, Deepak Bhole
no flags Details | Diff

  None (edit)
Description Deepak Bhole 2008-04-14 13:35:44 EDT
Description of problem:
Jars like jdbc-stdext, jndi, etc. are provided by the java-1.4.2-ibm package.
However, build-classpath cannot find these jars unless java-1.4.2-ibm-devel is
installed.

How reproducible:
Always

Steps to Reproduce:
1. Uninstall all jvms from a RHEL4 machine (except gcj)
2. Install java-1.4.2-ibm (make sure java-1.4.2-ibm-devel is not installed
alongwith)
3. Run "build-classpath jdbc-stdext"

Actual results:
The script exits saying that the jar was not found.

Expected results:
The script should output the jar location, as the jar is provided by java-1.4.2-ibm.

Additional info:
I looked into the issue, and the problem is that the dir where build-classpath
looks (/usr/lib/jvm-exports/java), is pointed to the SDK exports dir
(/etc/alternatives/java_sdk_exports), which will be correct only if the -devel
subpackage of the jvm is installed.

Either the place where build-classpath looks should be modified, or, if that is
not possible, the extensions like jdbc, jndi, etc. should be moved to the -devel
subpackage.
Comment 2 jiri vanek 2011-06-13 09:07:15 EDT
"the extensions like jdbc, jndi, etc. should be moved to the -devel"

IMHO we definitely needs them in jre.

" and the problem is that the dir where build-classpath
looks (/usr/lib/jvm-exports/java), is pointed to the SDK exports dir
(/etc/alternatives/java_sdk_exports)"

/usr/lib/jvm-exports/java-1.4.2-ibm-sap-1.4.2.XX.YY.{sap.}arch/ directory is created by java 1.4.2 package. This one contains all (eg jdbc) jars. This one is linked from /usr/lib/jvm-exports/java-1.4.2-ibm{-.sap}.arch (comes from java package) and /usr/lib/jvm-exports/java-1.4.2-ibm-sap-1.4.2{-sap}.arch(comes from devel package). It is not nice that those two packages shares file, but this symlink can be used in alternatives

All the way -  openjdk have just link from jvm-exports to itself, sun java and another ibm javas have structure similar to this one and others are using jre-exports - and all those (including IBM 1.4.2) have jre-exports which should serve for purpose mentioned above.

This issue can probably infect all supported javas.
Comment 3 jiri vanek 2011-06-13 09:57:47 EDT
one typo above:

from /usr/lib/jvm-exports/jre-1.4.2-ibm{-.sap}.arch (comes from java
package) and /usr/lib/jvm-exports/java-1.4.2-ibm-sap-1.4.2{-sap}.arch(comes
from devel package). 

So pckages do not share files - sorry
Comment 4 jiri vanek 2011-06-13 10:14:49 EDT
The link collection is ok - 
jre creates directory  
 /usr/lib/jvm-exports/java-1.4.2-ibm-sap-1.4.2.XX.YY.{sap.}arch
jre creates link
 /usr/lib/jvm-exports/jre-1.4.2-ibm{-.sap}.arch  to this directory
jdk creates link
 /usr/lib/jvm-exports/java-1.4.2-ibm{-.sap}.arch  to this directory

java alternatves slave 
 --slave %{_jvmjardir}/jre                  jre_exports                 %{_jvmjardir}/%{jrelnk} \  points to correct (first) link

javac alternatives slave
 --slave %{_jvmjardir}/java                  java_sdk_exports            %{_jvmjardir}/%{sdklnk} \ points to correct (second) link

after reading /usr/share/java-utils/java-functions file's method do_find_jar(), the find algorithm bruteforce "six" directories -  
 for jardir in "$JVM_LIBDIR" "$JAVAVER_JNIDIR" "$JAVAVER_LIBDIR" \
                 "$JAVAAPP_LIBDIR" "$JNI_LIBDIR" "$JAVA_LIBDIR" ; do

 $JVM_LIBDIR is pointing to /usr/lib/jvm-exports/java
Comment 5 jiri vanek 2011-06-13 10:24:41 EDT
Solution which keeps all things as they are is the one, which will add  /usr/lib/jvm-exports/jre-1.4.2-ibm{-.sap}.arch (configured by alternatives) to do_find_jar() search path.

I'm afraid all proprietary jdk's are affected by this issue.

Is this possible to be done on package jpackage-utils maintainer level?

( --slave %{_jvmjardir}/jre                  jre_exports    points t odesired directory.)
Comment 6 Deepak Bhole 2011-06-13 13:50:21 EDT
Created attachment 504509 [details]
Sample solution that makes build-classpath search jre exports if sdk is not installed

Yep, this is certainly doable on jpackage-utils side. 

Sample solution attached.
Comment 8 jiri vanek 2011-06-14 03:26:18 EDT
Attached patch serve its purpose. By this issue are affected all proprietary javas for rhel. Also this issue occurs only when just jre is instaled - and this is very rare issue as noone complains about this for more then two years.

If some problems occur in future, this patch will be included into jpackage-utils.

For now closing.

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