Re: [Catalyst] Problems upgrading .psgi file (Warning "You are running Catalyst::Engine::PSGI, which is considered a legacy engine for, this version of Catalyst." -> Error "response must be an array r
On 05/03/2012 12:04 PM, Tomas Doran wrote: >> I'm using Catalyst 5.90011. What's wrong here? Isn't mod_psgi working >> anymore? Is mod_psgi still the way to go with apache and catalyst? Did I >> read "Catalyst::Runtime" correctly? > > Catalyst uses the psgi.streaming interface, and mod_psgi doesn't support this. > > Try adding Plack::Middleware::BufferedStreaming to make your responses > unbuffered? Thanks for the answer. I've helped myself and I'm using now mod_perl with PSGI and this worked right out of box. Case closed. -- So long... Erik ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Problems upgrading .psgi file (Warning "You are running Catalyst::Engine::PSGI, which is considered a legacy engine for, this version of Catalyst." -> Error "response must be an array refe
I'm using Catalyst with the mod_psgi (lastest version from https://github.com/spiritloose/mod_psgi/) with my version of an .psgi file. Recently I got this warning during the startup of my apache: (removed timestamps for a better readability) [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [notice] Digest: generating secret for digest authentication ... [notice] Digest: done You are running Catalyst::Engine::PSGI, which is considered a legacy engine for this version of Catalyst. We will continue running and use your existing psgi file, but it is recommended to perform the trivial upgrade process, which will leave you with less code and a forward path. You are running Catalyst::Engine::PSGI, which is considered a legacy engine for this version of Catalyst. We will continue running and use your existing psgi file, but it is recommended to perform the trivial upgrade process, which will leave you with less code and a forward path. Please review Catalyst::Upgrading Subroutine Catalyst::Request::env redefined at /var/lib/catalyst/lib/perl5/site_perl/5.8.8/Catalyst/Engine/PSGI.pm line 13, line 998. [notice] Apache configured -- resuming normal operations env as a writer is deprecated, you probably need to upgrade Catalyst::Engine::PSGI at /var/lib/catalyst/lib/perl5/site_perl/5.8.8/Catalyst/Engine.pm line 29, line 998. [...] No problem, after reading "Catalyst::Runtime" I modified my well.psgi #!/usr/bin/env perl use strict; use warnings; use Plack::Builder; use Well; my $app = Well->psgi_app(@_); $app; After doing that I only got the following error in my logfiles: [error] response must be an array reference This error message comes from the source of mod_psgi. The content after the restart with the modified .psgi file is a "500 Internal Server Error" error page from every request. I'm using Catalyst 5.90011. What's wrong here? Isn't mod_psgi working anymore? Is mod_psgi still the way to go with apache and catalyst? Did I read "Catalyst::Runtime" correctly? Thanks for your help and work. -- So long... Erik ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Stand-alone Scripts
On 04/27/2012 03:25 PM, Glen Diener wrote:
> my $schema = DealerDemoSite::Schema::DemoDB->connect($connect_info_args);
>
> my $demo = $schema->resultset('DemoDB::DddDemo')->find({demoid => 30024});
>
> I'm getting the following error message:
>
> DBIx::Class::Schema::resultset(): Can't find source for DemoDB::DddDemo at
> ./maint.pl line 28
Try this:
my $demo = $schema->resultset('DddDemo')->find({demoid => 30024});
--
So long... Erik
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Session duplicate key constraints on concurrent requests
On Friday 07 October 2011 14:48:14 Tobias Kremer wrote: > I've written about this issue a couple of times in the past and it > seems that this still hasn't been fixed. Here's what's happening: > > 1. Request A comes in with an expired session cookie, C::P::Session > tries to find the session for the given cookie but finds nothing. > 2. Meanwhile, Request B comes in, also trying to find the session for > the same(!) cookie and goes away with empty hands as well. > 3. Both requests try to insert a new session, one succeeds, the other > dies(!) with a duplicate key constraint error from MySQL. How will the session key calculated? Any idea? Randomly? So two random processes will calculate the same session value? -- So long... Erik ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] URI->new() with utf8 string and Unicode::Encoding will not work (but URI->new() with utf8 octets will work)
On 03/04/2011 08:26 AM, Eisenberger Tamás wrote: > So Erik, can you please review your test, or explain a real word > situation of the problem you facing? I was trying to add some utf8 tests to my controller and calling the running catalyst instance from the command line was okay but calling it via test was not okay. I was wondering about about the differences between the two cases because the used string was the same so I've expected the same result. 2 Things will fix this: 1) Understand the issue (string with utf8 flag on/off) 2) Use Encode::encode() in your .t files I don't know how real world this is. B-) -- So long... Fuzz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] URI->new() with utf8 string and Unicode::Encoding will not work (but URI->new() with utf8 octets will work)
Hello list,
I'm was looking for some unicode/utf8/encoding problem during my problem
and I've discovered a strange thing.
URLs provided with an unicode character will be not correctly encoded by
the Unicode::Encoding plugin.
Here's the simple test case:
1) Create the application and cd into it:
% catalyst.pl MyApp
% cd MyApp
2) Add the plugin Unicode::Encoding in lib/MyApp.pm
3) Replace the 'sub index { ...}' in 'lib/MyApp/Controller/Root.pm' with
the following code:
- B< -
sub index : Regex('^test$')
{
my ( $self, $c, $parameter ) = @_;
$c->response->body( 'length = ' . length($parameter) );
}
- B< -
4) Add a test script "t/04encoding.t" like this:
- B< -
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests => 4;
use Test::Deep;
use HTTP::Status;
use HTTP::Request;
use Data::Dumper;
BEGIN { use_ok 'Catalyst::Test', 'MyApp' }
BEGIN { use_ok 'MyApp::Controller::Root' }
foreach my $u ('http://localhost/test/%E3%81%8B',
"http://localhost/test/\x{304b}"; )
{
my $request = HTTP::Request->new(
'GET'=> $u, [ 'Content-Type' => 'text/html; charset=utf8', ],
);
print $request->as_string();
my $response = request( $request );
is( $response->content, 'length = 1', 'length = 1' );
}
- B< -
5) Start the test script
% perl t/04encoding.t
The first call will give the correct answer 'length = 1' because the 3
arabian octets were encoded correctly to one character.
The second call will give the wrong answer 'length = 3'.
Please note that the statement "print $request->as_string()" will print
the same http header:
> GET http://localhost/test/%E3%81%8B
> Content-Type: text/html; charset=utf8
My 2 cents: Further investigation brought me to
Catalyst::Plugin::Unicode::Encoding::prepare_action().
The problem is that the second URL from above is already an utf8 string,
means that "Encode::is_utf8( $_ )" in the named method returns true and
nothing will be done by the plugin.
Before I do some silly stuff I want to hear a second opinion from the list.
Is this fixable? Is catalyst here the problem? I think not. According
to the Bug in URI (Ticket #43859, "should be _utf8_off -ed raw data
before URI encoding",
https://rt.cpan.org/Ticket/Display.html?id=43859) the problem may be
within URI.
But maybe it's possible to fix this issue in the testsuite of catalyst.
Any thoughts?
--
So long... Fuzz
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] local::lib and mini-cpan for Catalyst apps
On Thursday 16 July 2009, Chris wrote: > Has anyone had success with such a thing? If/when I get it working > I'll do a write-up for the wiki. Recently I've written a small shell script that install a lot of catalyst stuff under '/foo/bar'. After tweaking PERL5LIB everything runs fine. It's not nice but's it's working (for me). But the local::lib approach looks smarter. B-) -- So long... Fuzz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] script/myapp_server -r Can't exec "/usr/bin/perl" every 3 or 4 restarts
On Tuesday 28 April 2009, Matt S Trout wrote:
> Two possibilities:
>
> (1) exec a $^X to print @INC to get the "normal" @INC
>
> (2) use $Config{arch} and /^5.\/ to strip off the extra ones.
>
> Thoughts?
I think (1) is more bulletproof. I think a restart costs a lot of time
and an additional call of $^X doesn't matter here.
--
So long... Fuzz
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] script/myapp_server -r Can't exec "/usr/bin/perl" every 3 or 4 restarts
On Wednesday 22 April 2009, Mike Glen wrote:
> I'm running the catalyst server (script/myapp_server) using the -r
> option to restart after changes are made but after every 3 or 4
> restarts i get the error message
>
> Can't exec "/usr/bin/perl": Argument list too long at
> /usr/lib/perl5/site_perl/5.8.5/Catalyst/Engine/HTTP.pm line 337.
1) Got privileges to edit the file HTTP.pm, make a copy
2) open the file in an editor and add this 2 lines before the exec
statement in line 337:
use Data::Dumper
warn Dumper([$^X, $0, @{ $options->{argv} }]);
Look at the output and post it here.
--
So long... Fuzz
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where to put "use"
On Wednesday 18 February 2009, Dermot wrote: > One of my controller is starting to use a lot of other modules like > File::Find...etc but they are usually confined to one subroutine or > method. It's most common to see all the use statements at the top of > the package but I have seen instances where they are declared within > the Sub block. Is there an advantage is declaring the use of modules, > that are only used by a single subroutine, in that subroutine? For perl it doesn't matter where you put this definition. Personaly I expect to find the 'use' at the top of the sources. Not in in middle of the file. At least I would expect it in a middle of a subroutine. Just my 2 cents. -- So long... Fuzz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst site design drafts feedback thread
On Wednesday 11 June 2008, Matt S Trout wrote: > Simon Elliott: > > (1) http://www.browsing.co.uk/cat To be short: I like the first version. -- So long... Fuzz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
