Issues with Warbler and plugins that make assumptions about structure of Rails app. (e.g ActiveScaff

Ruby JRuby
1

Yesterday, I attempted to deploy a Rails application that used
ActiveScaffold (hereafter referred to as AS) with Warbler into a JEE
container.

I ran into a few issues that have to do with the fact that AS and
another plugin that are assuming a standard Rails application structure.

All of the required files appear to be in the deployed app, under /
instead of /public of course.

But for example, in the AS CSS, there are relative references like this:

background: url(…/…/…/images/active_scaffold/default/cross.png) 0 0
no-repeat;

which definitely do not resolve correctly in the deployed app.

Also, both AS and another plugin have install.rb code that assumes the
presence of the /public directory. In the case of AS, I had to include
“public” in the config.dirs directive just to get the app. to start
because it was running this AS code to copy to a directory named
“public”.

In general, it appears that when Warbler is combined with plugins that
hardcode the “public” in certain file access code (or even just assume
it per the CSS example above), that some static files will not be able
to be accessed due to the forced relocation of the contents of “public”
to “/” in the deployed app.

In the AS case, there are some workarounds involving the
Rails.public_path variable and then a patch that takes advantage of
that.

But it appears that this will always be an issue. Whenever one pulls in
a plugin, one needs to evaluate whether it is assuming the standard
Rails directory structure and then if the plugin does so assume, patch
appropriately so that it will work in Warbler.

I can’t see a way around this.

Any thoughts?

Wes

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

On Thu, Aug 21, 2008 at 3:12 PM, Wes G. [email protected] wrote:

But for example, in the AS CSS, there are relative references like this:
hardcode the “public” in certain file access code (or even just assume it
appropriately so that it will work in Warbler.

I can’t see a way around this.

Any thoughts?

  1. Fork AS and make the necessary changes and maintain that, and maybe
    hope they get merged back
  2. Re-jigger the way Warbler generates a war. This is already possible
    to some extent by messing with pathmaps (see 1) but there’d also
    have to be a way to serve up the static files that might require
    changes to jruby-rack.

/Nick

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Nick S. wrote:

of /public of course.

plugin, one needs to evaluate whether it is assuming the standard Rails

  1. Re-jigger the way Warbler generates a war. This is already possible
    to some extent by messing with pathmaps (see 1) but there’d also
    have to be a way to serve up the static files that might require
    changes to jruby-rack.

I am convinced that there is a way to handle this with what exists. I’m
currently going down this path:

I’ve added “public” to the config.dirs list so I get everything in
public and below under WEB-INF.

I think if I set the public.root to be “WEB-INF/public/…” or something
very close to that, I can get it to work. But I haven’t yet :).

Now, that’s a bit of hack, since we’ve gone to the trouble to copy the
static resources to /, but then just ignore them via public.root being
set to something else, but I figure, refinement can come later.

Wes

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
4

Wes G. wrote:

I’ve added “public” to the config.dirs list so I get everything in
public and below under WEB-INF.

I think if I set the public.root to be “WEB-INF/public/…” or something
very close to that, I can get it to work. But I haven’t yet :).

the real problem is the lack of something that do reference to the
public path in Rails before 2.1. several plugins assume that public dir
will be

File.join(RAILS_ROOT, “public”)

Warbler first, and Rails 2.1 now assume that u can change the public dir
location and reference cleanly (Rails.public_path). This is great!, now
we need that the plugins authors begin to use this.

ActiveScaffold 1.2 will be Rails 2.1 only, unfortunely the lead
developers appear to have to much work to consider patches for this
situations (Rails 2.1 broke AS to a great level because AS did use
several tricks that now are avoided, and much work has to be done)

exist at least two AS forks in github for use Rails.public_path (i did
drop mine after this ones, more polished) i prefer:

that are using Rails.public_path and Rails.root instead of the old way

is only a matter of time that this patch will go upstream to AS, this is
the plugin that i use for production in two apps under jruby (inside
glassfish v2)

–
Black Hand

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
5

Hi,

if you guys start hacking how JRuby-Rack and Warbler deal with Rails
static files, you might also consider that current bug
http://jira.codehaus.org/browse/JRUBY-2832 when trying to serve static
files that collides partially with dynamic requests paths, especially
when serving static pages caches. That would be nice to have a
solution that improve all that or at least don’t make serving caches
even harder.

Regards,

Raphaël Valyi.

On Fri, Aug 22, 2008 at 12:05 AM, BlackHand
[email protected] wrote:

–
Black Hand

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
6

BlackHand wrote:

drop mine after this ones, more polished) i prefer:
Black Hand

I read that entire post and I see what you did and how it should work,
and it makes sense to me. What I seem to be seeing is similar, yet
different. I am able to get all of the active scaffold functionality to
work but none of the little images show up (close button, arrows,
etc.). You have not seen this problem in any of your Glassfish deployed
apps.? It would seem to me that this problem should exist regardless of
JEE container.

Wes

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
7

Raphaël Valyi wrote:

Hi,

if you guys start hacking how JRuby-Rack and Warbler deal with Rails
static files, you might also consider that current bug
http://jira.codehaus.org/browse/JRUBY-2832 when trying to serve static
files that collides partially with dynamic requests paths, especially
when serving static pages caches. That would be nice to have a
solution that improve all that or at least don’t make serving caches
even harder.

I’ll take a quick look at it and see if I can make any sense of it.

But I think for now, I’ll have to go back to Goldspike for Rails, and
use Warbler exclusively for Merb/Rack where the app. doesn’t have any
non-trivial plugin dependencies. I’ve run out of time to mess with
this.

Wes

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
8

By the way, don’t get me wrong, serving static files with Warbler in
general can be done. It’s just that it’s not immediate and you have to
hack in the way I explained in the bug report. May be I get a chance
to spend a little more time on that issue later on and see if I don’t
come with an easier solution, like for instance sugessting an other
default web.xml servlet or some other hack that could prevent
automatic redirects without even hitting the JRuby Rack servlet
filter.

Raphaël Valyi.

On Fri, Aug 22, 2008 at 12:39 AM, Wes G. [email protected] wrote:

even harder.
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email