Torquebox LoadError - no such file to load -- torquebox/Service_registry

Question

Installed torquebox-server gem.

$torquebox run is ok. Program runs fine on Apache proxy Torquebox through :80 and SSL AJP :8009.

Here's where it hits the fan: 'sudo service torquebox start' with UpStart behaves well with one exception. No errors in the browser. Just a blank white page. I'm using chruby. Here's the torquebox log:

Unable to require file: torquebox/service_registry: org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- torquebox/service_registry at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1071) [jruby.jar:] at RUBY.require(/home/klyde/.rubies/jruby-1.7.19/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:54) at RUBY.(root)(:1)

Of course, the directory and file above exist, as torquebox's own log shows.

torquebox run executes fine, it would seem, because jruby-1.7.19 (the same as Torquebox's v 3.1.2 runtime on jruby-1.7.19), gems, and program all reside under my Ubuntu user 'klyde'. But this command is merely for development/test. When running as a service, Torquebox is looking sideways at the 'torquebox' user, with its own bashrc. Yes, Torquebox requires its own user! So under both users, klyde and torquebox, the bashrc's contain the same:

export TORQUEBOX_HOME=/home/klyde/.gem/jruby/1.9.3/gems/torquebox-server-3.1.2-java
export TORQUEBOX_HOME_RAKE_SUPPORT=/home/klyde/.gem/jruby/1.9.3/gems/torquebox-rake-support-3.1.2
export TORQUEBOX_SERVER=/home/klyde/.gem/jruby/1.9.3/gems/torquebox-server-3.1.2-java
export JBOSS_HOME=$TORQUEBOX_SERVER/jboss
export JRUBY_HOME=/home/klyde/.rubies/jruby-1.7.19
export PATH=$JRUBY_HOME/bin:$PATH

export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin

I've read that Torquebox anticipates paths, etc, through it's own version of jruby runtime, as opposed to what chruby (or rvm, rbenv) might do. In this spirit, I've added torquebox user to the klyde group. I've raised permissions on a couple files in my klyde .gem directory, providing a quick and dirty cure. I've even attempted chown -R torquebox:torquebox /home/klyde/.rubies. No luck there )

Question: Must i reinstall everything, program included, under the torquebox user, as if that would work, anyway?? Or is there a more elegant (sane) approach?

Answer 1

Solution:

Solved. I'll answer my own question. Here is a pile of tips I recall.

The heart of the matter seems to be a problem with the gem path. See this comment. And this. Whereas Ruby managers often like to seperate gems from rubies, eg. ~/.gem ~/.rubies, when you look at the native JRuby that ships with Torquebox, you'll see that Torquebox tucks gems away in JRuby's own subfolders:

/opt/torquebox/torquebox-3.1.2/jruby/lib/ruby/gems/shared/gems/

As proof of this, you'll see that the Torquebox binary download includes the gem suite 'torquebox-server'.

I had used chruby and ran:

$ jruby -S gem install torquebox-server

And like RVM, it worked fine using 'torquebox run'. But to take advantage of production-like commands - 'sudo service torquebox start' - I found it necessary to downloaded the binary and install under /opt in order to follow the instructions for 'upstart'.

Warbler prepares a .war file for JBoss. But Torquebox, which wraps JBoss, provides its own code, designed to replace the need of the .war. However, both 'torquebox run' or 'sudo service torquebox start' call bundler. So how gems are placed through bundler seems to be important. A copy/paste of gems into the native JRuby (/opt/torquebox/torquebox-3.1.2/jruby...) may not work (as I discovered).

Assuming you (wisely) wish to use your own JRuby under ~/ , and after environment variables are set (as I show), then from the terminal, you will want to see something like this:

$ jruby -S gem env
RubyGems Environment:
- RUBYGEMS VERSION: 2.4.5
- RUBY VERSION: 1.9.3 (2015-01-29 patchlevel 551) [java]
- INSTALLATION DIRECTORY: /home/klyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared
- RUBY EXECUTABLE: /home/klyde/.rubies/jruby-1.7.19/bin/jruby
- EXECUTABLE DIRECTORY: /home/klyde/.rubies/jruby-1.7.19/bin
- SPEC CACHE DIRECTORY: /home/klyde/.gem/specs
- SYSTEM CONFIGURATION DIRECTORY: /home/klyde/.rubies/jruby-1.7.19/etc

- GEM PATHS:
- /home/klyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared

Notice .rubies, NOT .gem.

If RVM or rbenv or chruby is enabled, it will try to control GEM_HOME. This must be disabled. One suggestion, look in /etc/profile.d/

From any directory, GEM_HOME should be empty, or at least, pointing to a path in your JRuby's subfolders.

As a test:

$ echo $GEM_HOME
(here we can have a blank line)

And in ~/.gemrc

install: --no-ri --no-rdoc
update:  --no-ri --no-rdoc 

gemhome: /home/klyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared
gempath: /home/klyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared

Although the above manual edits will work, how uncivilized!) Especially in development, it's convenient to use a manager to switch rubies per program. To get the best of both worlds, I'll use chruby as an example.

The natural directory for gems in a ruby/jruby is actually in its own subfolders. This is GEM_ROOT. And GEM_ROOT remains constant. chruby alters or artificially creates a GEM_HOME and GEM_PATH from what it finds in the GEM_ROOT. Then it proceeds to file away gems under ~/.gem. Observe:

$ echo $GEM_ROOT    
/home/klyde/.rubies/ruby-2.2.2/lib/ruby/gems/2.2.0

$ echo $GEM_HOME
/home/klyde/.gem/ruby/2.2.2

$ echo $GEM_PATH
/home/klyde/.gem/ruby/2.2.2:/home/clyde/.rubies/ruby-2.2.2/lib/ruby/gems/2.2.0

And for jruby...

$ echo $GEM_ROOT    
/home/klyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared

$ echo $GEM_HOME
/home/klyde/.gem/jruby/1.9.3

$ echo $GEM_PATH
/home/klyde/.gem/jruby/1.9.3:/home/clyde/.rubies/jruby-1.7.19/lib/ruby/gems/shared

To override this in chruby:

/usr/local/share/chruby/chruby.sh

function chruby_use()
{
    ....
    if (( $UID != 0 )); then
        # export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/$RUBY_VERSION"
        # export GEM_PATH="$GEM_HOME${GEM_ROOT:+:$GEM_ROOT}${GEM_PATH:+:$GEM_PATH}"
        # export PATH="$GEM_HOME/bin${GEM_ROOT:+:$GEM_ROOT/bin}:$PATH"

        export GEM_HOME="$GEM_ROOT"
        export GEM_PATH="$GEM_ROOT"
        export PATH=$GEM_HOME/bin:$PATH
        export PATH=$GEM_PATH/bin:$PATH
    fi
}

Each ruby/jruby becomes its own gemset. If you're not opposed to that, this quick edit in chruby will solve your problem with Torquebox's strict way of referencing gems. And you'll still be able to use the manager as usual between programs. Re-editing chruby.sh, you can return the manager to its default behavior. It's that simple!)

Knowing this little trick involving GEM_ROOT, perhaps the same remedy could be applied in RVM and rbenv.

1. Install Ruby and JRuby: I use chruby or 'ruby-install', and install rubies under ~/. Using either, the rubies/jrubies go into ~/.rubies.

2. Installing Torquebox binary: On Ubuntu 14.04, I followed precisely Torquebox manual 21.1.2 Torquebox Installation.

3. Env vars: If using the GEM_ROOT trick described above, the RUBY_HOME and JRUBY_HOME can probably be ignored.

/etc/profile.d/torquebox.sh :

export TORQUEBOX_HOME=/opt/torquebox/current
export JBOSS_HOME=$TORQUEBOX_HOME/jboss
export JRUBY_HOME=/home/klyde/jruby-1.7.19
PATH=$JBOSS_HOME/bin:$JRUBY_HOME/bin:$PATH

I also edited... /etc/profile

export TORQUEBOX_HOME=/opt/torquebox/current
export JBOSS_HOME=$TORQUEBOX_HOME/jboss
export JRUBY_HOME=/home/klyde/jruby-1.7.19

PATH=$JBOSS_HOME/bin:$JRUBY_HOME/bin:$PATH
export RUBY_HOME=/home/klyde/ruby-2.2.2

export PATH=$RUBY_HOME/bin:$PATH
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin

4. Sym link or move a copy of torquebox.conf:

   /opt/torquebox/torquebox-3.1.2/share/init/torquebox.conf

   into:

   /etc/init/torquebox.conf

Then edit a line. JBoss needs a clear path to its turn-on button, standalone.sh:

/opt/torquebox/current/jboss/bin/standalone.sh >> /var/log/torquebox/torquebox.log 2>&1

5. Enable 'sudo service torquebox start' with the rake upstart, Torquebox manual 18.4 Server control.

6. If using nokogiri:

I replaced nokogiri 1.6.6.2 with 1.6.1. For many, this change has been necessary. Google it for more info. This appears in a gem list as 1.6.1-java, and in my Gemfile (gem 'nokogiri', '1.6.1-java'). You may have to gut out (delete) the contents of Gemfile.lock, as well as directly editing it - nokogiri (1.6.1-java). '$jruby -S bundle' will not overwrite Gemfile.lock after direct edit, as will 'bundle install or update':

$jruby -S gem install nokogiri 1.6.1

This site is generally under SSL. For sake of those curious, and for me, should I ever forget, here's what my Apache proxy Torquebox looks like:

/etc/apache2/sites-available/example.conf :

<VirtualHost example.com:80>
    ServerAdmin webmaster@localhost
    ServerName example.com
    Redirect / https://example.com
</VirtualHost>

/etc/apache2/sites-available/example-ssl.conf :

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>

        SSLEngine on
        SSLCertificateFile   /etc/apache2/ssl/certs/16746xxxxxbbac.crt
        SSLCertificateChainFile /etc/apache2/ssl/certs/sf_bundle-g2-g1.crt
        SSLCertificateKeyFile /etc/apache2/ssl/private/ks.key

        ServerAdmin webmaster@localhost
        ServerName example.com
        ServerAlias example.com
        DocumentRoot /home/klyde/ror/exampleprog/public

        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPassReverseCookiePath / /
        ProxyPass /errors/ !
        ProxyPass / ajp://localhost:8009/
        ProxyPassReverse / ajp://localhost:8009/

        <Proxy *>
            AddDefaultCharset off
            Require all granted
            Order allow,deny
            Allow from all
        </Proxy>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

    </VirtualHost>
</IfModule>

/opt/torquebox/torquebox-3.1.2/jboss/standalone/configuration

<subsystem xmlns='urn:jboss:domain:web:1.4' default-virtual-server='default-host' native='false'>
    <connector name='http' protocol='HTTP/1.1' scheme='http' socket-binding='http'/>
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding='ajp' />
    <virtual-server name='default-host'>
        <alias name='localhost'/>
        <alias name='example.com'/>
    </virtual-server>
</subsystem>

Fix permissions when necessary. Running as user 'torquebox' may overcome some of these problems that first butt heads.