[cgiapp] Problem with Flash, Session & persistent environment identified

[Bradley C Bailey]

Richard,

> If Ron can make a working demo with CAP::Flash :) ..
> 
> Starting out with the bare minimum (no login, no authentication, direct 
> use of $dbh, etc), I get the flash messages displaying under mod_cgi, 
> but not under CA::Server unless I session->flush in teardown.
> 
> use base qw(Titanium);
> use CGI::Application::Plugin::TT;
> use CGI::Application::Plugin::Flash;
> 
> Startmode() sets some flash messages then re-directs to function1() to 
> display the template.
> 
> Removing Titanium and substituting CGI::Application as the superclass 
> was the key to getting the flash messages displayed under CA::Server 
> without needing session->flush. Yay!!

I am able to reproduce this as well.  I had my test application working, 
and I switched it to Titanium instead of CGI::Application and my 
sessions stopped working automatically flushing (not going out of scope).


> Then, bringing back all the plugins that Titanium uses one by one until 
> it broke again, CAP::ErrorPage is the one responsible. Presumably there 
> is something in there that causes the session to be retained in a 
> persistent env?
> 
> It's possible that one of the Titanium mods is also causing the failure 
> of AutoRunmode to work under mod_perl for me, but that's another issue.

I can confirm CAP::ErrorPage is what is causing this behavior.  Though I 
couldn't reproduce my problems with CAP::DebugScreen.

In CAP::ErrorPage:

sub add_page_not_found_rm {
     my $c = shift;

      my %rms = $c->run_modes;

      unless( exists $rms{'AUTOLOAD'}) {
          $c->run_modes(
              AUTOLOAD => sub {
                  return $c->error(
                      title => 'The requested page was not found.',
                      msg => "(The page tried was: 
".$c->get_current_runmode.")"
                  )
          });
      }
}


In the AUTOLOAD sub I think it is making a circular reference to the 
CGIApp object ($c) since the sub creates a closure which is stored 
inside of $c for the runmodes.

If inside that sub reference I add 'my $c = shift;' first the problem 
goes away, but I am not sure if that breaks the plugin at all since I do 
not use it.

Can anyone else reproduce this problem?

I can submit a bug report and/or patch.

Regards,
Bradley C Bailey