__PACKAGE__->mk_classdata($_)
for qw/components arguments dispatcher engine log dispatcher_class
engine_loader context_class request_class response_class stats_class
- setup_finished _psgi_app/;
+ setup_finished _psgi_app loading_psgi_file/;
__PACKAGE__->dispatcher_class('Catalyst::Dispatcher');
__PACKAGE__->request_class('Catalyst::Request');
}),
);
+ # Don't really setup_engine -- see _setup_psgi_app for explanation.
+ return if $class->loading_psgi_file;
+
my $engine = $class->engine_class;
Class::MOP::load_class($engine);
);
next unless -e $psgi_file;
+
+ # If $psgi_file calls ->setup_engine, it's doing so to load
+ # Catalyst::Engine::PSGI. But if it does that, we're only going to
+ # throw away the loaded PSGI-app and load the 5.9 Catalyst::Engine
+ # anyway. So set a flag (ick) that tells setup_engine not to populate
+ # $c->engine or do any other things we might regret.
+
+ $app->loading_psgi_file(1);
my $psgi_app = Plack::Util::load_psgi($psgi_file);
+ $app->loading_psgi_file(0);
return $psgi_app
unless $app->engine_loader->needs_psgi_engine_compat_hack;
- # load_psgi ran a .psgi file doing ->setup_engine('PSGI'). That's what
- # .psgi files generated by the old Engine::PSGI do. Those return an app
- # coderef calling into MyApp->run, which doesn't work anymore, so we're
- # just ignoring it and use the wrapped legacy psgi app
-
- $app->engine(undef);
- $app->setup_engine;
-
- # ^^ We need to do this because even though we are discarded $psgi_app, the
- # fact that it was loaded above means that Catalyst Engine now has the
- # wrong value (PSGI), which persists due to the singleton nature of all
- # this stuff. This solution is probably a lame hack but did work for all
- # the cases we know about. Hopefully we can pull out this crap soon
- # Please note that if the fact that the psgi file was loaded started to set
- # values in areas outside Engine this hack will probably fail.
-
warn <<"EOW";
Found a legacy Catalyst::Engine::PSGI .psgi file at ${psgi_file}.