Trinidad Startup

Hi Guys

I’m having some issue’s getting Trinidad to load my resources

src="/issue_log/javascripts/application.js?1290773728"

The app appears to run fine, my start up is:

trinidad --address 192.168.0.19 -e production -c /issue_log -p 8080
-apps /home/nath/issue_log/

Thanks

Here a tail of the logs

Started GET “/issue_log/javascripts/rails.js?1290790277” for
192.168.24.48 at Mon Nov 29 04:33:42 -0800 2010

ActionController::RoutingError (No route matches
“/javascripts/rails.js”):

You shouldn’t ever see the static assets being served in your rails
logs, i believe trinidad will serve that directly.

What’s your trinidad.yml config look like? Is your app defined as the
root context possibly? This would mean you wouldn’t use the context
path issue_log in the url in your browser

ya you’re using the root context there, In simplified terms, consider
each app within trinidad to be a context. With trinidad if you have
multiple apps, you’d access them like http://localhost:8080/app_1,
http://localhost:8080/app_2 etc… then each request would have the
‘app_x/’ prefix in the url. Since you’re not doing that, everything
should just use root as /

I’m not sure how you’re accessing the app in your browser, but as a
first step you should just go to http://localhost:8080 NOT
http://localhost:8080/issue_log

Can you also post the actual code you’re using to load up the
javascript? NOT the generated html script tag, but the rails command
you’re using

Here is a copy of my yml

Thanks
Nathan

address: localhost
port: 3000 # port where trinidad is running

environment: production # environment for rails applications
jruby_min_runtimes: 1 # min number of runtimes
jruby_max_runtimes: 1 # max number of runtimes
libs_dir: lib # directory where libraries packed as jars can be
found
classes_dir: classes # directory where other java classes can be
found
default_web_xml: config/web.xml # if you are using a custom web.xml
context_path: / # default context path
web_app_dir: /home/nath/issue_log # system path where the
application is located, by default is PWD
rackup: config.ru # rackup script if you are running a non rails
application
public: public # system path where your public files are located
log: log level

Thanks Brad,

Im accessing the site from http://192.168.0.19:3001/

(i have something else currently running on 3000, so I’ve change the
config to reflect)

Im just using the standard rails helpers
<%= stylesheet_link_tag “style”,“application” %>
<%= javascript_include_tag :defaults %>

which generate something like
/javascripts/application.js?1290773728

In my first post I did use a context of /issue_log but to simplify
things I changed to the root.

Thanks
Nathan

Hi Nathan,

I think you are overloading your configuration options and something
it’s
not been loaded properly.

What I’d do is start with the simplest configuration, I mean no
configuration at all, go to the application directory and run ‘jruby -S
trinidad’ and see what happen. If this work think carefully about what
you
need and add it to the configuration file.

For what I see in your file I think you just need to change the port and
the
jruby runtimes if your are running the application in threadsafe mode.


port: 8080
jruby_min_runtimes: 1
jruby_max_runtimes: 1

Other options in the file are the default ones, I rather keep it clean
and
add just what I need.

I’m starting thinking of rewrite this part of the configuration section
because perhaps it’s not as clear as it should. Any help is welcome.

Cheers

Hi David,

Thanks for you continued help

Okay so running trinidad without any configuration

generates links to resources //stylesheets/style.css?1291037787

Thanks again

Nathan

Just as a quick followup, I created a brand new rails app;

$ rails new trinitest
$ cd trinitest/
$ bundle install
$ rails generate scaffolding test name:string
$ rake db:migrate
$ jruby -S trinidad

trinidad (1.0.2)
trinidad_jars (0.3.3)
rails (3.0.3)

When I visited http://localhost:3000/tests, the default javascript and
stylesheets had the leading double slashes.

I think Trinidad is appending the web context to the links, so when
using the root context, you get that extra slash. If I feed it a
context, things work as expected:

$ jruby -S trinidad --context /webapp


Chris

Hi Chris,

seems it’s easy to reproduce, please could you file a bug so I can track
it?

https://github.com/calavera/trinidad/issues/

Btw, this is a good chance if you want to contribute, look for the
context_path configuration in server.rb and web_app.rb, it should be
easy to
bump into :slight_smile:

Cheers

On Tue, Dec 7, 2010 at 2:43 PM, David C.
[email protected] wrote:

Btw, this is a good chance if you want to contribute, look for the
context_path configuration in server.rb and web_app.rb, it should be easy to
bump into :slight_smile:

server.rb line 9:

  •     :context_path => '/',
    
  •    :context_path => '',
    

Tomcat’s default/ROOT context path is an empty string, not “/”.

Totally untested, though :slight_smile:


Hassan S. ------------------------ [email protected]
twitter: @hassan

I’m getting this same issue. Rails 3.0.3, latest version of trinidad.
I’m running from the root of my webapp using ‘jruby -S trinidad.’
When I use the Asset tag helpers, like so:

<%= stylesheet_link_tag ‘/stylesheets/site’ %>
<%= stylesheet_link_tag ‘site’ %>
<%= stylesheet_link_tag ‘/stylesheets/site.css’ %>

Trinidad is showing double slashes at the front of the URLs, causing
the browsers not to load the assets. If I run 'rails server" from teh
same directory, it works as expected.

Chris

On Mon, Nov 29, 2010 at 10:53 AM, Nathan Willoughby

Hi,

I’ve released Trinidad 1.0.3 that fixes the problem.

Cheers

Actually, my initial tests are showing it at command_line_parser.rb,
line 16:

     - :context_path => '/',
     + :context_path => '',

It looks as though the default command line options override the
default server.rb options, though I don’t know how this affects it if
you are loading from a yaml config file. I’ll file a ticket and play
around with it more. Possibly both need to be changed.

The good news is that these changes did seem to fix the problem, at
least in my quick tests.


Chris

On Tue, Dec 7, 2010 at 7:19 PM, Hassan S.