Re: Apache::TestMB ignores '-axps=' flag ?

2007-04-25 Thread Joshua Hoblitt 
Doh!  That indeed is the problem.  A doc patch for Apache-Test 1.29 is
attached. ;)

-J

--
On Mon, Apr 23, 2007 at 05:20:34PM -0700, Geoffrey Young wrote:
 
 
 Joshua Hoblitt wrote:
  Hi Folks,
  
  I just discovered that version of Apache::TestMB (no version string)
  from Apache-Test 1.29 is ignoring the -apxs= flags passed on the command
  line. E.g., `perl Build.PL -axps=/usr/sbin/apxs2`. 
 
 I really don't know the M::B extension to A-T, but in Makefile-land
 there is no equal sign.  that is, it's
 
   perl Makefile.PL -apxs /usr/sbin/apxs2
 
 and not
 
   perl Makefile.PL -apxs=/usr/sbin/apxs2
 
 so, try that.  yeah, I know, it's silly and inconsistent, but... :)
 
 --Geoff
diff -Nur Apache-Test-1.29.orig/lib/Apache/TestMB.pm 
Apache-Test-1.29/lib/Apache/TestMB.pm
--- Apache-Test-1.29.orig/lib/Apache/TestMB.pm  2007-04-25 11:10:56.0 
-1000
+++ Apache-Test-1.29/lib/Apache/TestMB.pm   2007-04-25 11:11:22.0 
-1000
@@ -258,7 +258,7 @@
 options in addition to the usual CModule::Build options. For
 example:
 
-  perl Build.PL -apxs=/usr/local/apache/bin/apxs
+  perl Build.PL -apxs /usr/local/apache/bin/apxs
 
 Consult the LApache::Test|Apache::Test documentation for a complete
 list of options.


pgpelTst9fo2P.pgp
Description: PGP signature

Apache::TestMB ignores '-axps=' flag ?

2007-04-23 Thread Joshua Hoblitt 
Hi Folks,

I just discovered that version of Apache::TestMB (no version string)
from Apache-Test 1.29 is ignoring the -apxs= flags passed on the command
line. E.g., `perl Build.PL -axps=/usr/sbin/apxs2`.  I'm suspecting that
this is probably my fault as I've created my own subclass so that I can
add hooks into ACTION_(code|build|install|clean) to build some nested
autotooled code.  As an example here are the first few lines of my
Build.PL.

--
my $build_pkg   = eval { require Apache::TestMB }
? 'Apache::TestMB'
: 'Module::Build';

my $class = $build_pkg-subclass(code = 'EOF');
use Apache::TestMB;
@ISA = qw( Apache::TestMB );

my $pkg_dir = ./nebclient;

sub ACTION_code {
my $self = shift;

$self-SUPER::ACTION_code(@_);

my $old_pwd = $ENV{PWD};
chdir $pkg_dir;

unless (-e configure) {
system(./autogen.sh) == 0 or die install failed: $?;
}

chdir $old_pwd;
}

.
.
--

As with ACTION_code(), All of my action handlers invoke SUPER as their
first action.  Any ideas as to what I've done to squash the apxs param?

Example of apxs being ignored:
--
$ perl Build.PL -axps=/foo/bar
$ ./Build test
.
.
$ grep -iR apxs t
t/conf/apache_test_config.pm: 'APXS' = '/usr/sbin/apxs',
t/conf/apache_test_config.pm: '_apxs' = {},
t/conf/apache_test_config.pm: 'apxs' = 
'/usr/sbin/apxs',
grep: t/logs/cgisock: No such device or address

--

Cheers,

-J

--


pgpOXjQIsPDgf.pgp
Description: PGP signature

Re: Apache2::compat from mod_perl 2.0.3 -- multiple issues

2007-03-27 Thread Joshua Hoblitt 
On Mon, Mar 26, 2007 at 09:02:09AM -0400, Geoffrey Young wrote:
 Joshua Hoblitt wrote:
  This error is caused by 'Apache2::ServerUtil::server_root' (note that
   missing '()') and this repeated in several places through-out
  compat.pm.
 
 you are not the first to report this, but I guess we've let it slip
 until now.  fixed in svn.  thanks.

I can confirm that this is now fixed for me.  Thanks!

  Commenting out the 'use strict' at the top of compat.om reveals
  another more serious error:
  
  # Error:  Undefined subroutine
  Apache2::ServerUtil::restart_count called at
  /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 76,
  DATA line 9.
  
  Which I assume is supposed to be provided by ServerUtil.so except
  that this symbol isn't defined in this lib.
  
  nm ./Apache2/ServerUtil/ServerUtil.so | grep restart 1cf0 T
  XS_Apache2__ServerUtil_restart_count U modperl_restart_count
  
  Any ideas as to what might have gone wrong in the build?
 
 that's strange.  did all tests pass for you?  we explicitly exercise
 this in several of the test scripts.
 
 keep in mind that lots of this stuff won't work if you just do something
 like
 
   $ perl -cw lib/Apache2/compat.pm
 
 you really need to call it from within a live, running mod_perl
 environment.  if you are, please consider sending along a minimal test
 case that reproduces the issue.  see http://perl.apache.org/bugs/

All of the tests (a few are skipped because of missing deps) are passing
for me.  It looks like the only test from my application that fails with
this error under Apache::TestMB is from Test::Distribution, which 'eval
require ...;'s the module in.  I think we can safely consider this a
red herring (although it would be nice is Apache2::ServerUtil died more
politely when not run under mod_perl).

Cheers,

-J

--


pgpMU3cfWvjsz.pgp
Description: PGP signature

Apache2::compat from mod_perl 2.0.3 -- multiple issues

2007-03-23 Thread Joshua Hoblitt 
It seems that compat.pm isn't 'use strict' clean even thou it is declaring this
pragma.

# Error:  Bareword Apache2::ServerUtil::server_root not allowed while 
strict subs in use at 
/usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 347, DATA 
line 9.

This error is caused by 'Apache2::ServerUtil::server_root' (note that
missing '()') and this repeated in several places through-out compat.pm.

Commenting out the 'use strict' at the top of compat.om reveals another more
serious error:

# Error:  Undefined subroutine Apache2::ServerUtil::restart_count 
called at /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 76, 
DATA line 9.

Which I assume is supposed to be provided by ServerUtil.so except that this
symbol isn't defined in this lib.

nm ./Apache2/ServerUtil/ServerUtil.so | grep restart
1cf0 T XS_Apache2__ServerUtil_restart_count
 U modperl_restart_count

Any ideas as to what might have gone wrong in the build?

-J

--


pgprXcYHtXGTZ.pgp
Description: PGP signature

Apache::Test - regression with handling of cgid?

2005-07-01 Thread Joshua Hoblitt 
Hi Folks,

I'm getting cgid errors in t/logs/error_log unless I set 'ScriptSock' in
t/conf/extra.conf.in.

--
[Wed Jun 29 11:10:52 2005] [error] cgid daemon process died, restarting
[Wed Jun 29 11:10:52 2005] [error] (13)Permission denied: Couldn't bind unix 
domain socket /var/run/cgisock
--

I found this issue in a thread from 2003 that appears to have resolved
this.

http://aspn.activestate.com/ASPN/Mail/Message/modperl/1823561

Although Apache::Test is definitely inheriting the cgid conf from the
system files.  Under t/conf:

--
$ perl -MApache::Test -e 'print $Apache::Test::VERSION\n'
1.25
$ grep -i cgid *
apache_test_config.pm:  'cgid_module',
apache_test_config.pm:  'modules/mod_cgid.so'
apache_test_config.pm: 'IfModule
!mod_cgid.c
apache_test_config.pm:LoadModule cgid_module
/usr/lib/apache2/modules/mod_cgid.so
apache_test_config.pm:'mod_cgid.c' =
'/usr/lib/apache2/modules/mod_cgid.so',
httpd.conf:IfModule !mod_cgid.c
httpd.conf:LoadModule cgid_module
/usr/lib/apache2/modules/mod_cgid.so
--

Was this just never resolved or was the fix rolledback for some reason?

Cheers,

-J

--


pgpY1jda17SGN.pgp
Description: PGP signature

Re: Apache::DBI and mod_perl 2.0.1

2005-07-01 Thread Joshua Hoblitt 
On Thu, Jun 30, 2005 at 11:25:26AM -0400, Philip M. Gollucci wrote:
 Mark A. Downing wrote:
 
 On Thu, 30 Jun 2005, Philip M. Gollucci wrote:
 
 Thanks for this Mark.  (Un)fortunately you've been beat to it and 
 there are few more changes to
 get all of it working with mp2.
 
 
 Very nice. Thanks. Can we get that pushed up to CPAN?
 
 Umm Talk to Ask B. H.  He's been a bit sparse on the responses.  
 Granted he's very busy.
 
 I've asked 3 times now.

I would also very much like to have connect_on_init() working under mp2.

-J

--


pgpWrNLjkr3XA.pgp
Description: PGP signature

Re: Apache::DBI and mod_perl 2.0.1

2005-07-01 Thread Joshua Hoblitt 
On Thu, Jun 30, 2005 at 05:58:29PM -0400, Philip M. Gollucci wrote:
 
 http://p6m7g8.net/Apache-DBI
 
 The 0.97's connect_on_init() works under MP2.
 
 In fact p6m7g8.net is running it on a backend server.

I know, I had already tested it.  Perhaps I should have been more
specific and said, I would also very much like to have
connect_on_init() working under mp2 with a version of Apache::DBI
available from CPAN. ;)

-J

--


pgpbalcM0bU7y.pgp
Description: PGP signature

Re: Apache::Test - regression with handling of cgid?

2005-07-01 Thread Joshua Hoblitt 
The issue was finally resolved by uninstalling mp2, mp1 and then
reinstalling just mp2.  I'm still scratching my head as to exactly what
the problem was.  My best guess is that there was a conflict between
versions of mp2 installed by both CPAN.pm and Gentoo ebuild.

Cheers,

-J

--
On Fri, Jul 01, 2005 at 09:38:40AM -0400, Geoffrey Young wrote:
 
 
 Joshua Hoblitt wrote:
  Hi Folks,
  
  I'm getting cgid errors in t/logs/error_log unless I set 'ScriptSock' in
  t/conf/extra.conf.in.
 
 that is already set for you in t/conf/extra.conf.in
 
   IfModule mod_cgid.c
   ScriptSock logs/cgisock
   /IfModule
 
 if that code isn't in your t/conf/extra.conf.in you must be using a really
 old version of mod_perl :)
 
 
  I found this issue in a thread from 2003 that appears to have resolved
  this.
  
  http://aspn.activestate.com/ASPN/Mail/Message/modperl/1823561
 
 if you follow the whole thread you'll see that the fix was applied, which
 resulted in the above IfModule block.
 
  
  Although Apache::Test is definitely inheriting the cgid conf from the
  system files.  Under t/conf:
 
  $ grep -i cgid *
 
 that really doesn't help me.  a cut-and-paste of the appropriate mod_cgid
 configuration with context would be a better help.
 
 but the real issue is why mod_cgid is ignoring the ScriptSock directive we
 give it.  please visit http://perl.apache.org/bugs/ and follow the
 directions there so we can get a feel for your environment.
 
 --Geoff


pgpQHlh97JI0f.pgp
Description: PGP signature

Re: Can Apache::TestMB suppress APXS warnings?

2004-12-21 Thread Joshua Hoblitt 
On Mon, 20 Dec 2004, Stas Bekman wrote:
Joshua Hoblitt wrote:
Hi Folks,
I've been unable to figure out how to get Apache::TestMB to setup my 
build
environment in such a way as to suppress APXS warnings during a test run. 
e.g.

--
t/10_client_newAPXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/10_client_newok
t/11_client_create.APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/11_client_create.ok
t/12_client_replicate..APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/12_client_replicate..ok
t/13_client_cull...APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/13_client_cull...ok
--

Is it possible to silence these gratuitous warnings?
which modperl is that?
Apache/1.3.33 (Unix) mod_perl/1.29 and I'm using 
Apache::Test/Apache::TestMB 1.17.
what code do you have in your tests that invokes those?
Any of the .t files that have use Apache::Test qw( -withtestmore ); in 
them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also displays a
number of APXS warnings at the begnning of the test run.
Here is the complete output of a test run:
--
$ make test
/usr/bin/perl5.8.5 Build --makefile_env_macros 1 test
/usr/bin/perl5.8.5 -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.8.5 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -clean
/usr/bin/perl5.8.5 -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST 
-bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.8.5 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -bugreport 
-verbose=0
APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for TARGET failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
/usr/local/apache/bin/httpd  -d 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t -f 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/conf/httpd.conf -D 
APACHE1
using Apache/1.3.33
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server moa:8529 started
t/01_load...ok
t/02_server_setup...ok
t/03_server_create_object...ok
t/04_server_replicate_objectok
t/05_server_lock_object.ok
t/06_server_unlock_object...ok
t/07_server_find_instances..ok
t/08_server_delete_instance.ok
t/09_server_stat_object.ok
t/10_client_new.APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/10_client_new.ok
t/11_client_create..APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/11_client_create..ok
t/12_client_replicate...APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/12_client_replicate...ok
t/13_client_cullAPXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/13_client_cullok
6/15 skipped: unsure if this should be part of the API
t/14_client_lockAPXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/14_client_lockok
t/15_client_unlock..APXS (/usr/local/apache/bin/apxs) query

Re: Can Apache::TestMB suppress APXS warnings?

2004-12-21 Thread Joshua Hoblitt 
On Tue, 21 Dec 2004, Stas Bekman wrote:
Joshua Hoblitt wrote:
[This thread really belongs to the httpd-test list, since it has nothing to 
do with modperl]

[...]
Apache/1.3.33 (Unix) mod_perl/1.29 and I'm using 
Apache::Test/Apache::TestMB 1.17.

what code do you have in your tests that invokes those?

Any of the .t files that have use Apache::Test qw( -withtestmore ); in 
them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also 
displays a
number of APXS warnings at the begnning of the test run.

Here is the complete output of a test run:

APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
what do you get when running: /usr/local/apache/bin/apxs -q SBINDIR
$ /usr/local/apache/bin/apxs -q SBINDIR
apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server
apxs:Error: binary `/usr/local/apache/bin/httpd'.
Which doesn't matter since mod_perl isn't built as a DSO...
-J
--
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Can Apache::TestMB suppress APXS warnings?

2004-12-20 Thread Joshua Hoblitt 
Hi Folks,
I've been unable to figure out how to get Apache::TestMB to setup my build
environment in such a way as to suppress APXS warnings during a test run.  e.g.
--
t/10_client_newAPXS (/usr/local/apache/bin/apxs) query 
for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/10_client_newok
t/11_client_create.APXS (/usr/local/apache/bin/apxs) query 
for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/11_client_create.ok
t/12_client_replicate..APXS (/usr/local/apache/bin/apxs) query 
for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/12_client_replicate..ok
t/13_client_cull...APXS (/usr/local/apache/bin/apxs) query 
for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/13_client_cull...ok
--
Is it possible to silence these gratuitous warnings?
Cheers,
-J
--
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::DBI 0.94 - connect_on_init broken?

2004-12-14 Thread Joshua Hoblitt 
Hi Folks,
This is my first serious attempt at working with mod_perl so please excuse me
if this e-mail is a little naive.
I have a SOAP::Transport::HTTP::Apache application that makes fairly heavy use
of DBI.  I would like to use Apache::DBI so I don't have to write my own logic
for keep alives and reconnecting broken database handles.  Unfortunately, the
connect_on_init method does not seem to work for me.
When I place this snippet in my Apache configuration my database (MySQL)
reports that no database threads have been spawned.
--
PerlModule DBI
PerlModule Apache::DBI
.
.
perl
Apache::DBI-connect_on_init(
DBI:mysql:database=foo:host=localhost,
foo,
foo,
);
/perl
--
When I replace that with:
--
PerlModule My::Foo
.
.
perl
Apache-push_handlers(PerlChildInitHandler = sub {
   My::Foo-setup(
   DBI:mysql:database=foo:host=localhost,
   foo,
   foo,
   );
   }
);
/perl
--
Where -setup is creating a database handle and storing it in a package
variable.  The database reports 64 threads (the number of Apache children at
startup) active on the database.  This has left me completely puzzled as
Apache::DBI is also installing a PerChildInitHandler.
I'm running this with Perl 5.8.5 on Apache 1.3.33/mod_perl 1.29.
Any advice would be much appreciated.
Cheers,
-J
--
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::DBI 0.94 - connect_on_init broken?

2004-12-14 Thread Joshua Hoblitt 
After some experimentation, it seems that if I use load Apache::DBI while using
my own PerlChildInitHandler that indeed database connection that time out do
get reconnected (as expected).  I'm still at a loss as to why 'connect_on_init'
does not work for me.
Cheers,
-J
--
On Tue, 14 Dec 2004, Joshua Hoblitt wrote:
Hi Folks,
This is my first serious attempt at working with mod_perl so please excuse me
if this e-mail is a little naive.
I have a SOAP::Transport::HTTP::Apache application that makes fairly heavy 
use
of DBI.  I would like to use Apache::DBI so I don't have to write my own 
logic
for keep alives and reconnecting broken database handles.  Unfortunately, the
connect_on_init method does not seem to work for me.

When I place this snippet in my Apache configuration my database (MySQL)
reports that no database threads have been spawned.
--
PerlModule DBI
PerlModule Apache::DBI
.
.
perl
Apache::DBI-connect_on_init(
DBI:mysql:database=foo:host=localhost,
foo,
foo,
);
/perl
--
When I replace that with:
--
PerlModule My::Foo
.
.
perl
Apache-push_handlers(PerlChildInitHandler = sub {
My::Foo-setup(
DBI:mysql:database=foo:host=localhost,
foo,
foo,
;
  }
);
/perl
--
Where -setup is creating a database handle and storing it in a package
variable.  The database reports 64 threads (the number of Apache children at
startup) active on the database.  This has left me completely puzzled as
Apache::DBI is also installing a PerChildInitHandler.
I'm running this with Perl 5.8.5 on Apache 1.3.33/mod_perl 1.29.
Any advice would be much appreciated.
Cheers,
-J
--
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html