jruby-rack 1.1.4 → 1.1.5

data/History.txt

@@ -1,7 +1,21 @@
+== 1.1.5 (04/03/12)
+
+- bundler 1.1 workaround when ENV is cleared - set ENV['PATH'] = ''
+- resolve servlet context from request.getServletContext if posssible
+- resetUnhandledResponse init param for controlling chain response handling
+- filter specific context params deprecated in favor of filter init params
+- logging should not depend on $servlet_context global (better #88 fix)
+- cleanup request buffer /tmp files after input stream gets closed
+- add an embed Config to correctly setup RackConfig from ruby runtime
+- introduce RackConfig#getOut/getErr for possible 1/2 stream redirection
+- ensure ENV changes do not affect the native environment (#101)
+- change Rails.public_path early on (#99) and do not set PUBLIC_ROOT in 3.x
+- synchronize session operations with JavaServletStore (#95)
+- allow configuring request buffer initial/maximum size using parameters
+- initialization exception behavior in listener might be overriden (#16)
+
 == 1.1.4 (02/21/12)
 
-- Thanks to @kares for all the maintenance and quick turnaround on
-  bugs this release!
 - incorrectly interpreted byte in RewindableInputStream causing EOFs (#92)
 - fix JRuby::Rack::Response 1.9 incompatibility due String#each
 - ensure $servlet_context is not nil in embedded scenario (#88)

data/README.md

@@ -1,46 +1,44 @@
 # JRuby-Rack
 
-JRuby-Rack is a lightweight adapter for the Java servlet environment
-that allows any Rack-based application to run unmodified in a Java
-servlet container. JRuby-Rack supports Rails, Merb, as well as any
-Rack-compatible Ruby web framework.
+JRuby-Rack is a lightweight adapter for the Java servlet environment that allows 
+any Rack-based application to run unmodified in a Java servlet container. 
+JRuby-Rack supports Rails as well as any Rack-compatible Ruby web framework.
 
 For more information on Rack, visit http://rack.rubyforge.org.
 
+[![Build Status](https://secure.travis-ci.org/jruby/jruby-rack.png?branch=master)](http://travis-ci.org/jruby/jruby-rack)
+
 # Getting Started
 
-The easiest way to use JRuby-Rack is to get [Warbler][1]. Warbler
-depends on the latest version of JRuby-Rack and ensures it gets placed in
-your WAR file when it gets built.
+The easiest way to use JRuby-Rack is to get [Warbler][1]. 
+Warbler depends on the latest version of JRuby-Rack and ensures it gets placed 
+in your WAR file when it gets built.
 
 If you're assembling your own WAR using other means, you can install the
-`jruby-rack` gem. It provides a method to locate the jruby-rack jar file:
+**jruby-rack** gem. It provides a method to locate the jar file:
 
     require 'fileutils'
     require 'jruby-rack'
     FileUtils.cp JRubyJars.jruby_rack_jar_path, '.'
 
-Otherwise you'll need to download the [latest JRuby-Rack jar][2], drop
-it into the WEB-INF/lib directory and configure the RackFilter in your
-application's web.xml. Example web.xml snippets are as follows.
+Otherwise you'll need to download the [latest jar release][2], drop it into the 
+*WEB-INF/lib* directory and configure the RackFilter in your application's 
+*web.xml*. Example web.xml snippets are as follows.
 
 ## For Rails
 
-Here's sample web.xml configuration for Rails. Note the environment
-and min/max runtime parameters. For multi-threaded Rails with a single
-runtime, set min/max both to 1. Otherwise, define the size of the
-runtime pool as you wish.
+Here's sample web.xml configuration for Rails. Note the environment and min/max 
+runtime parameters. For multi-threaded Rails with a single runtime, set min/max 
+both to 1. Otherwise, define the size of the runtime pool as you wish.
 
     <context-param>
       <param-name>rails.env</param-name>
       <param-value>production</param-value>
     </context-param>
-
     <context-param>
       <param-name>jruby.min.runtimes</param-name>
       <param-value>1</param-value>
     </context-param>
-
     <context-param>
       <param-name>jruby.max.runtimes</param-name>
       <param-value>1</param-value>
@@ -49,6 +47,19 @@ runtime pool as you wish.
     <filter>
       <filter-name>RackFilter</filter-name>
       <filter-class>org.jruby.rack.RackFilter</filter-class>
+      <!-- optional filter configuration init-params : -->
+      <init-param> 
+        <param-name>resetUnhandledResponse</param-name>
+        <param-value>true</param-value> <!-- true (default), false or buffer -->
+      </init-param>
+      <init-param> 
+        <param-name>addsHtmlToPathInfo</param-name>
+        <param-value>true</param-value> <!-- true (default), false -->
+      </init-param>
+      <init-param> 
+        <param-name>verifiesHtmlResource</param-name>
+        <param-value>false</param-value> <!-- true, false (default) -->
+      </init-param>
     </filter>
     <filter-mapping>
       <filter-name>RackFilter</filter-name>
@@ -61,9 +72,9 @@ runtime pool as you wish.
 
 ## For Other Rack Applications
 
-Here's a sample web.xml configuration for a Rack application. The main
-difference is that JRuby-Rack looks for a "rackup" file named
-`config.ru` in `WEB-INF/config.ru` or `WEB-INF/*/config.ru`.
+Here's a sample web.xml configuration for a Rack application. The main difference 
+is that JRuby-Rack looks for a "rackup" file named **config.ru** in 
+`WEB-INF/config.ru` or `WEB-INF/*/config.ru`.
 
     <filter>
       <filter-name>RackFilter</filter-name>
@@ -78,16 +89,17 @@ difference is that JRuby-Rack looks for a "rackup" file named
       <listener-class>org.jruby.rack.RackServletContextListener</listener-class>
     </listener>
 
-If you don't have a config.ru or don't want to include it in your web
-app, you can embed it in web.xml as follows (using Sinatra as an
-example). Be sure to escape angle-brackets for XML!
+If you don't have a config.ru or don't want to include it in your web app, you 
+can embed it in web.xml as follows (using Sinatra as an example). 
+
+Be sure to escape angle-brackets for XML !
 
     <context-param>
       <param-name>rackup</param-name>
       <param-value>
         require 'rubygems'
-        gem 'sinatra', '~&gt; 1.0'
-        require './lib/demo'
+        gem 'sinatra', '~&gt; 1.3'
+        require './lib/app'
         set :run, false
         set :environment, :production
         run Sinatra::Application
@@ -99,124 +111,112 @@ example). Be sure to escape angle-brackets for XML!
 
 ## Servlet Filter
 
-JRuby-Rack's main mode of operation is as a servlet filter. This
-allows requests for static content to pass through and be served by
-the application server. Dynamic requests only happen for URLs that
-don't have a corresponding file, much like many Ruby applications
-expect. The application can also be configured to dispatch through a
-servlet instead of a filter if it suits your environment better.
+JRuby-Rack's main mode of operation is as a servlet filter. This allows requests 
+for static content to pass through and be served by the application server. 
+Dynamic requests only happen for URLs that don't have a corresponding file, much 
+like many Ruby applications expect. 
+The application can also be configured to dispatch through a servlet instead of 
+a filter if it suits your environment better.
 
 ## Servlet environment integration
 
-- Servlet context is accessible to any application both through the
-  global variable $servlet_context and the Rack environment variable
-  java.servlet_context.
+- Servlet context is accessible to any application through the Rack environment 
+  variable *java.servlet_context* as well as the `$servlet_context` global.
 - Servlet request object is available in the Rack environment via the
-  key java.servlet_request.
-- Servlet request attributes are passed through to the Rack
-  environment.
+  key *java.servlet_request*.
+- Servlet request attributes are passed through to the Rack environment.
 - Rack environment variables and headers can be overridden by servlet
   request attributes.
-- Java servlet sessions are available as a session store for both
-  Rails and Merb. Session attributes with String keys and String,
-  numeric, boolean, or java object values are automatically copied to
-  the servlet session for you.
+- Java servlet sessions are available as a session store for Rails. 
+  Session attributes with String keys and String, numeric, boolean, or java 
+  object values are automatically copied to the servlet session for you.
 
 ## Rails
 
 Several aspects of Rails are automatically set up for you.
 
-- The Rails controller setting ActionController::Base.relative_url_root
+- The Rails controller setting `ActionController::Base.relative_url_root`
   is set for you automatically according to the context root where
   your webapp is deployed.
-- Rails logging output is redirected to the application server log.
+- `Rails.logger` output is redirected to the application server log.
 - Page caching and asset directories are configured appropriately.
 
 ## JRuby Runtime Management
 
-JRuby runtime management and pooling is done automatically by the
-framework. In the case of Rails, runtimes are pooled. For Merb and
-other Rack applications, a single runtime is created and shared for
-every request.
+JRuby runtime management and pooling is done automatically by the framework. 
+In the case of Rails, runtimes are pooled. For other Rack applications, 
+currently, a single runtime is created and shared for every request.
 
 ## JRuby-Rack Configuration
 
 JRuby-Rack can be configured by setting these key value pairs either
 as context init parameters in web.xml or as VM-wide system properties.
 
-- `rackup`: Rackup script for configuring how the Rack application is
-  mounted. Required for Rack-based applications other than Rails or
-  Merb. Can be omitted if a `config.ru` is included in the application
-  root.
-- `jruby.min.runtimes`: For non-threadsafe Rails applications using a
-  runtime pool, specify an integer minimum number of runtimes to hold
-  in the pool.
-- `jruby.max.runtimes`: For non-threadsafe Rails applications, an
-  integer maximum number of runtimes to keep in the pool.
-- `jruby.init.serial`: When using runtime pooling, indicate that the
-  runtime pool should be created serially in the foreground rather
-  than spawning background threads. For environments where creating
-  threads is not permitted.
-- `jruby.compat.version`: Set to "1.8" or "1.9" to make JRuby run a
-  specific version of Ruby.
-- `public.root`: Relative path to the location of your application's
-  static assets. Defaults to `/`.
+- `rackup`: Rackup script for configuring how the Rack application is mounted. 
+  Required for Rack-based applications other than Rails. Can be omitted if a 
+  *config.ru* is included in the application root.
+- `jruby.min.runtimes`: For non-threadsafe Rails applications using a runtime 
+  pool, specify an integer minimum number of runtimes to hold in the pool.
+- `jruby.max.runtimes`: For non-threadsafe Rails applications, an integer 
+  maximum number of runtimes to keep in the pool.
+- `jruby.init.serial`: When using runtime pooling, indicate that the runtime 
+  pool should be created serially in the foreground rather than spawning 
+  background threads. For environments where creating threads is not permitted.
+- `jruby.compat.version`: Set to "1.8" or "1.9" to make JRuby run a specific 
+  version of Ruby.
+- `public.root`: Relative path to the location of your application's static 
+  assets. Defaults to */*.
 - `gem.path`: Relative path to the bundled gem repository. Defaults to
-  `/WEB-INF/gems`.
-- `rails.root`, `merb.root`: Root path to the location of the Rails or
-  Merb application files. Defaults to `/WEB-INF`.
-- `rails.env`: Specify the Rails environment to run. Defaults
-  to 'production'.
+  */WEB-INF/gems*.
+- `rails.root`: Root path to the location of the Rails application files. 
+  Defaults to */WEB-INF*.
+- `rails.env`: Specify the Rails environment to run. Defaults to 'production'.
 - `rails.relative_url_append`: Specify a path to be appended to the 
-  ActionController::Base.relative_url_root after the context path. Useful
-  for running a rails app from the same war as an existing app, under
-  a sub-path of the main servlet context root.
-- `merb.environment`: Specify the merb environment to run. Defaults to
-  `production`.
+  `ActionController::Base.relative_url_root` after the context path. Useful
+  for running a rails app from the same war as an existing app, under a 
+  sub-path of the main servlet context root.
 - `jruby.rack.logging`: Specify the logging device to use. Defaults to
   `servlet_context`. See below.
+- `jruby.rack.ignore.env`: Clears out the `ENV` hash in each runtime to insulate 
+  the application from the environment.
 - `jruby.rack.background.spool`: (EXPERIMENTAL) Enable large request
   bodies to be spooled to a tempfile in the background.
-- `jruby.rack.filter.adds.html`: The default behavior for Rails and
-  many other Ruby applications is to add an .html extension to the
-  resource and attempt to handle it before serving a dynamic request
-  on the original URI. However, this behavior may confuse other
-  servlets in your application that have a wildcard mapping. Defaults
-  to true.
-- `jruby.rack.filter.verify.resource.exists`: If
-  `jruby.rack.filter.adds.html` is true, then this setting, when true,
-  adds an additional check using `ServletContext#getResource` to
-  verify that the .html resource exists. Default is false. (Note that
-  apparently some servers may not implement `getResource` in the way
+- `jruby.rack.filter.adds.html`: 
+  **deprecated** use `addsHtmlToPathInfo` filter config init parameter.
+  The default behavior for Rails and many other Ruby applications is to add an 
+  *.html* extension to the resource and attempt to handle it before serving a 
+  dynamic request on the original URI. 
+  However, this behavior may confuse other servlets in your application that 
+  have a wildcard mapping. Defaults to true.
+- `jruby.rack.filter.verify.resource.exists`: 
+  **deprecated** use `verifiesHtmlResource` filter config init parameter.
+  If `jruby.rack.filter.adds.html` is true, then this setting, when true, adds 
+  an additional check using `ServletContext#getResource` to verify that the 
+  *.html* resource exists. Default is false. 
+  (Note that apparently some servers may not implement `getResource` in the way 
   that is expected here, so in that case this setting won't matter.)
-- `jruby.rack.ignore.env`: Clears out the ENV hash in each runtime to
-  insulate the application from the environment.
 
 ## Initialization
 
-There are often cases where you need to perform custom initialization
-of the Ruby environment before booting the application. You can create
-a file called `META-INF/init.rb` or `WEB-INF/init.rb` inside the war
-file for this purpose. These files, if found, will be evaluated before
-booting the Rack environment, allowing you to set environment
-variables, load scripts, etc.
+There are often cases where you need to perform custom initialization of the 
+Ruby environment before booting the application. You can create a file called 
+*META-INF/init.rb* or *WEB-INF/init.rb* inside the war file for this purpose. 
+These files, if found, will be evaluated before booting the Rack environment, 
+allowing you to set environment variables, load scripts, etc.
 
 ## Logging
 
-JRuby-Rack sets up a delegate logger for Rails that sends logging
-output to `javax.servlet.ServletContext#log` by default. If you wish
-to use a different logging system, configure `jruby.rack.logging` as
-follows:
+JRuby-Rack sets up a delegate logger for Rails that sends logging output to 
+`javax.servlet.ServletContext#log` by default. If you wish to use a different 
+logging system, configure `jruby.rack.logging` as follows:
 
-- `servlet_context` (default): Sends log messages to the servlet
-  context.
-- `stdout`: Sends log messages to the standard output stream
-  `System.out`.
+- `servlet_context` (default): Sends log messages to the servlet context.
+- `stdout`: Sends log messages to the standard output stream `System.out`.
 - `commons_logging`: Sends log messages to Apache commons-logging. You
   still need to configure commons-logging with additional details.
 - `slf4j`: Sends log messages to SLF4J. Again, SLF4J configuration is
   left up to you.
-- `log4j`: Sends log messages to log4J. Again, log4J configuration is
+- `log4j`: Sends log messages to log4J. Again, Log4J configuration is
   left up to you.
 
 For those loggers that require a specific named logger, set it in the
@@ -269,10 +269,9 @@ the following:
 ## Rails Step-by-step
 
 This example shows how to create and deploy a simple Rails app using
-the embedded Java database H2 to a WAR using Warble and JRuby Rack.
+the embedded Java database H2 to a WAR using Warbler and JRuby-Rack.
 
-Install Rails and the driver and ActiveRecord adapters for the H2
-database:
+Install Rails and the ActiveRecord adapters + driver for the H2 database:
 
     jruby -S gem install rails activerecord-jdbch2-adapter
 
@@ -301,7 +300,7 @@ Copy this configuration into config/database.yml:
 
 Add the following to your application's Gemfile:
 
-    gem 'activerecord-jdbch2-adapter'
+    gem 'activerecord-jdbch2-adapter', :platform => :jruby
 
 Generate a scaffold for a simple model of blog comments.
 
@@ -311,37 +310,33 @@ Run the database migration that was just created as part of the scaffold.
 
     jruby -S rake db:migrate
 
-Start your application on the Rails default port 3000 using WEBrick
-and make sure it works:
+Start your application on 3000 using WEBrick and make sure it works:
 
     jruby script/rails server
 
-Generate a custom Warbler WAR configuration for the blog application
+Generate a production version of the H2 database for the application:
 
-    jruby -S warble config
+    RAILS_ENV=production jruby -S rake db:migrate
 
-Generate a production version of the H2 database for the blog
-application:
+Generate a custom Warbler WAR configuration for the blog application
 
-    RAILS_ENV=production jruby -S rake db:migrate
+    jruby -S warble config
 
-Edit this file: config/warble.rb and add the following line after
-these comments:
+Edit *config/warble.rb* and add the following line after these comments:
 
     # Additional files/directories to include, above those in config.dirs
     # config.includes = FileList["db"]
     config.includes = FileList["db/production_h2*"]
 
-This will tell Warble to include the just initialized production H2
+This will tell Warbler to include the just initialized production H2
 database in the WAR.
 
 Now generate the WAR file:
 
     jruby -S warble war
 
-This task generates the file: blog.war at the top level of the
-application as well as an exploded version of the war located here:
-tmp/war.
+This task generates the file: blog.war at the top level of the application as 
+well as an exploded version of the war located at *tmp/war*.
 
 The war should be ready to deploy to your Java application server.
 

data/lib/jruby/rack/version.rb

@@ -7,6 +7,6 @@
 
 module JRuby
   module Rack
-    VERSION = "1.1.4"
+    VERSION = "1.1.5"
   end
 end

metadata

@@ -2,7 +2,7 @@
 name: jruby-rack
 version: !ruby/object:Gem::Version 
   prerelease: 
-  version: 1.1.4
+  version: 1.1.5
 platform: ruby
 authors: 
   - Nick Sieger
@@ -10,7 +10,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2012-02-21 00:00:00 Z
+date: 2012-04-03 00:00:00 Z
 dependencies: []
 
 description: JRuby-Rack is a combined Java and Ruby library that adapts the Java Servlet API to Rack. For JRuby only.
@@ -23,11 +23,11 @@ extensions: []
 extra_rdoc_files: []
 
 files: 
-  - History.txt
-  - LICENSE.txt
   - README.md
-  - lib/jruby-rack-1.1.4.jar
+  - LICENSE.txt
+  - History.txt
   - lib/jruby-rack.rb
+  - lib/jruby-rack-1.1.5.jar
   - lib/jruby/rack/version.rb
 homepage: http://jruby.org
 licenses: []