Today we released v5.90053, the latest stable Catalyst. This release fixes a regression caused by the previous release that in some cases would cause trouble installing plugins that need access to the logger.
We also clarified how log configuration interacts with the general phases of Catalyst setup and added some documentation and workarounds in Catalyst::Delta for people that are trying to use the ConfigLoader plugin to configure a custom logger differently based on %ENV. There's a lot of weirdness in how the ConfigLoader plugin works, and it causes a lot of hair pulling since it is a plugin and gets installed during the 'setup_plugins' phase. There's a couple of options, ranging from 'doing something else' to hacking a special case where if this plugin is seen it gets installed ASAP. Thoughts and discussion welcomed. Since this fixes a regression I consider it a required update. At some point we will remove 5.90052 from CPAN since its broken. As a result, we've also released the next development version of Catalyst, 5.90059_002 which contains the regression fix (the 001 release has the regression). This way people that want to test the development revisions of Catalyst can do so without having trouble with that regression. This new development revision of Runner contains deeper changes to how the we connect Catalyst to PSGI, here's the full change log: 5.90059_002 - 2013-12-21 - We now pass a scalar or filehandle directly to you Plack handler, rather than always use the streaming interface (we are still always using a delayed response callback). This means that you can make use of Plack middleware like Plack::Middleware::XSendfile and we expect better use of server features (when they exist) like correct use of chunked encoding or properly non blocking streaming when running under a supporting server like Twiggy. See Catalyst::Delta for more. This change might cause issues if you are making heaving use of streaming (although in general we expect things to work much better. - In the case when we remove a content body from the response because you set an information status or a no content type status, warn that we are doing so when in debug mode. You might see additional debugging information to help you find and remove unneeded response bodies. - Updated the code where Catalyst tries to guess a content length when you fail to provide one. This should cause less issues when trying to guess the length of a funky filehandle. This now uses Plack::Middleware::ContentLength - Removed custom code to remove body content when the request is HEAD and swapped it for Plack::Middleware::Head - Merged fix for regressions from stable.. So in addition to those deeper changes to better support streaming cases, we are starting to migrate custom Catalyst code to available Plack::Middleware. Right now that middleware is basically hard coded into the application, but we expect later releases to offer more control (perhaps something similar to the Rails MiddlewareStack). On thing that has come up is ambiguity about the case when an application is calling $response->write to custom stream a response, but later sets a $response->body anyway. Right now we allow this but it would greatly simplify the code if we didn't (and right now its somewhat incorrect, in that we are forced to let Catalyst stream any file handles sent to the body.) If anyone is using $res->write and needs to set the ->body later please let me know. I see some use cases for this but not many :) Both new stable and new development should be on CPAN by the time you see this! jnap _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
