Skip Menu |

This queue is for tickets about the Kelp CPAN distribution.

Report information
The Basics
Id: 90175
Status: resolved
Priority: 0/
Queue: Kelp

People
Owner: MINIMAL [...] cpan.org
Requestors: GTERMARS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.4501
Fixed in: (no value)



Subject: Middleware doesn't re-wrap when using Kelp::Test
While trying to run some tests using "Kelp::Test" against my own application, it kept throwing an error about: not ok 3 - No Session middleware wrapped at /usr/share/perl5/vendor_perl/Kelp.pm line 219. After having a view of the source, I think I see why... While you use: next if $self->{_loaded_middleware}->{$class}++; to prevent the middleware from being re-loaded and re-wrapped around the application multiple times, that same "run()" method also creates the app each time its invoked. Thus, if I were to take an App that specified middleware via "config.pl", and ran it in a test as follows: $t->request(GET "/users/123")->code_is(200); $t->request(GET "/users/123")->code_is(200); I would get that "No Session middleware" error. The $app created by "run()" for the first request caused the modules to get loaded, and it was wrapped with that middleware. For the second request, however, "run()" determined that the modules were already loaded, and it was *not* wrapped with the middleware. Perhaps, rather than using "$self->{_loaded_middleware}" to track if we've wrapped the App with that middleware, what about just using a hash in that function? Then, it'd re-wrap the newly created App each time it was invoked. FYI... I did also check your own tests to see if I was doing something weird here, and I saw in your "middleware.t" test that it cleared the list of loaded middleware between each test invocation. I suspect that this is why it went un-noticed. Your thoughts?
You make a very valid point. Kelp::Test::request should *not* load and wrap the entire PSGI app each time it is called. I have already fixed this on Github and I will be releasing a new version of Kelp to CPAN probably on Monday. You can see the changes here, and apply them to your copy of lib/Kelp/Test.pm https://github.com/naturalist/kelp/commit/364f4fa093a343e2d01ab4e037c9a06cffb21c2a You don't need to worry about applying the changes to the .t file. Thanks for catching and reporting this issue! Cheers, Stefan On Sat Nov 09 01:47:30 2013, GTERMARS wrote: Show quoted text
> While trying to run some tests using "Kelp::Test" against my own > application, it kept throwing an error about: > > not ok 3 - No Session middleware wrapped at > /usr/share/perl5/vendor_perl/Kelp.pm line 219. > > After having a view of the source, I think I see why... > > While you use: > next if $self->{_loaded_middleware}->{$class}++; > > to prevent the middleware from being re-loaded and re-wrapped around > the application multiple times, that same "run()" method also creates > the app each time its invoked. > > Thus, if I were to take an App that specified middleware via > "config.pl", and ran it in a test as follows: > > $t->request(GET "/users/123")->code_is(200); > $t->request(GET "/users/123")->code_is(200); > > I would get that "No Session middleware" error. The $app created by > "run()" for the first request caused the modules to get loaded, and it > was wrapped with that middleware. For the second request, however, > "run()" determined that the modules were already loaded, and it was > *not* wrapped with the middleware. > > Perhaps, rather than using "$self->{_loaded_middleware}" to track if > we've wrapped the App with that middleware, what about just using a > hash in that function? Then, it'd re-wrap the newly created App each > time it was invoked. > > FYI... I did also check your own tests to see if I was doing something > weird here, and I saw in your "middleware.t" test that it cleared the > list of loaded middleware between each test invocation. I suspect > that this is why it went un-noticed. > > Your thoughts?
Just tried this patch out here locally, and it works like a charm. Thanks for the quick response!!
Resolved in version 0.4550