[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998428#comment-15998428 ]
Sean Busbey commented on HBASE-15199: ------------------------------------- {quote} The patch of HBASE-15199 does change the behavior of {code}HBASE_OPTS="$HBASE_OPTS -Djruby.home=$JRUBY_HOME -Djruby.lib=$JRUBY_HOME/lib"{code} Without the patch, it only takes effect when hbase shell. With the patch, it takes effect whenever JRUBY_HOME is specified explicitly, so jruby jar appears in hbase server's CLASSPATH. {quote} Hurm. Any reason we should keep it in server CLASSPATH? that sounds like a source of operator headache. I think I grok [~jerryhe]'s comment now; putting hte JRUBY_HOME check within the "do we need jruby now?" block makes more sense to me. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > ------------------------------------------------------------------------------------ > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell > Reporter: stack > Assignee: Xiang Li > Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch, > HBASE-15199.master.002.patch, HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)