Hi, FileServlet approach was discussed too in the earlier stages of the plugin.
Another approach would be remove FileServlet at all, move all static content to the root of the web app and modify rails rounting accordingly. Thus the servlet container would try to load the file, and fail over to rails if it doesn't. Obviously this would require to change rails application directory scheme, which is why this option was rejected. Fausto On 4/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > (but not a particularly elegant one). > > So as I mentioned before, Mephisto wants to route most requests for > static content through its theming engine. This means that in general > the simple wildcarding of subdirectories under public doesn't work...it > causes all requests for static content to get routed to the file > servlet, when there should actually be a fallback on the Rails servlet > if a file isn't found. > > So obviously the correct fix is that the file servlet and the rails > servlet should be on friendly terms, with the file servlet failing over > to the Rails servlet when a file doesn't exist, and allowing Rails to > handle it. This would be standard Rails behavior, or so it would seem. > > My temporary fix seems to be working "well enough" however, and I am > able to deploy a fully-working Mephisto instance locally. Here's the > change I made in create_war.rb: > > public_dir = File.join(config.staging, 'public') > public_files = [] > public_filelist = Rake::FileList.new(File.join(public_dir, '**/*')) > public_filelist.each do |f| > relative = f[public_dir.length..f.length] > #relative += File::SEPARATOR + '*' if File.directory?(f) > public_files << relative unless File.directory?(f) > end > > Yup, you're reading that right...instead of adding all files under > public directly and all directories as wildcarded paths, this adds all > files under all directories by name to web.xml. That certainly clutters > up the descriptor, but it allows only files that actually exist to be > handled by the file servlet. > > The correct solution would be much nicer, of course, so I'll see if I > can't look into that next. But this workaround functions reasonably well. > > - Charlie > _______________________________________________ > Jruby-extras-devel mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/jruby-extras-devel > _______________________________________________ Jruby-extras-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/jruby-extras-devel
