Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[to-do] towards **1.2** #168

Open
9 of 34 tasks
kares opened this issue Feb 25, 2014 · 6 comments
Open
9 of 34 tasks

[to-do] towards **1.2** #168

kares opened this issue Feb 25, 2014 · 6 comments
Labels
Milestone

Comments

@kares
Copy link
Member

kares commented Feb 25, 2014

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
    • native JRuby::Rack::Response
    • native JRuby::Rack::Logger
    • native Rack::Handler
  • compile against Java 1.6 (likely only JRuby 1.7 will be supported)
  • 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 ?
  • map logger levels 1-to-1
  • 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
  • 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
  • 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
Copy link

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
Copy link
Member Author

kares commented Aug 9, 2017

@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
Copy link

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
Copy link
Member Author

kares commented Aug 9, 2017

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
Copy link

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
Copy link
Member Author

kares commented Aug 10, 2017

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 ...

@headius headius modified the milestones: 1.2.0, 1.2.1 May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants