Re: [Problem] Can't return Content-type with SERVER_ERROR
Hi, Stas!
i think you want to use err_headers_out() instead.
http://www.modperl.com/book/chapters/ch9.html#Server_Response_Methods
Thanks for the help, but it seems like I'm using it already:
$self-response-headers-scan(sub { $r-err_header_out(@_) });
# ---^^
$r-content_type(join '; ', $self-response-content_type);
$r-custom_response($self-response-code,
$self-response-content);
it's the same as to use err_headers_out as far as I understand. What
is the general procedure to generate custom content-type along with
SERVER_ERROR?
sub handler {
...
$r-content_type('text/xml; charset=utf-8');
$r-custom_response($self-response-code,
$self-response-content);
$self-response-code;
}
doesn't work if '$self-response-code' is 500. mod_perl overrides my
content-type with text/html.
Best wishes, Paul.
--- Stas Bekman [EMAIL PROTECTED] wrote:
On Sun, 29 Jul 2001, Paul Kulchenko wrote:
Hi, All!
Code is simple, but I can't return custom content-type with
SERVER_ERROR:
sub handler {
. $self-response is HTTP::Response object
if ($self-response-is_success) {
$self-response-headers-scan(sub { $r-header_out(@_) });
$r-send_http_header(join '; ',
$self-response-content_type);
$r-print($self-response-content);
} else {
$self-response-headers-scan(sub { $r-err_header_out(@_)
});
$r-content_type(join '; ', $self-response-content_type);
$r-custom_response($self-response-code,
$self-response-content);
}
$self-response-code;
}
i think you want to use err_headers_out() instead.
http://www.modperl.com/book/chapters/ch9.html#Server_Response_Methods
In ALL cases (200OK and 500ServerError) I need to return error
code,
content, content-type and optional headers.
Regardless of my settings content-type is always text/html;
charset=iso-8859-1 which I expect to be text/xml;
charset=utf-8:
HTTP/1.1 500 Internal Server Error
Connection: close
Date: Sun, 29 Jul 2001 16:01:20 GMT
Server: Apache/1.3.12 (Win32) mod_perl/1.23
Content-Length: 642
Content-Type: text/html; charset=iso-8859-1
Client-Date: Sun, 29 Jul 2001 16:01:22 GMT
Client-Peer: 127.0.0.1:80
SOAPServer: SOAP::Lite/Perl/0.51
?xml version=1.0 encoding=UTF-8?SOAP-ENV:Envelope
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsi=http://www.w3.org/1999/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;SOAP-ENV:BodySOAP-ENV:Faultfaultcode
xsi:type=xsd:stringSOAP-ENV:Client/faultcodefaultstring
xsi:type=xsd:stringFailed to locate method (echo1) in class
(My::Parameters) at C:/Perl/site/5.6.0/lib/SOAP/Lite.pm line
1997.
/faultstring/SOAP-ENV:Fault/SOAP-ENV:Body/SOAP-ENV:Envelope
What am I doing wrong and what is the correct way to specify
custom
content-type? Everything works fine with 200OK. Thanks a lot.
Best wishes, Paul.
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo!
Messenger
http://phonecard.yahoo.com/
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org
http://perlmonth.com/
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
RE: [Problem] Can't return Content-type with SERVER_ERROR
Hi, Geoffrey!
your procedure is correct. well, except that you can't do what you
want :)
take a look at http_protocol.c -
'r-content_type = text/html; charset=iso-8859-1;' is hardcoded
in ap_send_error_response(), so it's an apache thing and not a
mod_perl thing...
Absolutely true to my surprise. That means you can't return proper
content-type and content-encoding with non-OK codes, Apache will
rewrite it for you anyway, which is too human-oriented and imho
should be corrected. I ended up generating usual successful response
with custom status (which is 500 in my case):
$r-status($self-response-code);
$self-response-headers-scan(sub { $r-header_out(@_) });
$r-send_http_header(join '; ', $self-response-content_type);
$r-print($self-response-content);
Apache::Constants::OK;
Probably worth mentioning in FAQ or somewhere. It took quite a bit of
my time.
Best wishes, Paul.
--- Geoffrey Young [EMAIL PROTECTED] wrote:
-Original Message-
From: Paul Kulchenko [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 2:53 AM
To: Stas Bekman
Cc: [EMAIL PROTECTED]
Subject: Re: [Problem] Can't return Content-type with
SERVER_ERROR
[snip]
it's the same as to use err_headers_out as far as I understand.
What
is the general procedure to generate custom content-type along
with
SERVER_ERROR?
sub handler {
...
$r-content_type('text/xml; charset=utf-8');
$r-custom_response($self-response-code,
$self-response-content);
$self-response-code;
}
doesn't work if '$self-response-code' is 500. mod_perl
overrides my
content-type with text/html.
your procedure is correct. well, except that you can't do what you
want :)
take a look at http_protocol.c -
'r-content_type = text/html; charset=iso-8859-1;' is hardcoded
in
ap_send_error_response(), so it's an apache thing and not a
mod_perl
thing...
HTH
--Geoff
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
[Problem] Can't return Content-type with SERVER_ERROR
Hi, All!
Code is simple, but I can't return custom content-type with
SERVER_ERROR:
sub handler {
. $self-response is HTTP::Response object
if ($self-response-is_success) {
$self-response-headers-scan(sub { $r-header_out(@_) });
$r-send_http_header(join '; ', $self-response-content_type);
$r-print($self-response-content);
} else {
$self-response-headers-scan(sub { $r-err_header_out(@_) });
$r-content_type(join '; ', $self-response-content_type);
$r-custom_response($self-response-code,
$self-response-content);
}
$self-response-code;
}
In ALL cases (200OK and 500ServerError) I need to return error code,
content, content-type and optional headers.
Regardless of my settings content-type is always text/html;
charset=iso-8859-1 which I expect to be text/xml; charset=utf-8:
HTTP/1.1 500 Internal Server Error
Connection: close
Date: Sun, 29 Jul 2001 16:01:20 GMT
Server: Apache/1.3.12 (Win32) mod_perl/1.23
Content-Length: 642
Content-Type: text/html; charset=iso-8859-1
Client-Date: Sun, 29 Jul 2001 16:01:22 GMT
Client-Peer: 127.0.0.1:80
SOAPServer: SOAP::Lite/Perl/0.51
?xml version=1.0 encoding=UTF-8?SOAP-ENV:Envelope
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsi=http://www.w3.org/1999/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;SOAP-ENV:BodySOAP-ENV:Faultfaultcode
xsi:type=xsd:stringSOAP-ENV:Client/faultcodefaultstring
xsi:type=xsd:stringFailed to locate method (echo1) in class
(My::Parameters) at C:/Perl/site/5.6.0/lib/SOAP/Lite.pm line 1997.
/faultstring/SOAP-ENV:Fault/SOAP-ENV:Body/SOAP-ENV:Envelope
What am I doing wrong and what is the correct way to specify custom
content-type? Everything works fine with 200OK. Thanks a lot.
Best wishes, Paul.
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
[ANNOUNCE] SOAP::Lite 0.51 (mod_soap and mod_xmlrpc included)
New version of SOAP::Lite has entered CPAN. number of fixes related to different Perl version and platforms number of fixes in XMLRPC::Lite fixed POP3 server added support for SOAP 1.2 (spec is still in draft, implementation is subject to change) added mod_xmlrpc transport (Apache::XMLRPC::Lite) added JABBER transport added MQ transport added TCP over SSL transport added non-blocking TCP multiserver included FastCGI transport modified XML::Parser::Lite to work on Perl 5.005 modified deserializer to work with different schemas (1999/2001) added extended array support (only in deserializer) improved WSDL support modified dispatch for XMLRPC server to work exactly as for SOAP added example with Inline::C module (inline.daemon). Dispatch to C, C++, assembler, Java, Python and Tcl :). all transport are available for both SOAP::Lite and XMLRPC::Lite: HTTP (daemon, CGI, mod_perl), SMTP/POP3, TCP, IO, JABBER, MQ tested on Perl 5.00503, 5.6.0, 5.6.1, 5.7.1 and 5.7.2 updated documentation and added new examples Module is available from http://www.soaplite.com/ and from CPAN. I'll be in SanDiego next week and will answer my emails slowly. Best wishes, Paul. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: [ANNOUNCE] SOAP::Lite 0.51 (mod_soap and mod_xmlrpc included)
Hi, Matt!
Dunno if you got my email, but I'd like to see the ability to
dynamically
modify the dispatch tables. At the moment I'm doing it as a hack
into your SOAP::Lite internals.
Sure, I replied the same day (July 13). Recently I had a problem with
my yahoo mail, so I sent you short mail asking whether you got my
reply :)). I though you're busy to answer :)). Fortunately I have a
copy. Here it is.
--- Paul Kulchenko [EMAIL PROTECTED] wrote:
Date: Fri, 13 Jul 2001 10:19:24 -0700 (PDT)
From: Paul Kulchenko [EMAIL PROTECTED]
Subject: Re: adding to dispatch_to
To: Matt Sergeant [EMAIL PROTECTED]
Hi, Matt!
Is there any way I can call dispatch_to, and *add* to the list,
rather than
change it? I'm building Attribute::WebService, where you'll be
able
to say:
sub foo : WebService { ... }, and have it automatically create a
That's so CL! That actually means that we can not only generate
server code (ot simplify it), but also build WebService description
(WSDL) from it. In fact, I was going to talk to you about taglib
for
Axkit that supports SOAP functionality, but I already delayed next
version and want to make a release in a couple of days. Yet we can
definitely talk about it if you're interested.
As for dispatch_to call, you can always do:
$server-dispatch_to($server-dispatch_to, @module_list);
Keep also in mind that dispatching can be done with dispatch_with()
also (which lets you bind specific namespace or SOAPAction to CLASS
or object).
Let me know if you face any problems or if you want to test it with
my current beta. There are many changes, and though they shouldn't
have any influence on this side, we can try just to be on the safe
side. Thanks, Matt, I'm very excited about it. I also plan to use
Attribute::* for providing type/name (instead of using SOAP::Data),
but as far as I know Attribute class is Perl 5.6 and later and I
still want to support 5.004 if possible.
Best wishes, Paul.
Let me know what do you think and we definitely should talk in
SanDiego. Also I didn't find Attribute::WebService on CPAN yet. I
would be glad also to work on SOAP-enabling taglib library and on
better COM integration. Thanks, Matt!
Best wishes, Paul.
--- Matt Sergeant [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2001, Paul Kulchenko wrote:
New version of SOAP::Lite has entered CPAN.
number of fixes related to different Perl version and platforms
number of fixes in XMLRPC::Lite
fixed POP3 server
added support for SOAP 1.2
(spec is still in draft, implementation is subject to change)
added mod_xmlrpc transport (Apache::XMLRPC::Lite)
added JABBER transport
added MQ transport
added TCP over SSL transport
added non-blocking TCP multiserver
included FastCGI transport
modified XML::Parser::Lite to work on Perl 5.005
modified deserializer to work with different schemas (1999/2001)
added extended array support (only in deserializer)
improved WSDL support
modified dispatch for XMLRPC server to work exactly as for SOAP
added example with Inline::C module (inline.daemon).
Dispatch to C, C++, assembler, Java, Python and Tcl :).
all transport are available for both SOAP::Lite and XMLRPC::Lite:
HTTP (daemon, CGI, mod_perl), SMTP/POP3, TCP, IO, JABBER, MQ
tested on Perl 5.00503, 5.6.0, 5.6.1, 5.7.1 and 5.7.2
updated documentation and added new examples
Dunno if you got my email, but I'd like to see the ability to
dynamically
modify the dispatch tables. At the moment I'm doing it as a hack
into your
SOAP::Lite internals.
--
Matt/
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: [OT] JMS-like event framework for Perl
Hi, Gunther!
Although SOAP::Lite interfaces with SMTP and POP3, I don't know if
SOAP::Lite really qualifies to be in the same class as products like
JMS, Neon, or Microsoft MSMQ.
I think not or at least not yet :).
However, I think the description of what the author is interested in
is a bit vague. The words seem to indicate that he would be
satisfied by setting up a SOAP service on an HTTP server that
listens to calls made to it (the events) and then runs.
This is a simpler model and does not really describe
publish/subscribe as being a feature he wants.
Agree. It can be built as simple SOAP call against your server.
Though I'm finding many similarities between publish/subscribe and
async messaging they share common problem in this aspect: client has
to tell server where to run callback or response in async model. You
don't need it if you have static environment (when you're responsible
for client and server and client has fixed endpoint), but that's not
interesting case for us.
What can be done in my understanding (and I'm working on it), we can
pass either URL for service description that is able to handle
callback, or even fragment that describes it.
--
Notification service.
Author creates the resource (something that can be pointed by URL and
may be interesting for others) and registers it:
manageResource(URL, {name, description})
System responds with status of the request: registered or not.
Registration may fail if URL is already registered or system decided
you may not register such URL (its not on your IP address) or for
any other reason.
User would like to know about any changes for specified resource. She
sends request and asks register her for this resource and send
notification if something changes:
manageNotification(URL, {notification} [, granularity])
Notification specifies how user would like to be notified (HTTP,
SMTP, etc), in which format and granularity specifies for which event
(resource updated, dropped, etc.). Notification registration may
succeed or fail for reasons similar to resource registration.
Author modifies the resource and would like to notify everybody who
is registered about update:
manageUpdate(URL, message)
It will register update with specified message for particular
resource and notify everybody who is subscribed for this resource.
User can be notified in two modes: active and passive. Active mode
supposes you have something that is able to accept notification, like
http server (for HTTP or SOAP requests) or mail account (for SMTP
requests), and passive notification will be stored on server and you
can come later and read notifications youve got (source, message and
time). You can combine these approaches: subscribe in active mode for
something youre urgent to know about and in passive mode for
everything else.
--
Notification is simpler because server knows exactly what parameters
he wants to pass. For example, I'd like to manage Meerkats checks
against my web site (for some sites one hour can be too often and for
others it can be to rare) and to achive that, I need to register URL
of my site with notification server (as author), Meerkat needs to
register (as User of this resource) and then I just need to send
updates to notification server and it will take care about the rest
and will notify eveybody who is subscribed for this service. Almost
nothing has to be changed on Meerkat's side, and other users can
register for the same service, like search engines, catalogs or
anybody else (like you and me).
Asynchronous messages are little bit different (actually it's not
neccessarily should be SMTP against POP3, it could be HTTP only, but
process on server side could take significant amount of time): A
calls B, then B calls A. Two problems: A should let B know how to
call it and pass something that will let Alater identify that this is
response for particular request, like messageID.
This model can definitely be built on top of SOAP (I hope to have
demonstration soon), but it'll require design changes in toolkit on
client side. I'd like to stay with 'collection' interface, when:
A collectionserver
--request--
add MID --request--
accept request with MID and
collection's endpoints
start process and
make fake response
-response--
-response-- with MID
time passed.
client runs request for particular MID
--request--
nothing for you yet
-response--
finish process and
make real response
-response-- with MID
--request--
yes, we have something for your MID
-response--
Collection
Re: [ANNOUNCE] Apache::SOAP 0.47 (mod_soap)
Hi, Adi!
performance. (I added
array support to it and tested an array of 200 values, which took
~1 sec to serialize under mod_perl).
I see I wasn't the only person who starts with adding Array support
to it and I even made my copy of it SOAP1.1 compliant, but then Keith
came with his compliant version.
As for performance, I tried and got similar results on my machine. I
don't know your environment, so I included all my scripts, so you may
try them on your machine and let us know.
Anyway, here is my results (win98):
Benchmark: timing 10 iterations of 100x100, 1x100...
100x100: 10 wallclock secs ( 9.72 usr + 0.00 sys = 9.72 CPU) @
1.03/s (n=10)
1x100: 9 wallclock secs ( 9.17 usr + 0.00 sys = 9.17 CPU) @
1.09/s (n=10)
So, time is about 1 sec for roundtrip to mod_perl (serialization -
deserialization - invocation - serialization - deserialization)
Time for serialization only is different:
Benchmark: timing 100 iterations of (1)x200, (1x100)x200...
(1)x200: 23 wallclock secs (23.34 usr + 0.00 sys = 23.34 CPU) @
4.28/s (n=100)
(1x100)x200: 25 wallclock secs (24.99 usr + 0.00 sys = 24.99 CPU) @
4.00/s (n=100)
So, about 4 times bette. Same script on Linux (serialization only):
Benchmark: timing 100 iterations of (1)x200, (1x100)x200...
(1)x200: 5 wallclock secs ( 5.53 usr + 0.01 sys = 5.54 CPU)
(1x100)x200: 6 wallclock secs ( 5.79 usr + 0.02 sys = 5.81 CPU)
About 18 times a second.
Try these scripts in your environment for better results.
# Serialization
use SOAP::Lite;
use Benchmark;
$s = SOAP::Serializer-new;
$array1 = [(1) x 200];
$array100 = [(1x100) x 200];
Benchmark::timethese(100, {
'(1)x200' = sub { $s-method(a = $array1) },
'(1x100)x200' = sub { $s-method(a = $array100) },
})
# mod_perl
use SOAP::Lite;
$s = SOAP::Lite
- uri('http://www.soaplite.com/My/Parameters')
- proxy('http://localhost/soap')
;
use Benchmark;
$s-echo; # ignore first call, don't give a start to the first one
$array1 = [(1) x 200];
$array100 = [(1 x 100) x 200];
Benchmark::timethese(10, {
'1x100' = sub { $s-echo($array1) },
'100x100' = sub { $s-echo($array100) },
})
#
second(!) to serialize a large data structure. I believe the
reason is that it
makes method calls for every element in the Perl data structure,
and method
calls in Perl are inefficient due to the symbol table lookups and
@ISA
checking. So the larger the data structure the worse the
That's right, but first Perl caches calls that involve inheritance
and second, I use the same scheme, because arrays can have everything
inside and I need to call serialization function for every element in
array. I did profiling for several versions and did some
improvements, but there is no obvious stopper.
I am currently using SOAP, because I like the DM design, but I
would switch to
SOAP::Lite if its serialization speed is significantly better.
I'd like to know your results, with your Array implementation. Thank
you.
Best wishes, Paul.
--- Adi Fairbank [EMAIL PROTECTED] wrote:
Paul,
I've done some work on Keith Brown's SOAP module, and I like its
design, but one
thing I noticed is that it is slow. Even under mod_perl, it can
take up to 1
second(!) to serialize a large data structure. I believe the
reason is that it
makes method calls for every element in the Perl data structure,
and method
calls in Perl are inefficient due to the symbol table lookups and
@ISA
checking. So the larger the data structure the worse the
performance. (I added
array support to it and tested an array of 200 values, which took
~1 sec to serialize under mod_perl).
I'd be interested in speed comparisons between SOAP and SOAP::Lite.
I've looked
at your code, but not actually run it. It doesn't look like you
use recursive
method calls the way Keith does. Have you done any benchmarks on
large data
structure serialization? I assume deserialization performance will
be roughly
equivalent for SOAP vs. SOAP::Lite since they both use XML::Parser.
I read the
PERFORMANCE section on base64 encoding, but it didn't mention
serialization
speed.
I am currently using SOAP, because I like the DM design, but I
would switch to
SOAP::Lite if its serialization speed is significantly better.
Cheers,
-Adi
Paul Kulchenko wrote:
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
Re: [ANNOUNCE] Apache::SOAP 0.47 (mod_soap)
Hi, Gunther!
Is there any way to add an interface to basically provide
serialization and
deserialization hints? My experience in the way we use SOAP is that
There is no way to ptovide hints, but you have several options to
alter serializer/deserializer and use all other infrastructure. For
example, you may override serializer completely from scratch and then
register it with:
my $soap = SOAP::Lite-serializer(My::Serializer-new)-...
Or you may inherit your own serializer and specify it in the same
way. The same thing is true about deserializer and about server side
(these methods are available there also).
I did some tests with overriding serializers and truly results are
surprised me at least a little bit. Script is below. Results:
o - (1)x200: 23 wallclock secs (23.68 usr + 0.00 sys = 23.68 CPU) @
4.22/s (n=100)
o - (1x100)x200: 25 wallclock secs (24.99 usr + 0.00 sys = 24.99
CPU) @ 4.00/s (n=100)
a - (1)x200: 15 wallclock secs (15.33 usr + 0.00 sys = 15.33 CPU) @
6.52/s (n=100)
a - (1x100)x200: 16 wallclock secs (16.14 usr + 0.00 sys = 16.14
CPU) @ 6.20/s (n=100)
t - (1)x200: 6 wallclock secs ( 5.11 usr + 0.00 sys = 5.11 CPU) @
19.57/s (n=100)
t - (1x100)x200: 6 wallclock secs ( 6.15 usr + 0.00 sys = 6.15
CPU) @ 16.26/s (n=100)
x - (1)x200: 2 wallclock secs ( 2.08 usr + 0.00 sys = 2.08 CPU) @
48.08/s (n=100)
x - (1x100)x200: 3 wallclock secs ( 3.19 usr + 0.00 sys = 3.19
CPU) @ 31.35/s (n=100)
First is default serializer.
Second makes serialization only for first element of array and then
duplicates the results, emulating procedure for one type for all
elements. 50% better
Third generates ready to use xml and provides it as the result (you
may provide xml fragments during serialization) using serializer's
tag function. Almost 5 times better comparing to default.
Forth generates xml with by-hand coding. Almost 10 times better than
default. Everithing else is generated by serializer, so you can
insert your fragment seamlessly.
It's definitely something to think about. I'll take a closer look,
but it shows that having some information about data structure you
may significantly speed up this process. You may alter serialization
depending on user-defined class, depending on Object class, depending
on ref type (array, hash, scalar), etc., so you have almost full
control on serializer behavior. Create you own, override what you
need, register it and you're done.
Here is the script
# -- -- -- -- -- -- -- -- -- -- --
use SOAP::Lite;
use Benchmark;
$s = SOAP::Serializer-new;
$a = My::Serializer::Array-new;
$x = My::Serializer::XML-new;
$t = My::Serializer::XMLtag-new;
$array1 = [(1) x 200];
$array100 = [(1x100) x 200];
Benchmark::timethese(100, {
'o - (1)x200' = sub { $s-method(a = $array1) },
'o - (1x100)x200' = sub { $s-method(a = $array100) },
'a - (1)x200' = sub { $a-method(a = $array1) },
'a - (1x100)x200' = sub { $a-method(a = $array100) },
'x - (1)x200' = sub { $x-method(a = $array1) },
'x - (1x100)x200' = sub { $x-method(a = $array100) },
't - (1)x200' = sub { $t-method(a = $array1) },
't - (1x100)x200' = sub { $t-method(a = $array100) },
});
BEGIN {
package My::Serializer::Array;
@My::Serializer::Array::ISA = 'SOAP::Serializer';
sub encode_array {
my($self, $array, $name, $type, $attr) = @_;
my $items = 'item';
my @items = ($self-encode_object($array-[0], $items)) x
@$array;
return [$name || '~C:Array', {%{$attr || {}}, '~C:arrayType' =
$arraytype, 'xsi:type' = SOAP::Utils::qualify('~C' = $type)},
[@items], $self-gen_id($array)];
}
package My::Serializer::XML;
@My::Serializer::XML::ISA = 'SOAP::Serializer';
sub encode_array {
my($self, $array, $name, $type, $attr) = @_;
my $items = join '', 'Array', map("item$_/item", @$array),
'/Array';
return [$name, {'_xml' = 1}, $items];
}
package My::Serializer::XMLtag;
@My::Serializer::XMLtag::ISA = 'SOAP::Serializer';
sub encode_array {
my($self, $array, $name, $type, $attr) = @_;
my $items = join '', 'Array', map($self-tag('item', {}, $_),
@$array), '/Array';
return [$name, {'_xml' = 1}, $items];
}
}
# -- -- -- -- -- -- -- -- -- -- --
Hope it gives you some ideas.
Best wishes, Paul.
--- Gunther Birznieks [EMAIL PROTECTED] wrote:
At 05:14 PM 2/24/2001 -0800, Paul Kulchenko wrote:
That's right, but first Perl caches calls that involve inheritance
and second, I use the same scheme, because arrays can have
everything
inside and I need to call serialization function for every element
in
array. I did profiling for several versions and did some
improvements, but there is no obvious stopper.
Is there any way to add an interface to basically provide
serialization and
deserialization hints? My experience in the way we use SOAP is that
there
are only a few core objects that really require SOAP and the rest
can be on
the front-end.
Maybe using a CORBA-like IDL config? Thus, I could give a st
[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/
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/
