Bug 558542 - NPE when trying to start CLI under openjdk on RHEL
Summary: NPE when trying to start CLI under openjdk on RHEL
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: CLI
Version: 1.3.1
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Filip Drabek
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: JON231
TreeView+ depends on / blocked
 
Reported: 2010-01-25 16:01 UTC by Corey Welton
Modified: 2018-11-14 14:19 UTC (History)
5 users (show)

Fixed In Version: 1.3.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-02 07:15:00 UTC
Embargoed:


Attachments (Terms of Use)
Quick test for RHQ CLI dependency (815 bytes, text/x-java)
2010-02-04 17:38 UTC, Simeon Pinder
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 55239 0 None None None Never

Description Corey Welton 2010-01-25 16:01:20 UTC
Description of problem:
If a user tries to use the openjdk packages installed on rhel to launch the RHQ CLI, s/he gets a null pointer exception.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1.  Assure RHEL system is running latest openjdk as the default java 
2.  Unzip CLI
3.  ./rhq-remoting-cli-1.3.0.GA/bin/rhq-cli.sh 

Actual results:
[root@hongse ~]# ./rhq-remoting-cli-1.3.0.GA/bin/rhq-cli.sh 
Exception in thread "main" java.lang.NullPointerException
	at org.rhq.enterprise.client.commands.ScriptCommand.<init>(ScriptCommand.java:83)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at java.lang.Class.newInstance0(Class.java:372)
	at java.lang.Class.newInstance(Class.java:325)
	at org.rhq.enterprise.client.ClientMain.initCommands(ClientMain.java:118)
	at org.rhq.enterprise.client.ClientMain.main(ClientMain.java:103)


Expected results:

CLI successfully launches.

Additional info:


[root@hongse ~]# rpm -qa|grep openjdk|sort
java-1.6.0-openjdk-1.6.0.0-1.7.b09.el5
java-1.6.0-openjdk-demo-1.6.0.0-1.7.b09.el5
java-1.6.0-openjdk-devel-1.6.0.0-1.7.b09.el5
java-1.6.0-openjdk-javadoc-1.6.0.0-1.7.b09.el5
java-1.6.0-openjdk-src-1.6.0.0-1.7.b09.el5

It seems to work just fine with Fedora 12, which has a slightly different release version, though I don't think that's the issue here:

[root@jiaozi ~]# rpm -qa|grep openjdk|sort
java-1.6.0-openjdk-1.6.0.0-30.b16.fc11.x86_64
java-1.6.0-openjdk-demo-1.6.0.0-30.b16.fc11.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-30.b16.fc11.x86_64
java-1.6.0-openjdk-javadoc-1.6.0.0-30.b16.fc11.x86_64
java-1.6.0-openjdk-plugin-1.6.0.0-30.b16.fc11.x86_64
java-1.6.0-openjdk-src-1.6.0.0-30.b16.fc11.x86_64

Comment 1 Simeon Pinder 2010-02-04 17:38:06 UTC
Created attachment 388849 [details]
Quick test for RHQ CLI dependency

Quick test for RHQ CLI dependency

Comment 2 Simeon Pinder 2010-02-04 17:44:31 UTC
This is a java/jre/jdk release problem. The scripting package is completely missing from the rt.jar library for some RHEL instances(Ex. rlx-0-12.rhndev.redhat.com).  We can put better defensive code on the CLI side to tell them i) we can't proceed ii) they need to try a later JDK. 

In addition the attached file should be compiled (javac TestScript) and run (java TestScript) on each JDK version to quickly check that the CLI prerequisites(existing in a sound JDK) are indeed there. 

The right solution to this problem is to determine the minimum level of OpenJDK (32 and 64 bit and RHEL/Fedora) that this problem does not occur in and document in the release notes for the CLI. 

*Note: We're probably building the OpenJDK for both RHEL and Fedora so we should verify both and their 32 and 64 bit versions as well.* 

Looks like it works on:
java-1.6.0-openjdk-1.6.0.0-29.b16.fc11.x86_64
java-1.6.0-openjdk-1.6.0.0-30.b16.fc11.x86_64

and NOT on:
java-1.6.0-openjdk-1.6.0.0-1.7.b09.el5

Comment 3 Corey Welton 2010-02-04 18:26:29 UTC
Confirmed that it does fail on RHEL i386 and x86_64 arches.

Comment 4 Simeon Pinder 2010-02-08 16:53:00 UTC
Discussion continues on what the real solution to this problem should be.  The issue is more widespread than initially thought.  The following bug reports that appear related to this issue are listed below:

i) https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=470313

ii) http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=179

There are some indications that the required libraries may have been removed from the RHEL distribution due to licensing concerns.  Charles is investigating this aspect. 

Provided there are no licensing/business reasons why openjdk cannot be patched or made to work with alternative scripting engines out of the box, Ian Springer has proposed the following potential workarounds to get the CLI working on OpenJdk.  Further research, testing and management guidance would be needed to choose the best alternatives to proceed with:

---------------------------------------------------------------------------
############# mail post/excerpt from Ian Springer -- 2/5/10 --#############
I did some research on this a couple days ago to help Simeon out. From
what I gathered, the newer versions of openjdk that support jscript
out-of-box as long as the rhino package is installed, do so by
automatically adding /usr/share/java/js.jar to the JVM's bootclasspath.
So knowing this, I think we might be able to get Rhino installed using a
few potential methods:

1) Append the following option to the CLI java command line:

-Xbootclasspath/p:/opt/rhq-cli/lib/js-1.7R2.jar

(which will prepend /opt/rhq-cli/lib/js-1.7R2.jar to the beginning of
the bootclasspath)

This would work for either an older openjdk version or a newer one. For
the newer ones, it would allow us to put out own newer js.jar ahead of
whatever /usr/share/java/js.jar the user has installed as part of the
rhino package.

Or if a newer openjdk is detected but the rhino package is not
installed, we have a couple other options:

2) yum install rhino

This assumes the latest version of rhino that's available from the
default RHEL repos will work for the CLI, which sounds like it may not
be the case.

3) rpm -i /opt/rhq-cli/etc/rhino-1.7-1.r2.6.jpp5.noarch.rpm

4) ln -s /opt/rhq-cli/lib/js-1.7R2.jar /usr/share/java/js.jar

############# mail post/excerpt from Ian Springer -- 2/5/10 --#############
---------------------------------------------------------------------------

If the correct Rhino installation is not actually bundled with OpenJDK, then the working solution for correct script engine usage on openjdk goes outside of the normal java usage pattern.  For most java applications, the JVM is the only core dependency and application specific dependencies are taken care of by the application developer at install time.  Making the JDK itself depend(for correct operation) upon an external version of a platform specific library like Rhino is an exceptionally bad idea as it ignores one of java's central tenets of uniform cross platform operation.

Comment 5 Charles Crouch 2010-02-08 21:35:42 UTC
Closing this issue for now and we can revisit testing RHQ CLI support when RHEL includes a version of openjdk which includes rhino.

Comment 10 Charles Crouch 2011-03-07 19:56:06 UTC
Re-opening to investigate RHEL version support

Comment 17 Larry O'Leary 2011-05-05 19:52:31 UTC
rhino has made it into the OpenJDK package for RHEL 5.6.z (http://rhn.redhat.com/errata/RHEA-2011-0485.html). Specific RPM it made it into is: java-1.6.0-openjdk-1.6.0.0-1.21.b17.el5.x86_64.rpm.

Comment 18 Charles Crouch 2011-06-07 20:39:04 UTC
Since the package is now available in RHEL5.6, I'm pushing this ON-QA for testing.
The test from https://bugzilla.redhat.com/show_bug.cgi?id=558542#c8 should now pass and any CLI script should now be executable from an up to date RHEL5.6 instance.

Comment 20 Heiko W. Rupp 2013-09-02 07:15:00 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.


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