[to-do] towards **1.2**

[kares]

JRuby-Rack 1.2 is aimed as a cleanup release which might break some binary compatibility with 1.1.x when its worth (a badly designed API or due performance reasons). This should only affect users even when they explicitly depend on JRuby-Rack APIs - the very most users won't be affected at all.

No one seems to be working towards 1.2 much currently. If you're interested in seeing some of these enhancements/features/performance work get in touch or show some support at BountySource

• [ ] performance improvements by going native with crucial .rb parts
  • [x] native JRuby::Rack::Response
  • [x] native JRuby::Rack::Logger
  • [x] native Rack::Handler
• [x] compile against Java 1.6 (likely only JRuby 1.7 will be supported)
• [x] update/compile against Servlet 3.0 (JavaEE 6) at minimum
• [ ] ~~refactor project build - use Mavenfile / JBundler~~
• [ ] when no runtimes specified - default to using a shared one (for all)
• [ ] verify precompiled assets serving (e.g. with Trinidad)
• [ ] support for servlet/filter auto-configuration on JEE 6 scanning ?
• [x] map logger levels 1-to-1
• [x] thread-safe logger.silence by default (with default JRuby::Rack.logger) !
• [ ] support env['rack.errors']
• [ ] support (default) env['rack.session'] for all (not just Rails)
  • consider changing session_options to a frozen Hash @env['rack.session.options'] ||= {}
• [ ] do not read body ... warn on rewind by default (review usage in Rack/Rails middleware)
• [ ] alternatives to rack's multi-part (needs rewind and uses temp files for >=128k)
• [ ] default to using the ServletEnv for Rack::Handler::Servlet (if avoids rewind) ?
• [ ] servlet_env file-upload detection ?! ... clearly rack file upload is bloated by using memory.
• [ ] better embedding API - org.jruby.rack.embed seems rather confusing (and not that usable)
• [ ] make the listener optional and use the same one for rack as well as rails apps
• [ ] improve ErrorApp (HTTP_ACCEPT detection, support for serving 503.json)
• [ ] remove deprecated files e.g. jruby/rack/errors
• [x] remove (old) Merb support
• [ ] review booter support setting jruby.rack.booter = :rails to force ?
• [ ] possibly release booter, could RailsBooter.to_app calls be avoided ?
• [ ] RailsBooter - default to Rails 3/4 - detect 2.3 specifics instead of the other way around
• [x] cleanup old Bundler "ext" + polluted_with_anyio? check in Rack::Response
• [ ] verify Rack::Response send_file extensions are working - include TC support?
• [ ] setup Java/Ruby documentation
• [ ] introduce Websockets support
• [ ] handle ActionController::Live streaming
• [ ] implement Rack::Async-chronous processing
• [ ] review Rails/Sinatra example
• [ ] ~~try out app-engine once again with an example~~

[JasonLunn]

Would it be possible to get a release based off of master? In particular, the map logger levels 1-to-1 feature would really be helpful.

[kares]

@JasonLunn unfortunately its not release ready - quite far from it. that one features might be semi-complete ... although only on my fork. am also thinking about forms of monetization for the extended features since obviously there's little help and I can not manage support after a release on my own. in the end it might never get completed - it is what it is for now, take it or use a Java logger library with some Ruby sugar.

[JasonLunn]

I tried to drop a locally built 1.2 gem into a fresh proof-of-concept app but I got the error below:

SEVERE: javax.servlet.ServletContext log: error app failed to handle exception: org.jruby.exceptions.RaiseException: (ArgumentError) wrong number of arguments calling `info` (0 for 1)
org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `bytesize' for Rack::Utils:Module
	at RUBY.call(uri:classloader:/jruby/rack/error_app/show_status.rb:30)
	at org.jruby.rack.ext.Servlet.call(org/jruby/rack/ext/Servlet.java:83)

[kares]

as I said its likely quite broken, you're on your own here - the ext parts are a WiP. might drop a pre-release in a week or two.

[JasonLunn]

What's your process for debugging this gem? I would take a stab at producing a backport of logger-level mapping, but I don't know of a way to attach a ruby debugger to a running Tomcat process.

[kares]

sorry but I do not thing its such a good idea (for 1.1) since it's a noticeable back-wards incompatible change. e.g. users will experience "disappearing" logs unless they configure the native backend appropriately (which in some cases with certain servers and setup might not be an option). would need additional work to be a opt-in feature. as I said you're pretty much on your own here. feel free to get in touch privately if its quite crucial for you guys - we could figure smt out on the clock. my 'free' oss support slot is pretty much 'vacant' :) I am only going to spent time on this on the way I like to ...