Re: Apache-Test subdirectory has moved
Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? it probably should but it doesn't. just copy your modified files to someplace safe, do the update, then move then back. --Geoff
RE: loading mod_perl first?
Hi,
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first,
# so make sure that it's loaded before files inherited from the
# global httpd.conf
$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
what this does is load mod_perl.so ahead of all other
modules, giving it least priority. there are a few problems
I see with this
- in 1.3 this is a _very_ untypical setup - mod_perl.so
needs to be loaded last so that it gets first crack at each phase.
- in 2.X order doesn't matter due to the new hooking API,
but it _does_ matter for overriding directives. that is, you
can't load mod_perl.so first and get first crack at
_directive_ parsing.
anyway, I guess what I'm saying is that 99% of the time we
want mod_perl to have the highest priority, but we do the
exact opposite with Apache-Test, which is probably ungood.
now, in all fairness to embperl I don't want to just yank
this out without giving gerald some alternative. however, I
think it's a bad idea to create a test environment that
doesn't accurately represent the most common case.
so, here are some possible solutions...
- historically I think this was introduced before we had
extra.last.conf.in functionality. gerald, does using that
file help you?
I don't use Apache::Test (unless I install a new mod_perl and run make
test). If I remember right the reason why this was introduced, was that
mod_perl copied the LoadModule over from httpd.conf and the tests fails
then, when Embperl.so is loaded before mod_perl.so, because there are
unresolved symbols.
I am not sure if this is still a problem.
- we could provide for an extra argument to
configure_libmodperl() which would place mod_perl.so first
instead of the (new) default of last. this would allow folks
like embperl to do something like
package My::TestConfigurePerl;
our @ISA = qw(Apache::TestConfigurePerl);
sub configure_libmodperl { shift-SUPER::configure_libmodperl(1) }
and have things work the way they did before. patch attached.
I am not sure if I understand the whole picture, since digging in
Apache::Test was some time ago for me, but it looks like that this change
might make sense.
Gerald
thoughts?
--Geoff
Re: Apache-Test subdirectory has moved
Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. --Geoff
preload modules at sever startup
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
Thanks in advance,
Jim
Re: preload modules at sever startup
Jim Martinez wrote:
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
better [EMAIL PROTECTED] now, but that list was just created yesterday :)
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
if you can move it to t/lib/Foo/Bar.pm Apache-Test will pick it up.
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
yes. an equivalent in mp1 might be to do this in extra.conf.in
Perl
use lib qw(@ServerRoot@/../lib)
/Perl
or without the Perl sections from modperl_extra.pl.in, which is equivalent
to startup.pl but with @var@ substitution. you can use modperl_extra.pl if
you don't need substitution.
keep in mind that if you go this route you will probably need to change
extra.conf.in to extra.last.conf.in so that it is loaded _after_ your
startup.pl. see the bottom of the generated httpd.conf to see what I mean.
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
no, that's the idea. you just need to use the magic files :)
HTH
--Geoff
Re: loading mod_perl first?
may be we should be more flexible right away and use the same approach Apache uses, i.e. have each custom module a say for its insertion priority. So we could add mod_perl as middle module and give other modules an opportunity to load themselves before (first/very_first or after (last/very_last) mod_perl or some other module. It really shouldn't be mod_perl centric as more and more non-perl projects start to use A-T. well, I think this is kinda a mod_perl problem, since we're only talking about TestConfigurePerl and it's special treatment of mod_perl. if you use TestConfig or TestConfigPHP then the modules are just inherited from httpd.conf (mod_perl included) in the order in which they appear there, which is typically what the user wants. in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. So instead of printing the modules right away they could be assembled into an array which will be then resorted the way the user wants. e.g.: add_foo(, before = mod_perl.c); add_foo(, after = qw[mod_perl.c mod_proxy.c]); or have those before/after/last/first/etc encoded in the API instead... well, I think that for the most part inheriting order from httpd.conf is sufficient, at least for the moment, but we can always create a larger API later when time allows. for the moment, though, I think I'm happy to make an exception for embperl within TestConfigPerl. at least until somebody complains :) --Geoff
Re: loading mod_perl first?
Geoffrey Young wrote: in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. Don't the new 2.x proxy modules have the same type of dependency? mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy, but I've never tried loading them out of order to see if they fail. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: loading mod_perl first?
Christopher H. Laco wrote:
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on
another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use
PerlModule not
LoadModule. embperl seems to be the exception to this. axkit would
be the
only other I could think of but I just verified that it uses
PerlModule as well.
Don't the new 2.x proxy modules have the same type of dependency?
mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
but I've never tried loading them out of order to see if they fail.
yeah, that seems to be the case. and apparently there are some things that
may require mod_dav as well.
but generally this isn't an issue, since we inherit the order, as well as
module location, from httpd.conf. of course, if mod_dav wanted to use
Apache-Test for its own development it wouldn't inherit from httpd.conf but
would create its own TestConfigDav.pm class to handle things for it.
what makes mod_perl unique in this circumstance is that we are making
exception for Embperl, which is really a third party module that we have no
control over - anybody can have a custom mod_foo that depends on mod_perl or
any other module, but that doesn't mean we need to account for it in
Apache-Test land.
anyway, I'm starting to think that the best solution is like the one I've
attached here, at least for the moment. what this means is that people with
Embperl in their httpd.conf won't have problems, while people wanting to
explicitly test Embperl will have to do what everyone else needs to do -
subclass TestConfig.pm and determine the module loading order themselves.
--Geoff
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
Re: Apache-Test subdirectory has moved
Geoffrey Young wrote: Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? if you don't find any with grep, then there are none. So we should add one then :) additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: loading mod_perl first?
Geoffrey Young wrote:
+1
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? if you don't find any with grep, then there are none. So we should add one then :) additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test subdirectory has moved
if you don't find any with grep, then there are none. So we should add one then :) :) yes, now that it's officially ours we should do more to publicise it. additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. that's cool. additionally I think we should have subdirectories for each of the supported languages /Apache-Test/perl /Apache-Test/php /Apache-Test/parrot (someday soon) and so on. in fact, it was the need for a home for php-related docs and whatnot that prompted this move in the first place ;) And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? yes, specifically under /Apache-Test/perl was what I was going to suggest. And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) yes. and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup good idea. from an .htaccess file or do we do that in the core httpd.conf? of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? --Geoff
