cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Faidon Liambotis (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-6240) CLASSPATH logic from init script is unused, JNA isn't loaded
Date Thu, 24 Oct 2013 20:48:01 GMT
Faidon Liambotis created CASSANDRA-6240:
-------------------------------------------

             Summary: CLASSPATH logic from init script is unused, JNA isn't loaded
                 Key: CASSANDRA-6240
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6240
             Project: Cassandra
          Issue Type: Bug
          Components: Packaging
            Reporter: Faidon Liambotis


The init script has a classpath() function that collects all the jars and even includes this
piece of code to work with the standard Debian/Ubuntu libjna-jar:
{code:none}
    # use JNA if installed in standard location
    [ -r /usr/share/java/jna.jar ] && cp="$cp:/usr/share/java/jna.jar"
{code}

This seems very nice and correct, however the classpath() function is never called and is
entirely unused :) Instead, /usr/bin/cassandra is called, which in turn includes /usr/share/cassandra/cassandra.in.sh,
which has basically similar code to collect the jars for CLASSPATH but a) without the JNA
standard path trick b) without using EXTRA_CLASSPATH (from /etc/default/cassandra) at all,
so Cassandra boots without either JNA nor EXTRA_CLASSPATH, contrary to expectations.

There are various suggestions on the web to do "ln -s /usr/share/java/jna.jar /usr/share/cassandra/lib/";
I suspect this bug to be the reason for that.

 /usr/share/cassandra/cassandra.in.sh seems smart enough to append but not overwrite CLASSPATH,
so fixing the init script's classpath() to only include JNA + EXTRA_CLASSPATH (and making
sure it's actually getting called :)) should be enough for a fix.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message