[CASSANDRA-11628] Fix the regression to CASSANDRA-3983 that got introduced by CASSANDRA-10679

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 2.1.15, 2.2.7, 3.0.6, 3.6
• Component/s: Legacy/Tools
• Severity: Normal
• Since Version: 3.2
• Assignee: Wei Deng
• Reporter: Wei Deng

Authors

Wei Deng

Reviewers

Yuki Morishita

• Created: 21/Apr/16 20:40
• Updated: 16/Apr/19 09:30
• Resolved: 26/Apr/16 01:10

Description

It appears that the commit from CASSANDRA-10679 accidentally cancelled out the effect that was originally intended by CASSANDRA-3983. In this case, we would like to address the following situation:

When you already have a C* package installed (which will deploy a file as /usr/share/cassandra/cassandra.in.sh), but also attempt to run from a binary download from http://cassandra.apache.org/download/, many tools like cassandra-stress, sstablescrub, etal. will search the packaged dir (/usr/share/cassandra/cassandra.in.sh) for 'cassandra.in.sh' before searching the dir in your binary download or source build. We should reverse the order of that search so it checks locally first. Otherwise you will encounter some error like the following:

root@node0:~/apache-cassandra-3.6-SNAPSHOT# tools/bin/cassandra-stress -h
Error: Could not find or load main class org.apache.cassandra.stress.Stress

root@node0:~/apache-cassandra-3.6-SNAPSHOT# bin/sstableverify -h
Error: Could not find or load main class org.apache.cassandra.tools.StandaloneVerifier

The goal for CASSANDRA-10679 is still a good one: "For the most part all of our shell scripts do the same thing, load the cassandra.in.sh and then call something out of a jar. They should all look the same." But in this case, we should correct them all to look the same but making them to look local dir first.

Issue Links

• links to: trunk commit
• links to: trunk dtest
• links to: trunk testall