[Catalyst] modperl 1.3 wierdness
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 ___ 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] modperl 1.3 wierdness
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. ___ 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] modperl 1.3 wierdness
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: use lib qw(/my/home/dir); PerlModule My::App After: use lib qw(/my/home/dir); use My::App; I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, well, loading anything, though. Odd. ___ 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] modperl 1.3 wierdness
On Mon, Apr 21, 2008 at 07:09:26PM +1000, Toby Corkindale wrote: > The above problem was solved by changing the apache config. > Before: > >use lib qw(/my/home/dir); > > PerlModule My::App > > After: > >use lib qw(/my/home/dir); >use My::App; > 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 Directorhttp://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/ ___ 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] modperl 1.3 wierdness
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: > > > >use lib qw(/my/home/dir); > > > > PerlModule My::App > > > > After: > > > >use lib qw(/my/home/dir); > >use My::App; > > > > 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 ___ 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] modperl 1.3 wierdness
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 Directorhttp://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/
___
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] modperl 1.3 wierdness
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?
___
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] modperl 1.3 wierdness
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 Directorhttp://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/
___
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/
