[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/Perl 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/
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
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 +-+
[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,
Steve
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 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]
RE: [OT] (apache question) Working around MaxClients?
You could defined a different port in your img 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:
img src="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]
[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 ("!--") that appears at the end of
the file, after the closing tag for the html element. The XSLT problem is
worse - it won't work at all. The process seems to loop and finally short
out.
Excuse me if I'm missing something obvious here. I'm still a bit green with
these things. :(
Any ideas what could be causing the problems? I'm guessing that the odd
opening comment effect is related to the $Response-End() call in the
"virtual" include in ssi_filter.ssi, but I'm at a loss as to what could be
causing the problems with the xslt.xml example.
Sincerely,
Scott Kearn
I have the current versions (according to CPAN) of all the modules included
in Bundle::Apache::ASP installed, and I'm using version 1.95.1 of Expat,
downloaded from the Sourceforge project site. The other required modules
that I have installed (and their versions) are as follows:
Apache::Filter - 1.016
Apache::SSI - 2.16
XML::Parser - 2.30
XML::DOM - 1.27
XML::XSLT - 0.32
And here's the debug log from the attempt at running the xslt.xml example.
Note that this is from /one/ request:
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.6310;0.] RUN ASP (v2.09) for
/usr/local/etc/httpd/htdocs/client/documentation/ApacheAsp/eg/xslt.xml
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.6487;0.0177] call srand() post fork
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.6496;0.0009] GlobalASA package Apache::ASP::Demo
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.6499;0.0003] global.asa was not cached for
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg___global_asa
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.6755;0.0256] compiling global.asa Apache::ASP::Demo
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg___global_asa
exists 1 - asp: Apache::ASP=HASH(0x82f8760); compiled: HASH(0x82f75c8);
exists: 1; id:
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg___global_asa;
package: Apache::ASP::Demo; - --- - exists: ; mtime: ;
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.7154;0.0399] global.asa routines - Application_OnEnd: 1;
Application_OnStart: 1; Script_OnEnd: 1; Script_OnFlush: 1; Script_OnStart:
1; Session_OnEnd: 1; Session_OnStart: 1;
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.7170;0.0016] parsing xslt.xml
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8030;0.0860] loaded module Apache::Symbol
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8035;0.0005] active undefing sub
Apache::ASP::Demo::_usr_local_etc_httpd_htdocs_client_documentation_ApacheAs
p_eg_xslt_xmlxDYN code CODE(0x82ee338)
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8039;0.0004] compiling into package Apache::ASP::Demo subid
Apache::ASP::Demo::_usr_local_etc_httpd_htdocs_client_documentation_ApacheAs
p_eg_xslt_xmlxDYN
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8072;0.0033] Script_OnStart
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8076;0.0004] executing Script_OnStart
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8082;0.0006] tieing response package for STDOUT
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8087;0.0005] executing
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg_xslt_xmlxDYN
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8202;0.0115] Script_OnEnd
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8206;0.0004] executing Script_OnEnd
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8211;0.0005] Script_OnFlush
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8214;0.0003] executing Script_OnFlush
[Fri Feb 23 02:10:55 2001] [error] [asp] [32023] [debug]
[982919455.8225;0.0011] xslt processing with template.xsl
[Fri Feb 23 02:10:58 2001] [error] [asp] [31744] [debug]
[982919458.1842;0.] RUN ASP (v2.09) for
/usr/local/etc/httpd/htdocs/client/documentation/ApacheAsp/eg/xslt.xml
[Fri Feb 23 02:10:58 2001] [error] [asp] [31744] [debug]
[982919458.1850;0.0008] call srand() post fork
[Fri Feb 23 02:10:58 2001] [error] [asp] [31744] [debug]
[982919458.1859;0.0009] GlobalASA package Apache::ASP::Demo
[Fri Feb 23 02:10:58 2001] [error] [asp] [31744] [debug]
[982919458.1863;0.0004] global.asa was not cached for
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg___global_asa
[Fri Feb 23 02:10:58 2001] [error] [asp] [31744] [debug]
[982919458.1890;0.0027] compiling global.asa Apache::ASP::Demo
_usr_local_etc_httpd_htdocs_client_documentation_ApacheAsp_eg___global_asa
exists 1 - asp: Apache::ASP=HASH(0x82f9760); compiled: HASH(0x82f75c8);
exists:
[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
[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
Location /mod_soap
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold = 1"
/Location
=item httpd.conf (Files), file-based access
FilesMatch "\.soap$"
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold = 1"
/FilesMatch
=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 Location, Directory, Files,
FilesMatch
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
Fexamples/server/mod_soap.htaccess 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/
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: Location / SetHandler perl-script PerlHandler Apache::TreeBrowser /Location 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 Location / into a Location /tree, 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/
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 ("!--") that appears at the end of
the file, after the closing tag for the html element. The XSLT problem is
worse - it won't work at all. The process seems to loop and finally short
out.
Would you please send me separately the output of the HTML, and the
source file itself for the ssi example. I thought I fixed a bug in
there but perhaps not. Actually, if you'd like, I'll email you separately
my dev 2.11 release which may fix your SSI problem, as the content length
was being set when it shouldn't be in 2.09 while filtering, and this may
be the issue, especially if viewing in IE I believe.
Excuse me if I'm missing something obvious here. I'm still a bit green with
these things. :(
You have done remarkably to get this far!
Any ideas what could be causing the problems? I'm guessing that the odd
opening comment effect is related to the $Response-End() call in the
"virtual" include in ssi_filter.ssi, but I'm at a loss as to what could be
causing the problems with the xslt.xml example.
For XML::XSLT, I would recommend sticking with the .24 release from the
Bundle::XML, or which you can download from the SourceForge site
for it. Sorry no URL handy. The issue seems that the new XML::XSLT
module maintainer has harshly deprecated the old API I used, and
may have broken some things in the process. I found .32 not to work
on my own Linux box, where .24 still does.
I will need to rewrite the XSLT interface for Apache::ASP for the
lastest XML::XSLT, and while I'm at it, I think I will be adding
support for XML::Sablotron, for those that need the speed. I may
also add a caching layer to keep the pace up, as XSLT tends to
be rather slow. I had a Tie::Cache RAM cache before, and I'll
likely add a file based cache instead as that is more appropriate
for these kinds of large slow data sets.
--Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
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
Location /mod_soap
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold = 1"
/Location
=item httpd.conf (Files), file-based access
FilesMatch "\.soap$"
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to "/Your/Path/To/Deployed/Modules,
Module::Name, Module::method"
PerlSetVar options "compress_threshold = 1"
/FilesMatch
=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 Location, Directory, Files,
FilesMatch
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
Fexamples/server/mod_soap.htaccess for .htaccess example
=head1 COPYRIGHT
Copyright (C) 2000-2001 Paul Kulchenko. All rights reserved.
This library is free software; you
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/
