FAQ
Hi guys,
I have an application that runs well on modperl 2.0, fcgi and the standalone
server.. but due to some stubborn/paranoid sysadmins[1] we are going to have to
run it under modperl 1.3.

This has resulted in some wierdness I haven't seen before, and I wondered if
anyone else had hit it?

I'll try and make a working mock-up I can post to the list to demonstrate the
problem IF no-one else has seen it before.

Given that I have:
My::Schema (DBIx::Class::Schema)
--> My::Schema::OneTable
--> My::Schema::TableTwo
and
My::App (Catalyst)
--> My::App::Model::DB (Catalyst::Model::DBIC::Schema)

During Apache start-up I see:
---------------------------------------------------------
Subroutine My::App::Model::DB::OneTable::ACCEPT_CONTEXT redefined at
lib/My/App/Model/DB.pm
Subroutine My::App::Model::DB::TableTwo::ACCEPT_CONTEXT redefined at
lib/My/App/Model/DB.pm
Syntax error on line 7 of apache.conf:
Can't locate My/App/Model/DB/OneTable.pm in @INC ([snip]).
Compilation failed in require.
---------------------------------------------------------

This is weird - why is it trying to load the *schema*'s subclasses under the
Catalyst's model? (Which of course fails..)

Cheers,
Toby

Search Discussions

  • Toby Corkindale at Apr 21, 2008 at 8:45 am

    On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote:
    Hi guys,
    I have an application that runs well on modperl 2.0, fcgi and the standalone
    server.. but due to some stubborn/paranoid sysadmins[1] we are going to have
    to run it under modperl 1.3.
    Footnotes:
    1) This is their job, to be paranoid and stubborn.

    2) We're actually running mod perl 1.29. Ick.
  • Toby Corkindale at Apr 21, 2008 at 10:09 am

    On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote:
    Hi guys,
    I have an application that runs well on modperl 2.0, fcgi and the standalone
    server.. but due to some stubborn/paranoid sysadmins[1] we are going to have
    to run it under modperl 1.3.

    This has resulted in some wierdness I haven't seen before, and I wondered if
    anyone else had hit it? [snip]
    During Apache start-up I see:
    ---------------------------------------------------------
    Subroutine My::App::Model::DB::OneTable::ACCEPT_CONTEXT redefined at
    lib/My/App/Model/DB.pm
    Subroutine My::App::Model::DB::TableTwo::ACCEPT_CONTEXT redefined at
    lib/My/App/Model/DB.pm
    Syntax error on line 7 of apache.conf:
    Can't locate My/App/Model/DB/OneTable.pm in @INC ([snip]).
    Compilation failed in require.
    ---------------------------------------------------------
    The above problem was solved by changing the apache config.
    Before:
    <Perl>
    use lib qw(/my/home/dir);
    </Perl>
    PerlModule My::App

    After:
    <Perl>
    use lib qw(/my/home/dir);
    use My::App;
    </Perl>


    I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, well,
    loading anything, though. Odd.
  • Matt S Trout at Apr 21, 2008 at 7:23 pm

    On Mon, Apr 21, 2008 at 07:09:26PM +1000, Toby Corkindale wrote:
    The above problem was solved by changing the apache config.
    Before:
    <Perl>
    use lib qw(/my/home/dir);
    </Perl>
    PerlModule My::App

    After:
    <Perl>
    use lib qw(/my/home/dir);
    use My::App;
    </Perl>
    Yep. PerlModule will do double-loading, as documented, which Catalyst can't
    handle (and shouldn't need to).

    I suspect you'd've found changing PerlModule to PerlRequire would have done
    the trick as well, though my MP1's rusty.
    I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, well,
    loading anything, though. Odd.
    If you didn't make install it and deleted the Makefile.PL, it's not going to.

    Catalyst uses the presence of Makefile.PL to check if it's running in an
    unpacked dist versus running installed; since obviously an unpacked dist
    -must- have a Makefile.PL otherwise it's not a valid dist[0]

    Choose one option :)

    [0] Yes, we do check for Build.PL as well. Hush.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Toby Corkindale at Apr 28, 2008 at 2:30 am

    On Mon, Apr 21, 2008 at 07:23:44PM +0100, Matt S Trout wrote:
    On Mon, Apr 21, 2008 at 07:09:26PM +1000, Toby Corkindale wrote:
    The above problem was solved by changing the apache config.
    Before:
    <Perl>
    use lib qw(/my/home/dir);
    </Perl>
    PerlModule My::App

    After:
    <Perl>
    use lib qw(/my/home/dir);
    use My::App;
    </Perl>
    Yep. PerlModule will do double-loading, as documented, which Catalyst can't
    handle (and shouldn't need to).

    I suspect you'd've found changing PerlModule to PerlRequire would have done
    the trick as well, though my MP1's rusty.
    As is mine.. I wish we'd move away from it here :(
    I'm still seeing some problems indicating the Plugin::ConfigLoader isn't,
    well, loading anything, though. Odd.
    If you didn't make install it and deleted the Makefile.PL, it's not going to.

    Catalyst uses the presence of Makefile.PL to check if it's running in an
    unpacked dist versus running installed; since obviously an unpacked dist
    -must- have a Makefile.PL otherwise it's not a valid dist[0]
    Aaah yes, I remember hitting this way back! That magic Makefile-detection..

    Unfortunately due to somewhat unusual app deployment tactics here, apps get
    "installed" manually, into their own little area, along with their required
    perl dependencies, thus losing the Makefile.PL, but also requiring that the
    config file lived in the same non-standard location.

    (it does kind of make sense..)
    Choose one option :)
    Erm, does stripping out ConfigLoader and replacing it with a similarly
    operating plugin that knows to look in our company-specific locations count? :)

    Thanks for the help!
    -Toby
  • Matt S Trout at May 3, 2008 at 11:22 pm

    On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
    Unfortunately due to somewhat unusual app deployment tactics here, apps get
    "installed" manually, into their own little area, along with their required
    perl dependencies, thus losing the Makefile.PL, but also requiring that the
    config file lived in the same non-standard location.
    How about using

    __PACKAGE__->config(
    'Plugin::ConfigLoader' => {
    file => __PACKAGE__->path_to(...)
    }
    );

    or setting an environment variable?

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Toby Corkindale at May 4, 2008 at 2:19 pm

    On Sat, May 03, 2008 at 11:22:49PM +0100, Matt S Trout wrote:
    On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
    Unfortunately due to somewhat unusual app deployment tactics here, apps get
    "installed" manually, into their own little area, along with their required
    perl dependencies, thus losing the Makefile.PL, but also requiring that the
    config file lived in the same non-standard location.
    How about using

    __PACKAGE__->config(
    'Plugin::ConfigLoader' => {
    file => __PACKAGE__->path_to(...)
    }
    );

    or setting an environment variable?
    The location varies depending on build version and status, but could have been
    solved with the env variable part combined with the loader options..
    But at the time it was 8pm at night and I wanted to go home, and hacking up a
    little DIY loader was quicker than trying to figure out what was going wrong
    with the plugin.. You know how it gets sometimes?
  • Matt S Trout at May 5, 2008 at 11:57 am

    On Sun, May 04, 2008 at 11:19:24PM +1000, Toby Corkindale wrote:
    On Sat, May 03, 2008 at 11:22:49PM +0100, Matt S Trout wrote:
    On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
    Unfortunately due to somewhat unusual app deployment tactics here, apps get
    "installed" manually, into their own little area, along with their required
    perl dependencies, thus losing the Makefile.PL, but also requiring that the
    config file lived in the same non-standard location.
    How about using

    __PACKAGE__->config(
    'Plugin::ConfigLoader' => {
    file => __PACKAGE__->path_to(...)
    }
    );

    or setting an environment variable?
    The location varies depending on build version and status, but could have been
    solved with the env variable part combined with the loader options..
    But at the time it was 8pm at night and I wanted to go home, and hacking up a
    little DIY loader was quicker than trying to figure out what was going wrong
    with the plugin.. You know how it gets sometimes?
    Yes, but I've had hacked the app back out of whatever broken-ass deployment
    system can't handle a checkout dir -and- doesn't use 'make install' so
    Catalyst's "find the config when installed as a normal perl/CPAN dist" logic
    didn't work either. Because really, if it can't handle a straight CPAN
    module properly deploying perl stuff using it ain't a good idea.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 21, '08 at 7:54a
activeMay 5, '08 at 11:57a
posts8
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Toby Corkindale: 5 posts Matt S Trout: 3 posts

People

Translate

site design / logo © 2022 Grokbase