basic support for delayed writes/async with docs
[catagits/Catalyst-Runtime.git] / lib / Catalyst / Upgrading.pod
index 510b61d..1807053 100644 (file)
@@ -2,6 +2,44 @@
 
 Catalyst::Upgrading - Instructions for upgrading to the latest Catalyst
 
+=head1 Upgrading to Catalyst 5.90040
+
+This version of L<Catalyst> offers some support for using L<AnyEvent> and
+L<IO::Async> event loops in your application.  In order to achieve this goal
+we needed to make some changes to the way the we finalize the HTTP response
+such that sloppy code that closed over $c and leaked memory will no longer
+work in some manner.  For example you might accidently have:
+
+    $c->stash(my_model => sub { $c->model->find(shift) });
+
+If you have old code that leaks memory in this way but otherwise seemed to
+work, it will no longer complete the response properly.
+
+If you don't want to fix your code, you can force the old behavior with the
+global configuration key C<aggressively_close_writer_on_finalize_body>.  This
+of course will still leave you with a leaky application and you lose the new
+event loop support, but your application will go back to completing its
+response output.  For example:
+
+    package MyApp::Web;
+
+    use Moose;
+    use Catalyst;
+
+    __PACKAGE__->config(
+      name => 'MyApp::Web',
+      enable_catalyst_header => 1,
+      disable_component_resolution_regex_fallback => 1,
+      aggressively_close_writer_on_finalize_body => 1,
+    );
+
+    __PACKAGE__->setup;
+
+See L<Catalyst::Component::ContextClosure> for help on how to close over the
+context safely, should you need to do this.  See L<CatalystX::LeakChecker>
+and L<Catalyst::Controller::LeakTracker> for help if you want to solve your
+memory leak issues.
+
 =head1 Upgrading to Catalyst 5.9
 
 The major change is that L<Plack>, a toolkit for using the L<PSGI>
@@ -65,7 +103,7 @@ script is upgraded to use L<Catalyst::Script::HTTP>.
 If you were using L<Catalyst::Engine::CGI> there is no upgrade needed if your
 myapp_cgi.pl script is already upgraded to use L<Catalyst::Script::CGI>.
 
-=head2 Upgrading the Preforking Engine
+=head2 Upgrading Catalyst::Engine::HTTP::Prefork
 
 If you were using L<Catalyst::Engine::HTTP::Prefork> then L<Starman>
 is automatically loaded. You should (at least) change your C<Makefile.PL>
@@ -156,6 +194,10 @@ any tests run via L<Catalyst::Test> will not be compatible with the new
 release, and will result in the development server starting, rather than
 the expected test running.
 
+B<NOTE:> If you are directly accessing C<< $c->req->env >> to get the PSGI
+environment then this accessor is moved to C<< $c->engine->env >>,
+you will need to update your code.
+
 =head2 Engines which are known to be broken
 
 The following engines B<DO NOT> work as of Catalyst version 5.9. The
@@ -210,6 +252,15 @@ This behavior has been removed, and now a 500 response will be returned
 to the test. This change standardizes behavior, so that local test
 requests behave similarly to remote requests.
 
+=head2 Regex dispatch type is deprecated.
+
+The Regex dispatchtype (L<Catalyst::DispatchType::Regex>) has been deprecated.
+
+You are encouraged to move your application to Chained dispatch (L<Catalyst::DispatchType::Chained>).
+
+If you cannot do so, please add a dependency to Catalyst::DispatchType::Regex to your application's
+Makefile.PL
+
 =head1 Upgrading to Catalyst 5.80
 
 Most applications and plugins should run unaltered on Catalyst 5.80.
@@ -219,7 +270,7 @@ been made which could cause incompatibilities. If your application or plugin
 is using deprecated code, or relying on side effects, then you could have
 issues upgrading to this release.
 
-Most issues found with pre-existing components have been easy to
+Most issues found with existing components have been easy to
 solve. This document provides a complete description of behavior changes
 which may cause compatibility issues, and of new Catalyst warnings which
 might be unclear.
@@ -277,7 +328,7 @@ replaces L<NEXT> with L<Class::C3::Adopt::NEXT>, forcing all components
 to resolve methods using C3, rather than the unpredictable dispatch
 order of L<NEXT>.
 
-This issue is characterised by your application failing to start due to an
+This issue manifests itself by your application failing to start due to an
 error message about having a non-linear @ISA.
 
 The Catalyst plugin most often causing this is
@@ -484,7 +535,7 @@ The following test demonstrates the problem:
     use Test::More;
     isnt(BaseClass->can('foo'), Child->can('foo'));
 
-=head2 Extending Catalyst::Request or other classes in an ad-hoc manner using mk_accessors
+=head2 Extending Catalyst::Request or other classes in an ad hoc manner using mk_accessors
 
 Previously, it was possible to add additional accessors to Catalyst::Request
 (or other classes) by calling the mk_accessors class method.
@@ -511,6 +562,13 @@ The correct fix is to re-arrange your class's inheritance hierarchy so that the
 COMPONENT method you would like to inherit is the first (left-hand most)
 COMPONENT method in your @ISA.
 
+=head2 Development server relying on environment variables
+
+Previously, the development server would allow propagation of system
+environment variables into the request environment, this has changed with the
+adoption of Plack. You can use L<Plack::Middleware::ForceEnv> to achieve the
+same effect.
+
 =head1 WARNINGS
 
 =head2 Actions in your application class