Bug 743379 - CLI fails on running *.js files with error
CLI fails on running *.js files with error
Product: RHQ Project
Classification: Other
Component: CLI (Show other bugs)
3.0.0 Beta1
x86_64 Linux
high Severity urgent (vote)
: ---
: JON 3.0.0
Assigned To: Lukas Krejci
Mike Foley
Depends On:
Blocks: 717392 rhq42 786976
  Show dependency treegraph
Reported: 2011-10-04 13:59 EDT by Nabeel Saad
Modified: 2015-11-01 19:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 786976 (view as bug list)
Last Closed: 2012-02-07 14:25:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
autoimport JS file to test the CLI - currently works in JON 2.4.1 with all the latest patches (1.12 KB, application/javascript)
2011-10-04 13:59 EDT, Nabeel Saad
no flags Details

  None (edit)
Description Nabeel Saad 2011-10-04 13:59:20 EDT
Created attachment 526287 [details]
autoimport JS file to test the CLI - currently works in JON 2.4.1 with all the latest patches

Description of problem:
When I try to run a CLI command inputting a file name like so:

  /opt/jon-demo-3.0/jon-tools/rhq-remoting-cli-4.1.1-BETA1/bin/rhq-cli.sh -f autoImport.js

I get the following error:
  Exception in thread "main" java.lang.NullPointerException
	at org.rhq.bindings.StandardBindings.<init>(StandardBindings.java:92)
	at org.rhq.enterprise.client.commands.ScriptCommand.initBindings(ScriptCommand.java:171)
	at org.rhq.enterprise.client.commands.ScriptCommand.execute(ScriptCommand.java:78)
	at org.rhq.enterprise.client.ClientMain.processArguments(ClientMain.java:505)
	at org.rhq.enterprise.client.ClientMain.main(ClientMain.java:106)
rhq-cli.sh: /opt/jon-demo-3.0/jon-tools/rhq-remoting-cli-4.1.1-BETA1/bin/rhq-cli.sh done.

I seem to remember seeing a similar NullPointerException with the CLI in JON 2.4.1 that required one of the patches available in CSP at the moment (BZ704371), not sure if this has some how reverted.

Version-Release number of selected component (if applicable):
JON 3.0.0-Beta1 --> rhq-remoting-cli-4.1.1-BETA1

How reproducible:

Steps to Reproduce:
1. Start JON server
2. Setup CLI locally, go to bin folder
3. Save the uploaded autoimport.js file to the bin folder
4. Run the following command:
      ./rhq-cli.sh -f autoImport.js
Actual results:
The error displayed above

Expected results:
It should actually run the JS file and either import resources into the JON server or say there are no resources to import.

Additional info:
This breaks a lot of the scripting abilities and is quite important to resolve.
FYI, the CLI still works if you log in manually and then type in the commands from the autoimport.js file, but passing it seems to fail.
Comment 2 Charles Crouch 2011-10-05 09:47:58 EDT
Comment 3 John Sanda 2011-10-10 09:27:47 EDT
I just reproduced this bug with a simple script.

// inventory.js
rhq.login('rhqadmin', 'rhqadmin');
var resources = ResourceManager.findResourcesByCriteria(ResourceCriteria());
println('There are ' + resources.size() + ' resources in inventory');

// end script

I get the same NPE when I try running with rhq-cli.sh -f inventory.js. This is
a major regression. It looks like it prevents users from running script files
in batch or non-interactive mode. Fortunately there is somewhat of a work
around. You can execute script files from the interactive shell using the exec
command. If I log into the interactive shell, I can run the script file from
there. Here is an example to illustrate:

bash-4.1$ ./rhq-cli.sh 
RHQ - RHQ Enterprise Remote CLI 4.1.0-SNAPSHOT
unconnected$ login rhqadmin rhqadmin
Remote server version is: 4.1.0-SNAPSHOT (3177dd2)
Login successful

rhqadmin@localhost:7080$ exec -f inventory.js
Remote server version is: 4.1.0-SNAPSHOT (3177dd2)
There are 200 resources in inventory
Comment 4 Nabeel Saad 2011-10-10 10:19:41 EDT
Hello John,

Glad you were able to reproduce this so easily.  The workaround is good to know; however, it still doesn't allow for running the script via an "automated" process, can you?

i.e you can't have an external script call a CLI JS script...  

I'm trying to find a way around that because in the next couple of weeks I will NEED this functionality for an important demo...

Out of the things that you did, I would have expected that you wouldn't have to do:
   login rhqadmin rhqadmin

Given that your script had that line in the JS file.  I think that is the main problem.  If you try to do the line:
   exec -f inventory.js

before the login, it fails with the same NPE stack.

I guess in the meantime, I could do the following to get things working the way I want it to:

   (echo "login rhqadmin rhqadmin"; echo "exec -f /opt/CLI/autoImport.js"; echo "quit") | ./rhq-cli.sh 

Comment 5 Heiko W. Rupp 2011-10-11 03:49:16 EDT
In org.rhq.enterprise.client.ClientMain#executePromptCommand at
     boolean result = commands.get("exec").execute(this, args);
this is supposed to be a ClientMain that has a remoteClient already set.
This is not true, which later makes the cli go to org.rhq.enterprise.client.commands.ScriptCommand#initBindings

    public void initBindings(ClientMain client) {
        if (jsEngine == null) {
            bindings = new StandardBindings(client.getPrintWriter(), client.getRemoteClient());

and then NPE in

org.rhq.bindings.StandardBindings#StandardBindings when trying to get the managers

    public StandardBindings(PrintWriter output, RhqFacade rhqFacade) {
        PageControl pc = new PageControl();

        managers = rhqFacade.getManagers();
Comment 6 Lukas Krejci 2011-10-11 11:43:35 EDT
commit 909e4f54d6d932c1c9168bce97f6a9cad42b33a2
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Tue Oct 11 17:33:19 2011 +0200

    BZ 743379 - Make sure to initialize the script engine with as much bindings
    as possible before the user logs in (and add the rest when logged in).
Comment 7 Mike Foley 2011-10-13 10:27:25 EDT
verified RHQ 10/13 build.
Comment 8 Mike Foley 2012-02-07 14:25:20 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 9 Charles Crouch 2012-02-14 19:20:32 EST
Setting Target Release correctly

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