i had some similar strangeness a while back, also related to
redirecting, and i ended up tracing it way down inside the mason
internals to the module that all of the errors inherit from
(HTML::Mason::Exceptions i think).
anyway, i think i got stuck at that level, because i wasn't sure exactly
how things worked in that particular module. but as Dave suggested, i
was able to extract the basics into a script. this accomplished two
major things, it allowed me to easily use perl with the -I flag to
include copies of the suspect modules somewhere other than my main perl
branch, and it helped me to narrow down the code to just what was
necessary to reproduce the situation. here is the form of the basic
script i used:
#!/usr/bin/perl
use HTML::Mason;
use strict;
my $outbuf;
my $interp = HTML::Mason::Interp->new
(comp_root => '/tmp',
data_dir => '/tmp/mason_data',
out_method => \$outbuf
);
my $retval=$interp->exec('/redirect.html');
print $outbuf, "\n";
print $retval, "\n";
# Do something with $outbuf
then for redirect.html
<%init>
########################################
## offending code using other modules ##
########################################
#$m->abort(302);
#$m->clear_buffer;
#$r->method('GET');
#$r->headers_in->unset('Content-length');
#$r->err_header_out( Location => "http://google.com"; );
$m->clear_buffer;
HTML::Mason::Exception::Abort->throw( error => 'Request->abort was
called', aborted_value => 302 );
$m->out( "HERE" );
die;
</%init>
<%flags>
inherit => ''
</%flags>
it's kind of hazy, but if i remember correctly, when i included certain
sections of the offending perl code, the $m->abort() would definitely
fail, as would an other abort() attempts as well as a plain old die. and
anything content that would have been produced after the failed abort()
would be swallowed also. from this i concluded that the abort() wasn't
simply failing, but that some underlying methods were being mangled in
ways that mason wasn't happy with.
Dave Rolsky wrote:
> On Mon, 14 May 2007, Charlie Katz wrote:
>
>> On Monday 14 May 2007 2:21 pm, Dave Rolsky wrote:
>>> What versions of Exception::Class and Devel::StackTrace do you have
>>> installed? Newer versions of Devel::StackTrace explicitly try to avoid
>>> using overloaded stringification because of problems like this.
>> Exception::Class 1.23
>> Devel::StackTrace 1.13
>>
>> So Exception::Class is up to date, but Devel::StackTrace is at 1.15 now. Do
>> you think 1.13 is old enough that I should upgrade?
>
> The changes to avoid overloaded stringification were introduced much
> earlier than 1.13.
>
> Devel::StackTrace can be forced to respect stringication overloading, but
> that's not the default, so I'm not sure why you're seeing this particular
> problem.
>
> Can you come up with a simple example outside of Mason?
>
>
> -dave
>
> /*===================================================
> VegGuide.Org www.BookIRead.com
> Your guide to all that's veg. My book blog
> ===================================================*/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mason-users mailing list
> Mason-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mason-users
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
