Bug 442402 - build-classpath cannot find jdbc-stdext unless -devel package is installed
Summary: build-classpath cannot find jdbc-stdext unless -devel package is installed
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: java-1.4.2-ibm
Version: 4.8
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: jiri vanek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-14 17:35 UTC by Deepak Bhole
Modified: 2011-06-14 07:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-14 07:26:18 UTC
Target Upstream Version:
Embargoed:


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 17:50 UTC, Deepak Bhole
no flags Details | Diff

Description Deepak Bhole 2008-04-14 17:35:44 UTC
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 13:07:15 UTC
"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 13:57:47 UTC
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 14:14:49 UTC
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 14:24:41 UTC
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 17:50:21 UTC
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 07:26:18 UTC
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.