Re: FileMan core dump
At 05:39 PM 2/24/2001 -1100, you wrote: >But, when I add teh line to my httpd.conf file: > >PerlModule Apache::FileMan; > >(the PerlModule Apache::Icon; directive is ok, just comment out >the PerlModule Apache::FileMan and OK, comment it in, and coredump.) > >The Apache server will coredump when you try to start it. >The server also coredumps on the '-t' test conf file syntax switch. >Eg: /usr/sbin/httpd -DHAVE_PERL -t > >Using Redhat 7.2, apache 1.3.12 > Do you have mod_perl staticly linked? I use to have mod_perl loaded as a DSO with simular results. Was your Apache, Perl (what version?), and mod_perl (what version?) built from source code all using the same compiler?
Re: [ANNOUNCE] Apache::SOAP 0.47 (mod_soap)
Hi, Gunther! --- Gunther Birznieks <[EMAIL PROTECTED]> wrote: > Hmmm, I am under the impression that the DevelopMentor stuff has a > mod_perl > SOAP Handler (although I was never able to get it to work) so > calling this > one Apache::SOAP in the official name space seems a difficult sell > unless That's true, DM's SOAP module has mod_perl handler, but it's under SOAP::Transport::HTTP::Apache namespace, and SOAP::Lite has also Apache module under the same namespace, but it's just server implementation, and Apache::SOAP's goal is to provide easy access to implementation from configuration files (it is actually subclass of SOAP::Transport::HTTP::Apache). > you are dedicated to supporting the full SOAP API (not sure what > SOAP::Lite leaves out). First thing I did seven months ago was my email to Keith Brown (author of DM's SOAP/Perl module) about possible ways for cooperation and I'v been told that he's willing to, but design of his module should be consistent with other DM's implementations and he has no plans to change it. There was no easy way to combine our efforts and I came up with another implementation. Don't want to praise myself, but feature set seems to be pretty comparable with other toolkits. I took ::Lite, just because SOAP namespace was already taken. It does much more than you can expect from something with suffix Lite. "Lite suffix reflects number of calories you should spend using this module". > In that case, maybe you should call it Apache::SOAP::Lite rather > than Apache::SOAP I thought about it, and in fact I released UDDI::Lite, but I also plan to release DBD::SOAP, DBIx::SOAP and couple of other modules and don't want to put suffix Lite everywhere, it could lead to confusion. Also I don't think (IMHO) that DevelopMentor will ever support their module, since they abandon SOAP development in Java, C++ and Perl and there is no other SOAP modules in Perl and I don't have plans to stop development any time soon. Moreover, I have a long TODO list :). > find out about your SOAP::Lite module and vice versa. It's like > getting two directory entries for the price of one. :) Cool :) > The annoying thing about breaking it out in its own module is that > you > might be tying Apache::SOAP tightly to the version of SOAP::Lite. > If you > consistently release new versions of both at the same time, then it > will be > a pain for people to constantly know they have two packages to > download instead of one (although I guess it can be bundled). Right, but there is no module specific code (it basically parameters parsing), so I think I'll keep it inside SOAP::Lite for one more version and then release as mod_soap. > Another positive thing about keeping the bundle under SOAP::Lite is > that > you might consider releasing SOAP::Lite server code for other > persistent > engines like PerlEx, Velocigen, SpeedyCGI, etc... and you could It works actually with Velocigen and as far as I understand with PerlEx also, but I don't have any information about SpeedyCGI. It also provides Daemon, TCP, CGI, IO, POP3 interfaces on server side (in addition to mod_perl and Apache::Registry) as well as COM interface and (hm, did I say already that I don't want to praise myself?) > And hopefully these comments will help you decide for yourself what > you'd like to do. Definitely, thanks a lot. Best wishes, Paul. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [ANNOUNCE] Apache::SOAP 0.47 (mod_soap)
Hmmm, I am under the impression that the DevelopMentor stuff has a mod_perl
SOAP Handler (although I was never able to get it to work) so calling this
one Apache::SOAP in the official name space seems a difficult sell unless
you are dedicated to supporting the full SOAP API (not sure what SOAP::Lite
leaves out).
In that case, maybe you should call it Apache::SOAP::Lite rather than
Apache::SOAP
The benefit of breaking out Apache::SOAP(::Lite) into its own CPAN module
is that it will be easier for people to find your module. People who see
the APache::* module list and are looking for SOAP will say "Ah ha!" and
find out about your SOAP::Lite module and vice versa. It's like getting two
directory entries for the price of one. :)
The annoying thing about breaking it out in its own module is that you
might be tying Apache::SOAP tightly to the version of SOAP::Lite. If you
consistently release new versions of both at the same time, then it will be
a pain for people to constantly know they have two packages to download
instead of one (although I guess it can be bundled).
Another positive thing about keeping the bundle under SOAP::Lite is that
you might consider releasing SOAP::Lite server code for other persistent
engines like PerlEx, Velocigen, SpeedyCGI, etc... and you could eventually
add drivers for these in the one package and presumably add SOAP Server
code that is shared amongst all the servers instead of breaking them out in
different packages.
Anyway, all I am saying is that in reply to your question about breaking
out Apache::SOAP is ...
"It depends".
And hopefully these comments will help you decide for yourself what you'd
like to do.
Thanks,
Gunther
At 12:42 PM 2/23/2001 -0800, Paul Kulchenko wrote:
>Apache::SOAP provides SOAP server functionality by simply adding
>couple of line in .htaccess or .conf file. Based on SOAP::Lite
>module, hence inherits all functionality, like, for example,
>compression on wire introduced in last version. For now released as
>part of SOAP::Lite module.
>Is there any value to ship it separately (probably as a mod_soap)?
>
>Module is available from www.soaplite.com or CPAN.
>
>Documentation and examples are included. Any comments are very
>welcome.
>
>Best wishes, Paul.
>
>=head1 NAME
>
>Apache::SOAP - Provide SOAP server functionality with simple
>configuration
>
>=head1 SYNOPSIS
>
>=over 4
>
>=item httpd.conf (Location), directory-based access
>
>
> SetHandler perl-script
> PerlHandler Apache::SOAP
> PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
>Module::Name, Module::method"
> PerlSetVar options "compress_threshold => 1"
>
>
>=item httpd.conf (Files), file-based access
>
>
> SetHandler perl-script
> PerlHandler Apache::SOAP
> PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
>Module::Name, Module::method"
> PerlSetVar options "compress_threshold => 1"
>
>
>=item .htaccess, directory-based access
>
> SetHandler perl-script
> PerlHandler Apache::SOAP
> PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
>Module::Name, Module::method"
> PerlSetVar options "compress_threshold => 1"
>
>=back
>
>=head1 DESCRIPTION
>
>This Apache Perl module provides the ability to add support for SOAP
>(Simple
>Object Access Protocol) protocol with easy configuration (either
>in .conf or
>in .htaccess file). This functionality should give you lightweight
>option
>for hosting SOAP services and greatly simplify configuration aspects.
>
>This
>module inherites functionality from SOAP::Transport::HTTP::Apache
>component
>of SOAP::Lite module.
>
>=head1 CONFIGURATION
>
>The module can be placed in , , ,
>
>directives in main server configuration areas or directly
>in .htaccess file.
>
>All parameters should be quoted and can be separated with commas or
>spaces
>for lists ("a, b, c") and with 'wide arrows' and commas for hash
>parameters
>("key1 => value1, key2 => value2").
>
>All options that you can find in SOAP::Transport::HTTP::Apache
>component
>are available for configuration. Here is the description of most
>important
>ones.
>
>=over 4
>
>=item dispatch_to (LIST)
>
>Specifies path to directory that contains Perl modules you'd like to
>give
>access to, or just list of modules (for preloaded modules).
>
> PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
>Module::Name, Module::method"
>
>=item options (HASH)
>
>Specifies list of options for your module, for example threshold for
>compression. Future versions will support more options. See
>SOAP::Transport::HTTP documentation for other options.
>
> PerlSetVar options "compress_threshold => 1"
>
>=back
>
>=head1 DEPENDENCIES
>
> SOAP::Lite
> mod_perl
>
>=head1 SEE ALSO
>
> SOAP::Transport::HTTP::Apache for implementation details,
> SOAP::Lite for general information, and
> F for .htaccess example
>
>=head1 COPYRIGHT
>
>Copyright (C) 2000-2001 Paul Kulchenko. All rights reserved.
>
>This library is free softwar
Re: [Apache::ASP] Problems with SSI and XSLT
"S.tygian B.lacksmith S.tudios" wrote:
>
> Hello,
>
> I've been having some troubles with the SSI and XSLT examples in the /eg/
> directory in my Apache::ASP installation: the SSI example works to a point,
> but there's an extra opening comment tag ("
path_info *again*! help!!!
So I have this very clean Red Hat 7.0 system: [root@tetine httpd]# rpm -V apache mod_perl [root@tetine httpd]# I download the Apache::TreeBrowser module from http://modperl.com/ and put the TreeBrowser.pm file in /etc/httpd/Apache (which I just created). At the very end of /etc/httpd/conf/httpd.conf, I add the following four lines: SetHandler perl-script PerlHandler Apache::TreeBrowser I restart my web server (with "/etc/init.d/httpd restart"), wait a little, then go fiddle with it. *** It doesn't work. *** The first part of path_info is "eaten" somewhere. Let me explain: If I start at the root (http://127.0.0.1/), everything looks fine, path_info is "/". I click on "bark". Now it's not fine, path_info still says "/", URL says "/bark/" (just like my location bar in my browser) and the web page says that I am at the "Tree Root" node. Now, if I click *again* on "bark", I am now at /bark/bark/, the path_info is "/bark/", the URL is "/bark/bark/" and the web page says that I am at the "bark" node. The translated path says /var/www/html/bark, even though there is no such directory, of course. Now for the most interesting: If I change the into a , EVERYTHING IS FINE. So this seems to be an exceptional case that happens only at /!?! So what's going on here?!? -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
[ANNOUNCE] Apache::SOAP 0.47 (mod_soap)
Apache::SOAP provides SOAP server functionality by simply adding
couple of line in .htaccess or .conf file. Based on SOAP::Lite
module, hence inherits all functionality, like, for example,
compression on wire introduced in last version. For now released as
part of SOAP::Lite module.
Is there any value to ship it separately (probably as a mod_soap)?
Module is available from www.soaplite.com or CPAN.
Documentation and examples are included. Any comments are very
welcome.
Best wishes, Paul.
=head1 NAME
Apache::SOAP - Provide SOAP server functionality with simple
configuration
=head1 SYNOPSIS
=over 4
=item httpd.conf (Location), directory-based access
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold => 1"
=item httpd.conf (Files), file-based access
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold => 1"
=item .htaccess, directory-based access
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold => 1"
=back
=head1 DESCRIPTION
This Apache Perl module provides the ability to add support for SOAP
(Simple
Object Access Protocol) protocol with easy configuration (either
in .conf or
in .htaccess file). This functionality should give you lightweight
option
for hosting SOAP services and greatly simplify configuration aspects.
This
module inherites functionality from SOAP::Transport::HTTP::Apache
component
of SOAP::Lite module.
=head1 CONFIGURATION
The module can be placed in , , ,
directives in main server configuration areas or directly
in .htaccess file.
All parameters should be quoted and can be separated with commas or
spaces
for lists ("a, b, c") and with 'wide arrows' and commas for hash
parameters
("key1 => value1, key2 => value2").
All options that you can find in SOAP::Transport::HTTP::Apache
component
are available for configuration. Here is the description of most
important
ones.
=over 4
=item dispatch_to (LIST)
Specifies path to directory that contains Perl modules you'd like to
give
access to, or just list of modules (for preloaded modules).
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
=item options (HASH)
Specifies list of options for your module, for example threshold for
compression. Future versions will support more options. See
SOAP::Transport::HTTP documentation for other options.
PerlSetVar options "compress_threshold => 1"
=back
=head1 DEPENDENCIES
SOAP::Lite
mod_perl
=head1 SEE ALSO
SOAP::Transport::HTTP::Apache for implementation details,
SOAP::Lite for general information, and
F for .htaccess example
=head1 COPYRIGHT
Copyright (C) 2000-2001 Paul Kulchenko. All rights reserved.
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=head1 AUTHOR
Paul Kulchenko ([EMAIL PROTECTED])
=cut
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
[ANNOUNCE] ApacheBench 0.60
The uploaded file
ApacheBench-0.60.tar.gz
has entered CPAN as
file: $CPAN/authors/id/A/AD/ADIRAJ/ApacheBench-0.60.tar.gz
size: 51190 bytes
md5: e2325d7f89e32fecb6f76643ae38f7ed
No action is required on your part
Request entered by: ADIRAJ (Adi Fairbank)
Request entered on: Fri, 23 Feb 2001 20:03:29 GMT
Request completed: Fri, 23 Feb 2001 20:04:51 GMT
Significant new features since 0.52:
- much better OO API
- new memory level setting to store only certain information
about each regression run (meant to reduce memory usage)
- customizable Content-type: headers in http requests
(need content type "text/xml" for soap and xml/rpc)
NAME
HTTPD::Bench::ApacheBench - Perl API for Apache
benchmarking and regression testing.
SYNOPSIS
use HTTPD::Bench::ApacheBench;
my $b = HTTPD::Bench::ApacheBench->new;
# global configuration
$b->concurrency(5);
$b->priority("run_priority");
# add HTTP request sequences (aka: runs)
my $run1 = HTTPD::Bench::ApacheBench::Run->new
({ urls => ["http://localhost/one", "http://localhost/two"] });
$b->add_run($run1);
# send HTTP request sequences to server and time responses
my $ro = $b->execute;
# calculate hits/sec
print (1000*$b->total_requests/$b->total_time)." req/sec\n";
GOALS
This project is meant to be the foundation of a complete
benchmarking and regression testing suite for an advanced,
transaction-based mod_perl site. We need to be able to
stress our server to its limit while also having a way to
verify the HTTP responses for correctness. Since our site
is transaction-based (as opposed to content-based), we
needed to extend the single-URL ab model to a multiple-URL
sequence model.
ApacheBench is based on the Apache 1.3.12 ab code
(src/support/ab.c).
...
see the pod for full documentation
[Apache::ASP] Problems with SSI and XSLT
Hello,
I've been having some troubles with the SSI and XSLT examples in the /eg/
directory in my Apache::ASP installation: the SSI example works to a point,
but there's an extra opening comment tag ("
RE: [OT] (apache question) Working around MaxClients?
You could defined a different port in your tags. Then you can start
thttpd to bind to that port. You shouldn't have a problem binding to ports
higher that 1024(?) I think. Unless they have done something to prevent
this which is doubtful.
Example:
http://www.foo.com:/test/test.gif">
Unfortunately it could mean changing lots of code on your site. Of course,
you could use something like Apache::filter to alter your image tags on the
way out. I don't think this would be a difficult issue though. The main
thing is if you can bind to ports over 1024.
> > I have a high traffic website (looks like 200 GB output per month,
> > something around 10-20 hits per day) hosted on a commercial
> > service. The service does not limit my bandwidth usage, but
> they limit the
> > number of concurrent Apache process that I can have to 41. This
> causes the
> > server to delay accepting new connections during peak times.
> > My account is a "virtual server"; what this means is that I
> have access to
> > the Apache httpd.conf files and can restart the Apache daemon,
> but do not
> > have the priviledge to bind a program to port 80 (so I can't
> put thttpd on
> > port 80).
Stathy Touloumis
Coder
if ( eval{ $you => require Perl } ) { $you = '?3r1 H@c|<3r' }
Edventions
8800 Bronx Ave
Skokie, IL 60077
www.edventions.com
[EMAIL PROTECTED]
RE: [bug] PerlModule reloads modules twice on start
I noticed this behavior as well. > I've noticed an inconcistency between PerlModule and use() (and > PerlRequire and require()).
Re: [AIX] [gsar@ActiveState.com: v5.6.1 trial2 is available]
On Fri, Feb 23, 2001 at 12:11:41PM +0100, [EMAIL PROTECTED] wrote:
> > to import symbols from the main program. The patch already does that in
> > makedef.pl for the perl.exp file, but only on AIX 4.3 and above because
> > the older AIX linkers do strange things if this option is used.
>
> I tried your patch on v5.6.1 trial2. It built and the resulting perl
> passed all its tests.
>
> However when I try to use this perl to build mod_perl, it doesn't
> even succeed in performing the configuration. I use the
> following configuration command:
>
> /usr/local/bin/perl5.6.1 Makefile.PL \
> USE_APXS=1 WITH_APXS=/usr/local/bin/apxs \
> PERL_USELARGEFILES=0
I have not used the APXS configuration method for a long time (due to
the inherent memory leaks it has), so I could imagine that a problem is
still lurking here. Could you try if the normal APACI mathod works? For
example:
perl Makefile.PL EVERYTHING=1 DO_HTTPD=1 USE_APACI=1 \
APACI_ARGS="--enable-module =most --enable-shared=max \
--disable-shared=perl --disable-shared=include"
> The only thing I can imagine is that the "new" perl is
> trying to open modules in the 5.6.0 or 5.5.3 site_perl subdirectories,
> and that there is an incompatibility with the link options. But I can't
> imagine what that incompatibility is.
It is the probably the import file with a dot thing ("#! ."), the
emulation I did in the past handled that differently. The dot thing
means importing from the main program, whereas before without the dot it
meant import later by use of the loadbind() system call explicetely. But
the native dlopen from AIX does not use loadbind(), so the old plug-ins
references back into the main part do not get resolved.
--
Jens-Uwe Mager
HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany
Phone: +49 5131 709320
FAX:+49 5131 709325
Internet: [EMAIL PROTECTED]
[OT] Re: Just learning, and a little stuck...
Yes, this doesn't belong on this list.
But: Couple of immediate problems:
- If you pass a hash in an argument list, it gets inserted into the list
as just a sequence of key,value pairs -- there's no way in the subroutine
to determine that a hash was passed, as opposed to a simple list, or an
array. You *can* pass it the way you're doing in your first example
(since the final thing you're taking off the argument list in the
subroutine is the hash), but I think most perl folks would agree that the
second example (passing a hash reference) is better form.
Obviously, this depends upon the semantics of the function you're
writing.
- 'shift' shifts one item off a list. You seem to be inferring that it
will shift off as many as needed -- you can just use a list assignment,
if that's what you want to do.
I think you want one of these options:
&join( $db, \%post);
sub join {
my ($db, $post_ref) = @_;
foreach $key (keys %$post_ref) {
or:
&join( $db, %post);
sub join {
my ($db, %post) = @_;
foreach $key (keys %post) {
No, you definitely want to limit yourself from using 'local' until you
understand the semantic differences between it and 'my'. 'Effective Perl
Programming', by Joseph Hall has a nice description of this.
HTH,
On Fri, 23 Feb 2001, Alec Smith wrote:
> This isn't specifically a mod_perl question, but something I'm having
> trouble doing within mod_perl code. I'm far from a Perl expert, but I
> try...
>
> I've got a hash called %post which contains submitted form info and a
> variable $db which is the result of a DBI->connect call. I need to take
> these 2 values and pass them into a subroutine. I've tried something like
>
> &join($db, %post);
>
> sub join
> {
>my ($db, %post) = shift (@_);
>...
>
>foreach $key (keys(%post))
>{
> ...
>}
> }
>
> and
>
> &join ($db, \%post);
>
> sub join
> {
> my ($db, $post) = shift (@_);
>
> foreach $key (keys(%$post))
> {
> %$post{$key} = $db->quote("%$post{$key}");
> }
> }
>
> Using CGI-based Perl I suppose I could just use local() instead of my()
> to avoid having to pass arguments, but didn't think this would be
> advisable in mod_perl code.
>
> How can I manage to do what I'm trying to do?
>
>
> Alec
>
>
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
Re: [AIX] [gsar@ActiveState.com: v5.6.1 trial2 is available]
On Wed, 21 Feb 2001, Jens-Uwe Mager wrote: Hi Jum ;-), > to import symbols from the main program. The patch already does that in > makedef.pl for the perl.exp file, but only on AIX 4.3 and above because > the older AIX linkers do strange things if this option is used. I tried your patch on v5.6.1 trial2. It built and the resulting perl passed all its tests. However when I try to use this perl to build mod_perl, it doesn't even succeed in performing the configuration. I use the following configuration command: /usr/local/bin/perl5.6.1 Makefile.PL \ USE_APXS=1 WITH_APXS=/usr/local/bin/apxs \ PERL_USELARGEFILES=0 No error messages are dispayed, the configuration just stops. When I add a -w to the options I get 2 warnings: PerlSSI.disabled (enable with PERL_SSI=1) Use of uninitialized value in hash element at Makefile.PL line 1654. Use of uninitialized value in hash element at Makefile.PL line 1654. Configuring mod_perl for building via APXS + Creating a local mod_perl source tree + Setting up mod_perl build environment (Makefile) + id: mod_perl/1.25 + id: Perl/v5.6.1 (aix) [/usr/local/bin/perl5.6.1] Now please type 'make' to build libperl.so Use of uninitialized value in hash element at Makefile.PL line 1654. Use of uninitialized value in numeric ge (>=) at Makefile.PL line 1058. # but with perl5.6.0 I also get these warnings: PerlSSI.disabled (enable with PERL_SSI=1) Use of uninitialized value in hash element at Makefile.PL line 1654. Use of uninitialized value in hash element at Makefile.PL line 1654. Configuring mod_perl for building via APXS + Creating a local mod_perl source tree + Setting up mod_perl build environment (Makefile) + id: mod_perl/1.25 + id: Perl/v5.6.0 (aix) [/usr/local/bin/perl5.6.0] Now please type 'make' to build libperl.so Use of uninitialized value in hash element at Makefile.PL line 1654. Use of uninitialized value in numeric ge (>=) at Makefile.PL line 1058. Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok . Perl5.6.0 completes the configuration normally. The only thing I can imagine is that the "new" perl is trying to open modules in the 5.6.0 or 5.5.3 site_perl subdirectories, and that there is an incompatibility with the link options. But I can't imagine what that incompatibility is. Bye Ciaran +-+ Ciaran DeignanTel: (France) 04 76 29 79 92 BULL XS-BU (http://www-frec.bull.com) HA and Consolidation Mail to: [EMAIL PROTECTED]Bullcom: 229 79 92 PGP: B1 78 FB 88 FD 86 58 A8 89 7B 22 8C D0 E8 71 FC Fax: 229 75 18 +-+
Just learning, and a little stuck...
This isn't specifically a mod_perl question, but something I'm having
trouble doing within mod_perl code. I'm far from a Perl expert, but I
try...
I've got a hash called %post which contains submitted form info and a
variable $db which is the result of a DBI->connect call. I need to take
these 2 values and pass them into a subroutine. I've tried something like
&join($db, %post);
sub join
{
my ($db, %post) = shift (@_);
...
foreach $key (keys(%post))
{
...
}
}
and
&join ($db, \%post);
sub join
{
my ($db, $post) = shift (@_);
foreach $key (keys(%$post))
{
%$post{$key} = $db->quote("%$post{$key}");
}
}
Using CGI-based Perl I suppose I could just use local() instead of my()
to avoid having to pass arguments, but didn't think this would be
advisable in mod_perl code.
How can I manage to do what I'm trying to do?
Alec
[bug] PerlModule reloads modules twice on start
I've noticed an inconcistency between PerlModule and use() (and
PerlRequire and require()).
When Apache starts, it immediately restarts itself to see whether it can
sustain the reload. So when you have
PerlModule Apache::Registry
you will see:
Subroutine handler redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 27.
Subroutine compile redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 174.
Subroutine parse_cmdline redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 190.
but if you have:
use Apache::Registry;
in startup.pl/ sections, Perl won't reload the files, since they are
already in %INC.
So it looks to me that Perl{Module|Require} directives should check %INC,
before execute the load.
This behavior is seen under Perl 5.6.x (apache 1.3.17 /mod_perl-1.25). I
think that I didn't see it under 5.005_03.
And Matt, as I've told you before that I saw:
Subroutine import redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 15.
Subroutine package_to_module redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 22.
Subroutine register_module redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 29.
Subroutine handler redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 48.
It has nothing to do with Apache::Reload.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
