FAQ
Hi

It gives me great pleasure to announce the third development release of
the next major version of Catalyst.

The changes from the previous PSGI development release include fixes for
various test failures as well as refactoring of the API for retrieving
PSGI application code references for Catalyst applications. See the end
of this mail for the full changelog.

This is a development release, and we need people to start trying to use
it _NOW_, and to tell us about the issues you find with your real world
applications. Otherwise we're going to be unable to fix those issues
before a final release.

There are still some known problems with the current release, and the
upgrading documentation is at this stage anything but complete.
However, we have been working hard to keep this release as compatible as
possible with previous versions, and the documentation for upgrading
will greatly improve before the final version..

Known issues:
* lighttpd versions below 1.4.23 are known to be broken (this should be able to
be worked around using Plack::Middleware::LighttpdScriptNameFix - we would love
some people using earlier versions of lighttpd to help test this)
* IIS6 is believed to be broken (fix will be forthcoming - please shout up if
you will be able to test this for us).

Other than this list of known issues, everything should continue working
as it did beforehand for all users (including current users of
Catalyst::Engine::PSGI). You shouldn't have to do _anything_ to upgrade
to the new release, other than ensure your application scripts (as
generated by catalyst.pl) to use the Catalyst::Script:: classes.

Please test the release out and let us know how you get on.

The release can be found at:
http://search.cpan.org/~flora/Catalyst-Runtime-5.89002-TRIAL/

Please report your successes (and/or failures) to the list, or come find
us on irc. We'll be trying to get a new dev release out every couple of
weeks now until people stop finding issues..

Thanks in advance


--
5.89002 2011-03-02 11:30:00 (TRIAL release)

Bug fixes:
- Fix a couple of test failures caused by optional dependencies such as FCGI
not being installed.

Refactoring:
- Simplified the API for getting a PSGI application code reference for a
Catalyst application for use in, for example, .psgi files. See
Catalyst::Upgrading for details.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/ab592f62/attachment.pgp

Search Discussions

  • Pedro Melo at Mar 2, 2011 at 3:08 pm
    Hi,
    On Wed, Mar 2, 2011 at 10:50 AM, Florian Ragwitz wrote:
    This is a development release, and we need people to start trying to use
    it _NOW_, and to tell us about the issues you find with your real world
    applications. Otherwise we're going to be unable to fix those issues
    before a final release.

    There are still some known problems with the current release, and the
    upgrading documentation is at this stage anything but complete.
    However, we have been working hard to keep this release as compatible as
    possible with previous versions, and the documentation for upgrading
    will greatly improve before the final version..
    I've just tested my app with the this version.

    I've noticed a small difference with Catalyst::Test. The latest stable
    version include two headers, 'host' and 'https'. They are missing from
    this version.

    Is this a documented change that I missed or a bug?

    Thanks,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • Tomas Doran at Mar 2, 2011 at 3:14 pm

    On 2 Mar 2011, at 15:08, Pedro Melo wrote:
    Is this a documented change that I missed or a bug?
    A bug!

    Thanks for trying and notifying us :_)

    Cheers
    t0m
  • Pedro Melo at Mar 2, 2011 at 3:23 pm
    Hi,
    On Wed, Mar 2, 2011 at 3:17 PM, Tomas Doran wrote:
    On 2 Mar 2011, at 15:08, Pedro Melo wrote:

    Is this a documented change that I missed or a bug?
    A bug!

    Thanks for trying and notifying us :_)
    No problem. I'm following the psgi branch, so I can update it and try
    again later if you wish.

    Bye,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • Florian Ragwitz at Mar 2, 2011 at 3:27 pm
    Many thanks for testing this release.


    Pedro Melo <melo@simplicidade.org> writes:
    I've noticed a small difference with Catalyst::Test. The latest stable
    version include two headers, 'host' and 'https'. They are missing from
    this version.

    Is this a documented change that I missed or a bug?
    It's certainly not the former, but I'm not sure it's the latter either.

    When doing local requests using Catalyst::Test (i.e. without
    CATALYST_SERVER to do remote testing set), HTTP::Request::AsCGI used to
    be used. We got rid of that and switched to using the infrastructure
    provided by Plack::Test instead.

    For local requests, Plack::Test::MockHTTP will now be used, so the
    HTTP::Requests from your tests will be turned into PSGI env hashes and
    then handled by your app. Apparently Plack::Test::MockHTTP doesn't set
    either HOST or HTTPS headers like HTTP::Request::AsCGI does. Instead it
    provides the server host in the SERVER_NAME header, and the uri scheme
    (http or https) in psgi.url_scheme.

    I'm not sure if this change of behaviour is something we should fix
    though. The engine knows that a request is secure by checking
    psgi.url_scheme, and applications can ask for that using
    $ctx->request->secure. Similarly, the request host was, is, and probably
    always will be available as $ctx->request->host.

    Did these changes actually cause your app to break? If so, what exactly
    does the code that broke look like?
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/ff78d40c/attachment.pgp
  • Pedro Melo at Mar 2, 2011 at 3:41 pm
    Hi,
    On Wed, Mar 2, 2011 at 3:27 PM, Florian Ragwitz wrote:
    Pedro Melo <melo@simplicidade.org> writes:
    I've noticed a small difference with Catalyst::Test. The latest stable
    version include two headers, 'host' and 'https'. They are missing from
    this version.

    Is this a documented change that I missed or a bug?
    It's certainly not the former, but I'm not sure it's the latter either.

    When doing local requests using Catalyst::Test (i.e. without
    CATALYST_SERVER to do remote testing set), HTTP::Request::AsCGI used to
    be used. We got rid of that and switched to using the infrastructure
    provided by Plack::Test instead.

    For local requests, Plack::Test::MockHTTP will now be used, so the
    HTTP::Requests from your tests will be turned into PSGI env hashes and
    then handled by your app. Apparently Plack::Test::MockHTTP doesn't set
    either HOST or HTTPS headers like HTTP::Request::AsCGI does. Instead it
    provides the server host in the SERVER_NAME header, and the uri scheme
    (http or https) in psgi.url_scheme.

    I'm not sure if this change of behaviour is something we should fix
    though. The engine knows that a request is secure by checking
    psgi.url_scheme, and applications can ask for that using
    $ctx->request->secure. Similarly, the request host was, is, and probably
    always will be available as $ctx->request->host.
    Right now I don't need https/secure, but I do need the host.

    At first I assumed that something like $ctx->request->host would be
    available but its not:

    [error] Caught exception in E5::Sites::Gestao::View::HTML->process
    "Can't locate object method "host" via package "Catalyst::Request"

    Thats with psgi branch, but I'm pretty sure stable doesn't have it either.
    Did these changes actually cause your app to break? If so, what exactly
    does the code that broke look like?
    Yes, it did because the app switched template paths based on the
    hostname used to access the app.

    The code I was using was:

    my $host = $c->request->headers->header('Host');
    $host =~ s/:\d+$//;

    I would prefer %ctx->request->host though, much cleaner.

    Bye,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • Florian Ragwitz at Mar 2, 2011 at 3:55 pm

    Pedro Melo writes:
    On Wed, Mar 2, 2011 at 3:27 PM, Florian Ragwitz wrote:

    I'm not sure if this change of behaviour is something we should fix
    though. The engine knows that a request is secure by checking
    psgi.url_scheme, and applications can ask for that using
    $ctx->request->secure. Similarly, the request host was, is, and probably
    always will be available as $ctx->request->host.
    Right now I don't need https/secure, but I do need the host.

    At first I assumed that something like $ctx->request->host would be
    available but its not:

    [error] Caught exception in E5::Sites::Gestao::View::HTML->process
    "Can't locate object method "host" via package "Catalyst::Request"
    Sorry, I meant to say $ctx->request->uri->host
    Did these changes actually cause your app to break? If so, what
    exactly does the code that broke look like?
    Yes, it did because the app switched template paths based on the
    hostname used to access the app.

    The code I was using was:

    my $host = $c->request->headers->header('Host');
    $host =~ s/:\d+$//;
    I guess pretty much every webserver will set a Host header, so we should
    probably do that as well in Plack::Test::MockHTTP, or at least in
    Catalyst::Test::local_request only for back-compat. I'll see what Plack
    upstream thinks about doing this in ::MockHTTP.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/0f2714fb/attachment.pgp
  • Pedro Melo at Mar 2, 2011 at 5:02 pm
    Hi,
    On Wed, Mar 2, 2011 at 3:55 PM, Florian Ragwitz wrote:
    Pedro Melo <melo@simplicidade.org> writes:
    On Wed, Mar 2, 2011 at 3:27 PM, Florian Ragwitz wrote:

    I'm not sure if this change of behaviour is something we should fix
    though. The engine knows that a request is secure by checking
    psgi.url_scheme, and applications can ask for that using
    $ctx->request->secure. Similarly, the request host was, is, and probably
    always will be available as $ctx->request->host.
    Right now I don't need https/secure, but I do need the host.

    At first I assumed that something like $ctx->request->host would be
    available but its not:

    [error] Caught exception in E5::Sites::Gestao::View::HTML->process
    "Can't locate object method "host" via package "Catalyst::Request"
    Sorry, I meant to say $ctx->request->uri->host
    Ahs, cool, that works fine for me. Should have though of that.

    Did these changes actually cause your app to break? If so, what
    exactly does the code that broke look like?
    Yes, it did because the app switched template paths based on the
    hostname used to access the app.

    The code I was using was:

    my $host = $c->request->headers->header('Host');
    $host =~ s/:\d+$//;
    I guess pretty much every webserver will set a Host header, so we should
    probably do that as well in Plack::Test::MockHTTP, or at least in
    Catalyst::Test::local_request only for back-compat. I'll see what Plack
    upstream thinks about doing this in ::MockHTTP.
    Cool. I'll be using $c->request->uri->host for now, although
    $c->request->host as a shortcut would be nice :)

    Bye,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • Tomas Doran at Aug 6, 2011 at 2:47 pm

    On 2 Mar 2011, at 15:08, Pedro Melo wrote:
    I've just tested my app with the this version.

    I've noticed a small difference with Catalyst::Test. The latest stable
    version include two headers, 'host' and 'https'. They are missing from
    this version.

    Is this a documented change that I missed or a bug?
    I have been trying to find this to rectify it, but I can't reproduce
    the issue (in the current stable release).

    Which function from Catalyst::Test are you using, and are the headers
    in the request or the response?

    Any chance you could show us a short example?

    Cheers
    t0m
  • John Napiorkowski at Aug 8, 2011 at 10:56 pm

    ----- Original Message -----
    From: Tomas Doran <bobtfish@bobtfish.net>
    To: Pedro Melo <melo@simplicidade.org>
    Cc: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Sent: Saturday, August 6, 2011 10:47 AM
    Subject: Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL PSGI Catalyst - third development release

    On 2 Mar 2011, at 15:08, Pedro Melo wrote:
    I've just tested my app with the this version.

    I've noticed a small difference with Catalyst::Test. The latest stable
    version include two headers, 'host' and 'https'. They are
    missing from
    this version.

    Is this a documented change that I missed or a bug?
    Could we possibly be talking about this method:?http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Test.pm;h=5c0cbe7cfd9ea22e2a20c1b14d10d7b69367a0ee;hb=psgi#l396


    I have been trying to find this to rectify it, but I can't reproduce the
    issue (in the current stable release).

    Which function from Catalyst::Test are you using, and are the headers in the
    request or the response?

    Any chance you could show us a short example?

    Cheers
    t0m


    _______________________________________________
    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/
  • Tomas Doran at Aug 9, 2011 at 2:51 pm

    On 8 Aug 2011, at 23:56, John Napiorkowski wrote:
    ----- Original Message -----
    From: Tomas Doran <bobtfish@bobtfish.net>
    To: Pedro Melo <melo@simplicidade.org>
    Cc: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Sent: Saturday, August 6, 2011 10:47 AM
    Subject: Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL
    PSGI Catalyst - third development release

    On 2 Mar 2011, at 15:08, Pedro Melo wrote:

    Is this a documented change that I missed or a bug?
    Could we possibly be talking about this method: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Test.pm;h=5c0cbe7cfd9ea22e2a20c1b14d10d7b69367a0ee;hb=psgi#l396
    Possibly, but that functionality is still there, and the tests for it
    pass...

    Cheers
    t0m
  • Fernan Aguero at Mar 2, 2011 at 9:24 pm

    On Wed, Mar 2, 2011 at 7:50 AM, Florian Ragwitz wrote:
    Hi

    It gives me great pleasure to announce the third development release of
    the next major version of Catalyst. [...]
    You shouldn't have to do _anything_ to upgrade
    to the new release, other than ensure your application scripts (as
    generated by catalyst.pl) to use the Catalyst::Script:: classes.

    Please test the release out and let us know how you get on.
    Dear all,

    please apologize if these are very stupid questions.

    We have a couple of catalyst web apps running under apache/mod_perl,
    and we usually test the apps during development using the
    script/myapp_server.pl script.

    I'd like to test the upcoming release, to make sure everything runs
    smoothly and check everything well in advance of a future upgrade of
    Catalyst::Runtime on our production servers.

    So I've downloaded the most recent version (5.89002) and installed it
    on a local prefix ($HOME/lib).

    Question 1: how to I tell my local checkout of the web app to use
    $HOME/lib/share/perl/5.10.1/Catalyst.pm instead of the system's
    /usr/local/share/perl/5.10.1/Catalyst.pm?

    I've edited myapp_server.pl and added
    use lib "/home/fernan/lib";

    but upon firing the server using myapp_server.pl, I still see: myapp
    powered by Catalyst 5.80031

    Question 2: I'm at a loss with regards to PSGI, Plack et al. I've read
    the docs at http://plackperl.org/, but I'm still not figuring our what
    this is all about. Should I care? Would this affect how I'm currently
    deploying my catalyst apps (apache/mod_perl)? Should I change (e.g.
    for better performance)? I'd appreciate if someone can explain in one
    or two sentences what plack/psgi is and/or why I should care, or
    perhaps point me in the right directions?

    Thanks a lot.

    And as always, many thanks for such a great framework!

    --
    fernan
  • Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 at Mar 3, 2011 at 3:26 pm

    Fernan Aguero ?:
    what plack/psgi is and/or why I should care
    I hear that often, so here's the elevator pitch I'm usually telling to convey
    the basic idea.

    Catalyst is a Web framework that runs on several Web servers. The different
    parts necessary to make this work are separated out into adapter classes such
    as Catalyst::Engine::Apache2::MP20. There are quite a number of them.

    Then framework X comes along and has to implement these adapters suitable for
    its codebase, too, and so on for every new framework.

    This repetition is not a good thing, and the frameworks want to get rid of it.
    The various adapters are written just once, outside of the frameworks, and
    with a standardised interface. The frameworks now only need exactly one
    adapter each, adhering to that interface.

    That interface spec is called PSGI; the implementation is called Plack.

    Apart from less code for each framework, there is the other advantage that
    adding support for a new Web server (e.g. Plack::Handler::Mongrel2)
    automatically enables this Web server for any PSGI-compliant framework.

    While it has been possible to run Catalyst 5.8 on top of PSGI-enabled Web
    servers with Catalyst::Engine::PSGI, Catalyst 5.9 goes native and cuts out one
    layer of indirection.

    Now that you know that, you should be able to answer the "Question 2"
    questions yourself.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: This is a digitally signed message part.
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110303/08eab499/attachment.pgp
  • Dave Rolsky at Mar 3, 2011 at 6:07 pm

    On Thu, 3 Mar 2011, Lars Dɪᴇᴄᴋ�ᴡ 迪拉斯 wrote:

    Apart from less code for each framework, there is the other advantage that
    adding support for a new Web server (e.g. Plack::Handler::Mongrel2)
    automatically enables this Web server for any PSGI-compliant framework.

    While it has been possible to run Catalyst 5.8 on top of PSGI-enabled Web
    servers with Catalyst::Engine::PSGI, Catalyst 5.9 goes native and cuts out one
    layer of indirection.
    The other advantage is that you can put functionality in the interface
    layer (Plack middleware), which means that you have an ecosystem of
    plugins _shareable across frameworks_.


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Fernan Aguero at Mar 3, 2011 at 6:28 pm

    On Thu, Mar 3, 2011 at 12:26 PM, Lars D?????? ??? wrote:
    Fernan Aguero ?:
    what plack/psgi is and/or why I should care
    I hear that often, so here's the elevator pitch I'm usually telling to convey
    the basic idea. [snipped]
    While it has been possible to run Catalyst 5.8 on top of PSGI-enabled Web
    servers with Catalyst::Engine::PSGI, Catalyst 5.9 goes native and cuts out one
    layer of indirection.

    Now that you know that, you should be able to answer the "Question 2"
    questions yourself.
    Thanks Lars,

    Now know WHAT plack/psgi is.

    There's still a 'why should I care' aspect in my Question 2 that was
    not clearly answered.

    Although it was not clear in any of the Plack/PSGI documentation that
    I've read, my guess is that only framework developers care about this.

    I, as a developer of web applications, shouldn't. Right?

    In other words, my apps will still work without modification under
    mod_perl2/Apache whenever the next Catalyst release (5.9, native PSGI)
    is out. Right?

    --
    fernan
  • Nigel Metheringham at Mar 4, 2011 at 8:41 am

    On 3 Mar 2011, at 18:28, Fernan Aguero wrote:

    Although it was not clear in any of the Plack/PSGI documentation that
    I've read, my guess is that only framework developers care about this.

    I, as a developer of web applications, shouldn't. Right?
    You should care in that it simplifies your choices - rather than
    needing to select an environment with a framework and web server
    that integrate, you now go for a PSGI supported webserver and can
    switch frameworks on top of that defined hand-off point.
    Should make it much easier if, say, you end up with multiple
    frameworks (ie when you are transitioning functionality from one to
    another).

    Nigel.
    --
    [ Nigel Metheringham ------------------------------ nigel@dotdot.it ]
    [ Ellipsis Intangible Technologies ]
  • Tomas Doran at Mar 4, 2011 at 4:50 pm

    On 3 Mar 2011, at 18:28, Fernan Aguero wrote:
    In other words, my apps will still work without modification under
    mod_perl2/Apache whenever the next Catalyst release (5.9, native PSGI)
    is out. Right?
    Yes, you should have to make exactly no changes, and everything should
    continue to work exactly as it does currently.

    Ergo please have a test and shout up if this isn't the case for you!

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 2, '11 at 10:50a
activeAug 9, '11 at 2:51p
posts17
users8
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase