soaplite-devel — SOAP::Lite developers

[Soaplite-devel] Document-style encoding for SOAP::Lite - offer of support

[Jason S. <jas...@gm...>]

Hi all,

I'm new to this list. My name is Jason Stewart and I am a maintainer
of a number of Perl modules on CPAN including XML::Xerces (I am JASONS
on CPAN), as well as a long time maintainer of SF projects (e.g.
mged.sf.net). I am writing to offer my assistance to the SOAP::Lite
project.

I've been offered a contract to add support to SOAP::Lite for
Document-style syntax. Because my client is paying for this, it will
be my primary focus, but I really want to do this in a fashion which
best supports the *entire* SOAP::Lite community, and not just my
client.

I would really enjoy assisting the new maintainers to help transition
the codebase to SVN, or in splitting the monolithic .pm file, or other
tasks. My primary concern for the next month will be SOAP::Lite - I
will be able to dedicate a *lot* of time.

I've been a Perl programmer since 1991, and a C/C++ programmer since
1995. Because of my background with Xerces, I have a lot of experience
with XML, but my experience with SOAP and web services is limited, and
old. I will need to catch up with the times.

Please let me know how I can best help. Looking forward to working
with you all!

Cheers, jas.

[Soaplite-devel] SOAP talk at german perl workshop / SOAP::Lite usage scenarios

[Martin K. <mar...@fe...>]

Hi there,

I'm giving a talk about perl's current SOAP modules at the German Perl
Workshop in Erlangen from February 13 2008 to February 15 2008.

As far as I know from the preliminary schedule, the SOAP talk (the title
is "State of the SOAP" - stolen from Byrne's post last year) is
scheduled on Friday.

I'm also doing a Birds-of-a-Feather session on what people expect of
current SOAP toolkits.

Whether your going to Erlangen or not, I'd be interested in the
following points:

- What do you use SOAP::Lite for?
	- for what purpose?
	- on which platform?
	- with wich perl version?
	- in which (larger) Framework?
        - as Client/Server?
	- with which protocol?

- What do you use XMLRPC::Lite for?
	... same as above

- What do you use UDDI::Lite for?
	... same as above

There are two reasons for my interest:

The first is that I'd like to split up SOAP::Lite into several packages
to improve maintainability (I could imagine that the Jabber, Mail and
TCP transport backends become separate add-on-packages, or that
UDDI::Lite becomes a separate package), and I'd certanly like to keep
the stuff everybody needs in the core package.

The second reason is that "modern" Web Services with complex WSDLs and
stuff are a bit outside the scope of the current SOAP::Lite module - and
due to backward compatibility reasons it cannot be easily extended
(SOAP::WSDL and XML::Compile::SOAP, the current WSDL-supporting SOAP
toolkits both requires perl >=5.8, and SOAP::Lite even works with
5.005). I'd like to know how much backward compatibility SOAP::Lite
needs - and where. I could imagine that SOAP::Lite's core should run
with perls as old as 5.005, while new stuff like complete WSDL
processing (perhaps provided by a add-on) could require newer versions
of perl.

But... I don't know. But you do. Please help me out.

Regards,

Martin

Re: [Soaplite-devel] http://1 500internal server error

[Martin K. <mar...@fe...>]

Hi piyush,

from your mail, everything looks OK - but I can't say much without the
trace created by the client.

Did you look up the cause for the error in the IIS' error log (there is
some, though it is not alway informative)?

Regards,

Martin

Am Donnerstag, den 03.01.2008, 22:34 -0800 schrieb piyush tewari:
> Hi 
> I am trying to access .Net based web service by a perl web client. 
> Every thing is going smoothly if the .net web service is based on the
> file system.
> But if it is an Http based web service, a IIS deployed web service,
> then the my perl web client is not able to access the published
> methods of the web service. The error message that i get is 
> HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error
> More information regarding the .net web service is that 
> 1. I have enabled Anonymous Access on the web site.
> 2. Execute permissions are set for both scripts and executables.
> 3. Read , write , directory browsing , indexing and log visits
> permissions are granted.
> So tell me what can be the possible cause of this 500 Internal server
> error on IIS deployed web service.
>  
>  
> The web method is the automated generated web method of the c# web
> service that is the HelloWorld.
>  
> The perl code is as follows:
>  
> #!/usr/bin/perl
> use SOAP::Lite (+trace => all, maptype => {});
> my $soap = SOAP::Lite
>    -> uri('http://tempuri.org/')
>    -> on_action(sub{join '/', 'http://tempuri.org/', $_[1] })
>    -> proxy ('http://localhost/WebSite7/Service.asmx');
> my $method = SOAP::Data->name('HelloWorld')
>  ->attr({xmlns => 'http://tempuri.org/'});
> my $result =  $soap->call($method);
> print $result->valueof('//HelloWorldResult');
>  
>  
> Thank you..
> 
> ______________________________________________________________________
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Soaplite-devel mailing list Soa...@li... https://lists.sourceforge.net/lists/listinfo/soaplite-devel

[Soaplite-devel] http://1 500internal server error

[piyush t. <pk...@ya...>]

Hi 
I am trying to access .Net based web service by a perl web client. 
Every thing is going smoothly if the .net web service is based on the file system.
But if it is an Http based web service, a IIS deployed web service, then the my perl web client is not able to access the published methods of the web service. The error message that i get is 
HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error
More information regarding the .net web service is that 
1. I have enabled Anonymous Access on the web site.
2. Execute permissions are set for both scripts and executables.
3. Read , write , directory browsing , indexing and log visits permissions are granted.
  So tell me what can be the possible cause of this 500 Internal server error on IIS deployed web service.
   
   
  The web method is the automated generated web method of the c# web service that is the HelloWorld.
   
  The perl code is as follows:
   
  #!/usr/bin/perl
use SOAP::Lite (+trace => all, maptype => {});
  my $soap = SOAP::Lite
   -> uri('http://tempuri.org/')
   -> on_action(sub{join '/', 'http://tempuri.org/', $_[1] })
   -> proxy ('http://localhost/WebSite7/Service.asmx');
  my $method = SOAP::Data->name('HelloWorld')
 ->attr({xmlns => 'http://tempuri.org/'});
  my $result =  $soap->call($method);
  print $result->valueof('//HelloWorldResult');
   
   
  Thank you..

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

Re: [Soaplite-devel] XML-RPC on mod_perl

[Paul K. <pau...@ya...>]

I like this idea. Similar to this, SOAP::Lite class provide self()
method that returns a reference to the instance that makes the call
(actually, a singleton). 

Paul.

--- Martin Kutter <mar...@fe...> wrote:

> Hi Byrne,
> 
> I don't like the idea of exposing private variables as package
> globals -
> that is I don't consider the 
> 
> use vars($server);
> 
> as particularly appealing.
> 
> I'm not into Movable Type, so I can only guess from your post - but
> maybe exposing the server variable via a method would help?
> 
> This could allow both the mod_perl and non-mod_perl variant to 
> call something like
> 
>  Apache::XMLRPC::Lite->server()->serializer()->encoding('utf-8');
> 
> or something like
> 
>  $server ||= Apache::XMLRPC::Lite->server();
>  $server->serializer()->encoding('utf-8');
> 
> Would this be sufficient for your purpose?
> 
> Greetings & a happy new year,
> 
> Martin
> 
> Am Mittwoch, den 02.01.2008, 10:36 -0800 schrieb Byrne Reese:
> > Ok, so I am writing not as a developer, but as a user. I was
> hoping that 
> > even though I have the programming skilz, that someone might help
> me out 
> > - after all, these days I am more of a product manager, then I am
> an 
> > engineer.
> > 
> > Here is an excerpt from a bug with Movable Type (the product I am
> the PM 
> > for) - the bug being described is that XML-RPC will NOT work
> under 
> > mod_perl or FastCGI. :-(. I am looking for help in addressing the
> root 
> > cause of this problem, in addition to guidance on the best short
> term 
> > workaround.
> > 
> >  From lib/MT/XMLRPCServer.pm, line 21 (the line where the error
> occurs):
> > 
> >     $main::server->serializer->encoding('UTF-8');
> > 
> > When running under mod_perl, the $main::server variable is
> undefined 
> > (does not exist) for a number of reasons:
> > 
> > 1. Scripts run under mod_perl are not run under package "main".
> > 
> > 2. Under mod_perl, the mt-xmlrpc.cgi script is never executed. 
> The 
> > mt-xmlrpc.cgi script defines a public $server variable when
> XMLRPC is 
> > run as a CGI script; mod_perl creates and initializes a $server
> instance 
> > through the Apache::XMLRPC::Lite perl module.
> > 
> > 3. The Apache::XMLRPC::Lite perl module does not expose its
> $server 
> > variable, making it inaccessible to any code outside of the 
> > Apache::XMLRPC::Lite perl module.
> > 
> > Because there is no $server variable available or accessible when
> 
> > Movable Type is configured to run XMLRPC under mod_perl, the code
> at 
> > line 21 in XMLRPCServer.pm makes it impossible to run Movable
> Type's 
> > XMLRPC under mod_perl.
> > 
> > There appears to be a number of ways this issue could be
> addressed, but 
> > I am not sure if any of them are particularly good nor which one
> might 
> > be the best:
> > 
> > 1. The Apache::XMLRPC::Lite code could be modified so that the
> $server 
> > variable it defines is a public variable rather than a private
> one.  
> >  From /extlib/Apache/XMLRPC/Lite.pm, line 20:
> > 
> > my $server = __PACKAGE__->new;
> > 
> > This variable could be made a public one, in the same way the
> $server 
> > variable defined in the mt-xmlrpc.cgi script is defined as a
> public 
> > variable:
> > 
> > use vars qw($server);
> > $server = __PACKAGE__->new;
> > 
> > With above change in the Apache::XMLRPC::Lite code, the code at
> line 21 
> > in XMLRPCServer.pm could then be modified to allow the encoding
> to be 
> > set for the $server instance under both CGI and mod_perl:
> > 
> >     if ($ENV{MOD_PERL}) {
> >        
> $Apache::XMLRPC::Lite::server->serializer->encoding('UTF-8');
> >     } else {
> >         $main::server->serializer->encoding('UTF-8');
> >     }
> > 
> > 2. If it is not desirable to modify the Apache::XMLRPC::Lite
> code, the 
> > Apache::XMLRPC::Lite class could be subclassed in the
> XMLRPCServer.pm 
> > module and within the subclass, define a $server variable which
> would be 
> > publicly available to other classes.
> > 
> > Because the Apache::XMLRPC::Lite perl module contains so little
> code, it 
> > takes about the same amount of code to subclass
> Apache::XMLRPC::Lite as 
> > it does to just reimplement it in XMLRPCServer.pm.
> > 
> > I added the following code at the beginning of XMLRPCServer.pm to
> 
> > reimplement the functionality provided by Apache::XMLRPC::Lite,
> and 
> > allow the $server variable to be accessible to other classes:
> > 
> > package MT::XMLRPCServer::Lite;
> > use strict;
> > use XMLRPC::Transport::HTTP;
> > use base qw( XMLRPC::Transport::HTTP::Apache );
> > 
> > use vars qw($server);
> > $server = __PACKAGE__->new;
> > 
> > sub handler {
> >   $server->configure(@_);
> >   $server->SUPER::handler(@_);
> > }
> > 
> > The mod_perl configuration was modified in the Apache httpd.conf
> file to 
> > use the new MT::XMLRPC::Lite class instead of
> Apache::XMLRPC::Lite:
> > 
> > PerlModule MT::XMLRPCServer
> > <Location /mt/xmlrpc>
> >     SetHandler perl-script
> >     PerlHandler MT::XMLRPCServer::Lite
> >     PerlSetVar dispatch_to "blogger, metaWeblog, mt"
> >     PerlSetVar MTConfig 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
> >     PerlSetEnv MT_CONFIG 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
> > </Location>
> > 
> > With above changes to XMLRPCServer.pm and the mod_perl
> configuration in 
> > the Apache httpd.conf file, the code at line 21 in
> XMLRPCServer.pm could 
> > then be modified to allow the encoding to be set for the $server 
> > instance under both CGI and mod_perl:
> > 
> >     if ($ENV{MOD_PERL}) {
> >        
> $MT::XMLRPCServer::Lite::server->serializer->encoding('UTF-8');
> >     } else {
> >         $main::server->serializer->encoding('UTF-8');
> >     }
> > 
> > 
> > 
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Soaplite-devel mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> > 
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Soaplite-devel] XML-RPC on mod_perl

[Byrne R. <by...@ma...>]

That works for our purposes.

Martin Kutter wrote:
> Hi Byrne,
>
> I don't like the idea of exposing private variables as package globals -
> that is I don't consider the 
>
> use vars($server);
>
> as particularly appealing.
>
> I'm not into Movable Type, so I can only guess from your post - but
> maybe exposing the server variable via a method would help?
>
> This could allow both the mod_perl and non-mod_perl variant to 
> call something like
>
>  Apache::XMLRPC::Lite->server()->serializer()->encoding('utf-8');
>
> or something like
>
>  $server ||= Apache::XMLRPC::Lite->server();
>  $server->serializer()->encoding('utf-8');
>
> Would this be sufficient for your purpose?
>
> Greetings & a happy new year,
>
> Martin
>
> Am Mittwoch, den 02.01.2008, 10:36 -0800 schrieb Byrne Reese:
>   
>> Ok, so I am writing not as a developer, but as a user. I was hoping that 
>> even though I have the programming skilz, that someone might help me out 
>> - after all, these days I am more of a product manager, then I am an 
>> engineer.
>>
>> Here is an excerpt from a bug with Movable Type (the product I am the PM 
>> for) - the bug being described is that XML-RPC will NOT work under 
>> mod_perl or FastCGI. :-(. I am looking for help in addressing the root 
>> cause of this problem, in addition to guidance on the best short term 
>> workaround.
>>
>>  From lib/MT/XMLRPCServer.pm, line 21 (the line where the error occurs):
>>
>>     $main::server->serializer->encoding('UTF-8');
>>
>> When running under mod_perl, the $main::server variable is undefined 
>> (does not exist) for a number of reasons:
>>
>> 1. Scripts run under mod_perl are not run under package "main".
>>
>> 2. Under mod_perl, the mt-xmlrpc.cgi script is never executed.  The 
>> mt-xmlrpc.cgi script defines a public $server variable when XMLRPC is 
>> run as a CGI script; mod_perl creates and initializes a $server instance 
>> through the Apache::XMLRPC::Lite perl module.
>>
>> 3. The Apache::XMLRPC::Lite perl module does not expose its $server 
>> variable, making it inaccessible to any code outside of the 
>> Apache::XMLRPC::Lite perl module.
>>
>> Because there is no $server variable available or accessible when 
>> Movable Type is configured to run XMLRPC under mod_perl, the code at 
>> line 21 in XMLRPCServer.pm makes it impossible to run Movable Type's 
>> XMLRPC under mod_perl.
>>
>> There appears to be a number of ways this issue could be addressed, but 
>> I am not sure if any of them are particularly good nor which one might 
>> be the best:
>>
>> 1. The Apache::XMLRPC::Lite code could be modified so that the $server 
>> variable it defines is a public variable rather than a private one.  
>>  From /extlib/Apache/XMLRPC/Lite.pm, line 20:
>>
>> my $server = __PACKAGE__->new;
>>
>> This variable could be made a public one, in the same way the $server 
>> variable defined in the mt-xmlrpc.cgi script is defined as a public 
>> variable:
>>
>> use vars qw($server);
>> $server = __PACKAGE__->new;
>>
>> With above change in the Apache::XMLRPC::Lite code, the code at line 21 
>> in XMLRPCServer.pm could then be modified to allow the encoding to be 
>> set for the $server instance under both CGI and mod_perl:
>>
>>     if ($ENV{MOD_PERL}) {
>>         $Apache::XMLRPC::Lite::server->serializer->encoding('UTF-8');
>>     } else {
>>         $main::server->serializer->encoding('UTF-8');
>>     }
>>
>> 2. If it is not desirable to modify the Apache::XMLRPC::Lite code, the 
>> Apache::XMLRPC::Lite class could be subclassed in the XMLRPCServer.pm 
>> module and within the subclass, define a $server variable which would be 
>> publicly available to other classes.
>>
>> Because the Apache::XMLRPC::Lite perl module contains so little code, it 
>> takes about the same amount of code to subclass Apache::XMLRPC::Lite as 
>> it does to just reimplement it in XMLRPCServer.pm.
>>
>> I added the following code at the beginning of XMLRPCServer.pm to 
>> reimplement the functionality provided by Apache::XMLRPC::Lite, and 
>> allow the $server variable to be accessible to other classes:
>>
>> package MT::XMLRPCServer::Lite;
>> use strict;
>> use XMLRPC::Transport::HTTP;
>> use base qw( XMLRPC::Transport::HTTP::Apache );
>>
>> use vars qw($server);
>> $server = __PACKAGE__->new;
>>
>> sub handler {
>>   $server->configure(@_);
>>   $server->SUPER::handler(@_);
>> }
>>
>> The mod_perl configuration was modified in the Apache httpd.conf file to 
>> use the new MT::XMLRPC::Lite class instead of Apache::XMLRPC::Lite:
>>
>> PerlModule MT::XMLRPCServer
>> <Location /mt/xmlrpc>
>>     SetHandler perl-script
>>     PerlHandler MT::XMLRPCServer::Lite
>>     PerlSetVar dispatch_to "blogger, metaWeblog, mt"
>>     PerlSetVar MTConfig 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
>>     PerlSetEnv MT_CONFIG 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
>> </Location>
>>
>> With above changes to XMLRPCServer.pm and the mod_perl configuration in 
>> the Apache httpd.conf file, the code at line 21 in XMLRPCServer.pm could 
>> then be modified to allow the encoding to be set for the $server 
>> instance under both CGI and mod_perl:
>>
>>     if ($ENV{MOD_PERL}) {
>>         $MT::XMLRPCServer::Lite::server->serializer->encoding('UTF-8');
>>     } else {
>>         $main::server->serializer->encoding('UTF-8');
>>     }
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Soaplite-devel mailing list
>> Soa...@li...
>> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>>
>>     
>
>   

Re: [Soaplite-devel] XML-RPC on mod_perl

[Martin K. <mar...@fe...>]

Hi Byrne,

I don't like the idea of exposing private variables as package globals -
that is I don't consider the 

use vars($server);

as particularly appealing.

I'm not into Movable Type, so I can only guess from your post - but
maybe exposing the server variable via a method would help?

This could allow both the mod_perl and non-mod_perl variant to 
call something like

 Apache::XMLRPC::Lite->server()->serializer()->encoding('utf-8');

or something like

 $server ||= Apache::XMLRPC::Lite->server();
 $server->serializer()->encoding('utf-8');

Would this be sufficient for your purpose?

Greetings & a happy new year,

Martin

Am Mittwoch, den 02.01.2008, 10:36 -0800 schrieb Byrne Reese:
> Ok, so I am writing not as a developer, but as a user. I was hoping that 
> even though I have the programming skilz, that someone might help me out 
> - after all, these days I am more of a product manager, then I am an 
> engineer.
> 
> Here is an excerpt from a bug with Movable Type (the product I am the PM 
> for) - the bug being described is that XML-RPC will NOT work under 
> mod_perl or FastCGI. :-(. I am looking for help in addressing the root 
> cause of this problem, in addition to guidance on the best short term 
> workaround.
> 
>  From lib/MT/XMLRPCServer.pm, line 21 (the line where the error occurs):
> 
>     $main::server->serializer->encoding('UTF-8');
> 
> When running under mod_perl, the $main::server variable is undefined 
> (does not exist) for a number of reasons:
> 
> 1. Scripts run under mod_perl are not run under package "main".
> 
> 2. Under mod_perl, the mt-xmlrpc.cgi script is never executed.  The 
> mt-xmlrpc.cgi script defines a public $server variable when XMLRPC is 
> run as a CGI script; mod_perl creates and initializes a $server instance 
> through the Apache::XMLRPC::Lite perl module.
> 
> 3. The Apache::XMLRPC::Lite perl module does not expose its $server 
> variable, making it inaccessible to any code outside of the 
> Apache::XMLRPC::Lite perl module.
> 
> Because there is no $server variable available or accessible when 
> Movable Type is configured to run XMLRPC under mod_perl, the code at 
> line 21 in XMLRPCServer.pm makes it impossible to run Movable Type's 
> XMLRPC under mod_perl.
> 
> There appears to be a number of ways this issue could be addressed, but 
> I am not sure if any of them are particularly good nor which one might 
> be the best:
> 
> 1. The Apache::XMLRPC::Lite code could be modified so that the $server 
> variable it defines is a public variable rather than a private one.  
>  From /extlib/Apache/XMLRPC/Lite.pm, line 20:
> 
> my $server = __PACKAGE__->new;
> 
> This variable could be made a public one, in the same way the $server 
> variable defined in the mt-xmlrpc.cgi script is defined as a public 
> variable:
> 
> use vars qw($server);
> $server = __PACKAGE__->new;
> 
> With above change in the Apache::XMLRPC::Lite code, the code at line 21 
> in XMLRPCServer.pm could then be modified to allow the encoding to be 
> set for the $server instance under both CGI and mod_perl:
> 
>     if ($ENV{MOD_PERL}) {
>         $Apache::XMLRPC::Lite::server->serializer->encoding('UTF-8');
>     } else {
>         $main::server->serializer->encoding('UTF-8');
>     }
> 
> 2. If it is not desirable to modify the Apache::XMLRPC::Lite code, the 
> Apache::XMLRPC::Lite class could be subclassed in the XMLRPCServer.pm 
> module and within the subclass, define a $server variable which would be 
> publicly available to other classes.
> 
> Because the Apache::XMLRPC::Lite perl module contains so little code, it 
> takes about the same amount of code to subclass Apache::XMLRPC::Lite as 
> it does to just reimplement it in XMLRPCServer.pm.
> 
> I added the following code at the beginning of XMLRPCServer.pm to 
> reimplement the functionality provided by Apache::XMLRPC::Lite, and 
> allow the $server variable to be accessible to other classes:
> 
> package MT::XMLRPCServer::Lite;
> use strict;
> use XMLRPC::Transport::HTTP;
> use base qw( XMLRPC::Transport::HTTP::Apache );
> 
> use vars qw($server);
> $server = __PACKAGE__->new;
> 
> sub handler {
>   $server->configure(@_);
>   $server->SUPER::handler(@_);
> }
> 
> The mod_perl configuration was modified in the Apache httpd.conf file to 
> use the new MT::XMLRPC::Lite class instead of Apache::XMLRPC::Lite:
> 
> PerlModule MT::XMLRPCServer
> <Location /mt/xmlrpc>
>     SetHandler perl-script
>     PerlHandler MT::XMLRPCServer::Lite
>     PerlSetVar dispatch_to "blogger, metaWeblog, mt"
>     PerlSetVar MTConfig 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
>     PerlSetEnv MT_CONFIG 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
> </Location>
> 
> With above changes to XMLRPCServer.pm and the mod_perl configuration in 
> the Apache httpd.conf file, the code at line 21 in XMLRPCServer.pm could 
> then be modified to allow the encoding to be set for the $server 
> instance under both CGI and mod_perl:
> 
>     if ($ENV{MOD_PERL}) {
>         $MT::XMLRPCServer::Lite::server->serializer->encoding('UTF-8');
>     } else {
>         $main::server->serializer->encoding('UTF-8');
>     }
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 

[Soaplite-devel] XML-RPC on mod_perl

[Byrne R. <by...@ma...>]

Ok, so I am writing not as a developer, but as a user. I was hoping that 
even though I have the programming skilz, that someone might help me out 
- after all, these days I am more of a product manager, then I am an 
engineer.

Here is an excerpt from a bug with Movable Type (the product I am the PM 
for) - the bug being described is that XML-RPC will NOT work under 
mod_perl or FastCGI. :-(. I am looking for help in addressing the root 
cause of this problem, in addition to guidance on the best short term 
workaround.

 From lib/MT/XMLRPCServer.pm, line 21 (the line where the error occurs):

    $main::server->serializer->encoding('UTF-8');

When running under mod_perl, the $main::server variable is undefined 
(does not exist) for a number of reasons:

1. Scripts run under mod_perl are not run under package "main".

2. Under mod_perl, the mt-xmlrpc.cgi script is never executed.  The 
mt-xmlrpc.cgi script defines a public $server variable when XMLRPC is 
run as a CGI script; mod_perl creates and initializes a $server instance 
through the Apache::XMLRPC::Lite perl module.

3. The Apache::XMLRPC::Lite perl module does not expose its $server 
variable, making it inaccessible to any code outside of the 
Apache::XMLRPC::Lite perl module.

Because there is no $server variable available or accessible when 
Movable Type is configured to run XMLRPC under mod_perl, the code at 
line 21 in XMLRPCServer.pm makes it impossible to run Movable Type's 
XMLRPC under mod_perl.

There appears to be a number of ways this issue could be addressed, but 
I am not sure if any of them are particularly good nor which one might 
be the best:

1. The Apache::XMLRPC::Lite code could be modified so that the $server 
variable it defines is a public variable rather than a private one.  
 From /extlib/Apache/XMLRPC/Lite.pm, line 20:

my $server = __PACKAGE__->new;

This variable could be made a public one, in the same way the $server 
variable defined in the mt-xmlrpc.cgi script is defined as a public 
variable:

use vars qw($server);
$server = __PACKAGE__->new;

With above change in the Apache::XMLRPC::Lite code, the code at line 21 
in XMLRPCServer.pm could then be modified to allow the encoding to be 
set for the $server instance under both CGI and mod_perl:

    if ($ENV{MOD_PERL}) {
        $Apache::XMLRPC::Lite::server->serializer->encoding('UTF-8');
    } else {
        $main::server->serializer->encoding('UTF-8');
    }

2. If it is not desirable to modify the Apache::XMLRPC::Lite code, the 
Apache::XMLRPC::Lite class could be subclassed in the XMLRPCServer.pm 
module and within the subclass, define a $server variable which would be 
publicly available to other classes.

Because the Apache::XMLRPC::Lite perl module contains so little code, it 
takes about the same amount of code to subclass Apache::XMLRPC::Lite as 
it does to just reimplement it in XMLRPCServer.pm.

I added the following code at the beginning of XMLRPCServer.pm to 
reimplement the functionality provided by Apache::XMLRPC::Lite, and 
allow the $server variable to be accessible to other classes:

package MT::XMLRPCServer::Lite;
use strict;
use XMLRPC::Transport::HTTP;
use base qw( XMLRPC::Transport::HTTP::Apache );

use vars qw($server);
$server = __PACKAGE__->new;

sub handler {
  $server->configure(@_);
  $server->SUPER::handler(@_);
}

The mod_perl configuration was modified in the Apache httpd.conf file to 
use the new MT::XMLRPC::Lite class instead of Apache::XMLRPC::Lite:

PerlModule MT::XMLRPCServer
<Location /mt/xmlrpc>
    SetHandler perl-script
    PerlHandler MT::XMLRPCServer::Lite
    PerlSetVar dispatch_to "blogger, metaWeblog, mt"
    PerlSetVar MTConfig 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
    PerlSetEnv MT_CONFIG 'C:/Apache/www/MT-4.01-en/mt-config.cgi'
</Location>

With above changes to XMLRPCServer.pm and the mod_perl configuration in 
the Apache httpd.conf file, the code at line 21 in XMLRPCServer.pm could 
then be modified to allow the encoding to be set for the $server 
instance under both CGI and mod_perl:

    if ($ENV{MOD_PERL}) {
        $MT::XMLRPCServer::Lite::server->serializer->encoding('UTF-8');
    } else {
        $main::server->serializer->encoding('UTF-8');
    }

Re: [Soaplite-devel] string "P" detected as a duration

[Daniel D. <dan...@dr...>]

On Fri, 21 Dec 2007, Martin Kutter wrote:
> the issue is fixed in CVS and will be in the next release.
> 
> Note that your solution is incomplete: The strings "PT" and "-PT" get
> still encoded as xsd:duration.
> 
> A correct solution is to test for !~ m{^-?PT?$}x

Good point.  Thanks for the fix!

[Soaplite-devel] [Fwd: Re: string "P" detected as a duration]

[Martin K. <mar...@fe...>]

Again for the list:

[Soaplite-devel] string "P" detected as a duration

[Daniel D. <dan...@dr...>]

The typelookup regexes in SOAP::Serializer mark the string "P" as a duration.

This ends up in the XML as:
<soap:Body><function xmlns="..."><c-gensym3 xsi:type="xsd:duration">P</c-gensym3></disk></soap:Body>

This makes my .NET target angry with the error message:
System.Runtime.Remoting.RemotingException - The argument type "00:00:00"
cannot be converted into parameter type "System.String".

I've fixed this by using SOAP::Data to hardcode the type, but I'd like to
suggest this fix for detecting durations:

http://dan.drown.org/software/SOAP-Lite-duration.diff

(this is against 0.68, I checked and the same code is in CVS on sourceforge)

Re: [Soaplite-devel] SOAP::Transport::HTTP::Apache barfs on missing Content-Length (patch included)

[Martin K. <mar...@fe...>]

Hi Felix,

actually, the HTTP spec says a server should return a 400 Bad Request
error on requests without Content-length header.

Thus, the correct patch is likely to look like this:

Index: lib/SOAP/Transport/HTTP.pm
===================================================================
RCS file: /cvsroot/soaplite/soaplite-dist/lib/SOAP/Transport/HTTP.pm,v
retrieving revision 1.28
diff -u -r1.28 HTTP.pm
--- lib/SOAP/Transport/HTTP.pm	1 Dec 2007 12:32:19 -0000	1.28
+++ lib/SOAP/Transport/HTTP.pm	3 Dec 2007 18:24:06 -0000
@@ -683,16 +683,23 @@
     }
     # End patch from JT Justman
 
+    my $content = "";
+    if ($cont_len > 0) {
+        my $buf;
+        # attempt to slurp in the content at once...
+        $content .= $buf while ($r->read($buf,$cont_len) > 0);
+    }
+    else {
+        # throw appropriate error for mod_perl 2
+        return Apache2::Const::HTTP_BAD_REQUEST()
+            if ($self->{'MOD_PERL_VERSION'} >= 2);
+        return Apache::Constant::BAD_REQUEST();
+    }
+
     $self->request(HTTP::Request->new( 
         $r->method() => $r->uri,
         HTTP::Headers->new($r->headers_in),
-        do { 
-           my ($c,$buf); 
-           while ($r->read($buf,$cont_len)) { 
-              $c .= $buf; 
-           } 
-           $c; 
-        }
+        $content 
     ));
     $self->SUPER::handle;
 

I'll apply it to CVS.

Thanks for reporting,

Martin

Am Montag, den 03.12.2007, 11:46 +0100 schrieb Felix J. Ogris:
> Hi,
> 
> SOAP::Transport::HTTP::Apache::handler() will complain with s.th. like "The
> LENGTH argument can't be negative at
> /usr/local/lib/perl5/site_perl/5.8.8/SOAP/Transport/HTTP.pm line 692" if the
> request contains no Content-Length header (eg. GET). So you get a server
> error instead of a "405 - method not allowed" response. My patch for the
> latest CVS version fixes that.
> 
> Felix
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________ Soaplite-devel mailing list Soa...@li... https://lists.sourceforge.net/lists/listinfo/soaplite-devel

[Soaplite-devel] SOAP::Transport::HTTP::Apache barfs on missing Content-Length (patch included)

[Felix J. O. <fjo...@og...>]

Hi,

SOAP::Transport::HTTP::Apache::handler() will complain with s.th. like "The
LENGTH argument can't be negative at
/usr/local/lib/perl5/site_perl/5.8.8/SOAP/Transport/HTTP.pm line 692" if the
request contains no Content-Length header (eg. GET). So you get a server
error instead of a "405 - method not allowed" response. My patch for the
latest CVS version fixes that.

Felix

Re: [Soaplite-devel] another Expect: 100-continue problem

[Felix J. O. <fjo...@og...>]

Martin Kutter (mar...@fe...) wrote:
 
> The attached SOAP::Transport::HTTP should fix the issue (you can also
> get it from SOAP::Lite's CVS).

Hi Martin,

thanks for your help, the CVS version solves my problem.

Felix

Re: [Soaplite-devel] another Expect: 100-continue problem

[Martin K. <mar...@fe...>]

Hi Felix,

I was able to reproduce this using a modified SOAP::Lite client.

The attached SOAP::Transport::HTTP should fix the issue (you can also
get it from SOAP::Lite's CVS).

The fix will be in the next release.

Please let me know if this does not help,

Martin

Am Donnerstag, den 29.11.2007, 09:32 +0100 schrieb Felix J. Ogris:
> Hi Martin,
> 
> that's on the wire:
> 
> POST /soap HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client
> Protocol 2.0.50727.1433)
> VsDebuggerCausalityData:
> uIDPo2vDfno51ExKp/wPCQq4mlUAAAAA9O1ffVSkc0y4KYb7mMHMmU4ykIL3HWpIqwW7cp9xR5QA
> CQAA
> Content-Type: text/xml; charset=utf-8
> SOAPAction: ""
> Host: fjo-otrs.dts-online.net
> Content-Length: 498
> Expect: 100-continue
> Connection: Keep-Alive
> 
> HTTP/1.1 100 Continue
> 
> <?xml version="1.0" encoding="utf-8"?><soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:tns="http://fjo-otrs.dts-online.net/soaptest"
> xmlns:types="http://fjo-otrs.dts-online.net/soaptest/encodedTypes"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><tns:test
> /></soap:Body></soap:Envelope>
> 
> HTTP/1.1 200 OK
> Date: Thu, 29 Nov 2007 08:16:13 GMT
> Server: Apache/2.2.6 (FreeBSD) mod_perl/2.0.3 Perl/v5.8.8
> Content-Length: 501
> Content-Type: text/xml; charset=utf-8
> SOAPServer: SOAP::Lite/Perl/0.69
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> 
> HTTP/1.1 100 Continue
> 
> <?xml version="1.0" encoding="UTF-8"?><soap:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><testRespo
> nse xmlns="http://fjo-otrs.dts-online.net/soaptest"><s-gensym3
> xsi:type="xsd:string">hello, world</s-gensym3></testResponse></s
> 
> As you can see, </soap:Body> is chopped, and </soap:Envelope> is missing,
> since that additional "HTTP/1.1 100 Continue" eats exactly their content
> length.
> 
> My httpd.conf:
> 
> ServerRoot      /usr/local
> LoadModule      alias_module libexec/apache22/mod_alias.so
> LoadModule      perl_module  libexec/apache22/mod_perl.so
> LoadModule      mime_module  libexec/apache22/mod_mime.so
> TypesConfig     etc/apache22/mime.types
> AcceptMutex     sysvsem
> NameVirtualHost *
> PerlOptions     +ParseHeaders
> PerlOptions     +SetupEnv
> ...
> <LocationMatch ^/soap$>
>   SetHandler perl-script
>   PerlResponseHandler Apache::SOAP
>   PerlSetVar dispatch_to /usr/local/soap
> </LocationMatch>
> 
> /usr/local/soap/soaptest.pm:
> 
> #!/usr/bin/perl
> 
> package soaptest;
> 
> =begin WSDL
> 
> _RETURN $string just hello world
> _DOC test function
> 
> =end WSDL
> 
> =cut
> 
> sub test ()
> {
>     return "hello, world";
> }
> 
> 1;
> 
> HTH,
> Felix
> 
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 

Re: [Soaplite-devel] another Expect: 100-continue problem

[Felix J. O. <fjo...@og...>]

Hi Martin,

that's on the wire:

POST /soap HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client
Protocol 2.0.50727.1433)
VsDebuggerCausalityData:
uIDPo2vDfno51ExKp/wPCQq4mlUAAAAA9O1ffVSkc0y4KYb7mMHMmU4ykIL3HWpIqwW7cp9xR5QA
CQAA
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Host: fjo-otrs.dts-online.net
Content-Length: 498
Expect: 100-continue
Connection: Keep-Alive

HTTP/1.1 100 Continue

<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://fjo-otrs.dts-online.net/soaptest"
xmlns:types="http://fjo-otrs.dts-online.net/soaptest/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><tns:test
/></soap:Body></soap:Envelope>

HTTP/1.1 200 OK
Date: Thu, 29 Nov 2007 08:16:13 GMT
Server: Apache/2.2.6 (FreeBSD) mod_perl/2.0.3 Perl/v5.8.8
Content-Length: 501
Content-Type: text/xml; charset=utf-8
SOAPServer: SOAP::Lite/Perl/0.69
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

HTTP/1.1 100 Continue

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><testRespo
nse xmlns="http://fjo-otrs.dts-online.net/soaptest"><s-gensym3
xsi:type="xsd:string">hello, world</s-gensym3></testResponse></s

As you can see, </soap:Body> is chopped, and </soap:Envelope> is missing,
since that additional "HTTP/1.1 100 Continue" eats exactly their content
length.

My httpd.conf:

ServerRoot      /usr/local
LoadModule      alias_module libexec/apache22/mod_alias.so
LoadModule      perl_module  libexec/apache22/mod_perl.so
LoadModule      mime_module  libexec/apache22/mod_mime.so
TypesConfig     etc/apache22/mime.types
AcceptMutex     sysvsem
NameVirtualHost *
PerlOptions     +ParseHeaders
PerlOptions     +SetupEnv
...
<LocationMatch ^/soap$>
  SetHandler perl-script
  PerlResponseHandler Apache::SOAP
  PerlSetVar dispatch_to /usr/local/soap
</LocationMatch>

/usr/local/soap/soaptest.pm:

#!/usr/bin/perl

package soaptest;

=begin WSDL

_RETURN $string just hello world
_DOC test function

=end WSDL

=cut

sub test ()
{
    return "hello, world";
}

1;

HTH,
Felix

[Soaplite-devel] another Expect: 100-continue problem

[Felix J. O. <fjo...@og...>]

Hi,

I'm running SOAP::Lite 0.69, Perl 5.8.8, mod_perl2-2.0.3 and Apache 2.2.6 on
a x86 FreeBSD 6.2 box. Apache::SOAP is setup as PerlResponseHandler in
httpd.conf. Apparently, Apache handles all HTTP conversation, especially the
"100 Continue" stuff which .NET webservices negotiate. I have noticed that
there is printed an additional "HTTP/1.1 100 Continue" in between the header
and body right before the SOAP response follows. So, in my eyes
$r->print("HTTP/1.1 100 Continue\r\n\r\n") in
SOAP::Transport::HTTP::Apache::handler() is an error (at least if
Apache::SOAP is run as PerlResponseHandler, which is mod_perl2's successor
of mod_perl's PerlHandler).
Can anyone prove that or tell me what else is wrong with my setup?

TIA
Felix

Re: [Soaplite-devel] SOAP-Lite development - SVN?

[Scott W. <sc...@pe...>]

On Sun, Nov 18, 2007 at 09:35:03PM +0100, Martin Kutter wrote:
> 
> If there's no opinions against the migration, I'll proceed - please let
> me know your thoughts.

+1

-- 
Scott Wiersdorf
<sc...@pe...>

Re: [Soaplite-devel] SOAP-Lite development - SVN?

[Byrne R. <by...@ma...>]

+1

Martin Kutter wrote:
> Hi there,
>
> after doing some maintenance work, I've been stumbling accross some of
> the limitations of CVS.
>
> As I'm (both private and professionally) am using subversion for all
> other projects, I'd like to move SOAP-Lite's repository to SVN, too.
>
> Theres two main reasons for doing so:
>
> * Accessibility via HTTP(S)
> Subversion on SF.net can be accessed via http(s). To me it means that I
> can access SOAP-Lite's repository from everywhere. Right now I'm
> sometimes having troubles to connect through company firewalls.
>
> * Lazyness
> SVN keeps a global revision number (and a global revision log) for the
> whole repository. When compiling the Changes file for a release, yll a
> maintainer has to do is typing "svn history" and look through the commit
> messages. This is impossible with CVS, as CVS keeps a log for every
> file.
>
> There's a few other reasons I'm not going to discuss in detail - if you
> need more info on differences between CVS and SVN, just ask.
>
> SF.net provides SVN repositories, and instruction on how to migrate
> (using cvs2svn - I have been migrating the twentysomething repositories
> of my former team with cvs2svn without having troubles).
>
> If there's no opinions against the migration, I'll proceed - please let
> me know your thoughts.
>
> Thanks,
>
> Martin
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>   

[Soaplite-devel] SOAP-Lite development - SVN?

[Martin K. <mar...@fe...>]

Hi there,

after doing some maintenance work, I've been stumbling accross some of
the limitations of CVS.

As I'm (both private and professionally) am using subversion for all
other projects, I'd like to move SOAP-Lite's repository to SVN, too.

Theres two main reasons for doing so:

* Accessibility via HTTP(S)
Subversion on SF.net can be accessed via http(s). To me it means that I
can access SOAP-Lite's repository from everywhere. Right now I'm
sometimes having troubles to connect through company firewalls.

* Lazyness
SVN keeps a global revision number (and a global revision log) for the
whole repository. When compiling the Changes file for a release, yll a
maintainer has to do is typing "svn history" and look through the commit
messages. This is impossible with CVS, as CVS keeps a log for every
file.

There's a few other reasons I'm not going to discuss in detail - if you
need more info on differences between CVS and SVN, just ask.

SF.net provides SVN repositories, and instruction on how to migrate
(using cvs2svn - I have been migrating the twentysomething repositories
of my former team with cvs2svn without having troubles).

If there's no opinions against the migration, I'll proceed - please let
me know your thoughts.

Thanks,

Martin

[Soaplite-devel] SOAP-Lite-0.70_03

[Martin K. <mar...@fe...>]

Hi there,

i'd like to announce SOAP-Lite-0.70_03, a new pre-release version of
SOAP::Lite.

This is a bugfix release - maybe some of the bugs bothering you have
been fixed (and maybe new ones introduces - please open a bug report if
you find new ones).

The new SOAP-Lite package may be downloaded from sourceforge's download
page at https://sourceforge.net/project/showfiles.php?group_id=66000

It will also be available from CPAN in around a day or so - please allow
some time to let the CPAN indexer catch up.

You may find the new release on search.cpan.org by navigating to the
SOAP-Lite distribution page and following the link to the latest
development release. As a pre-release, it will usually not show up in
search results.

Thanks for all bug reports and patches,

Martin

[Soaplite-devel] SOAP-Lite-0.70_02

[Martin K. <mar...@fe...>]

Hi there,

i'd like to announce SOAP-Lite-0.70_02, a new pre-release version of
SOAP::Lite.

This is a bugfix release - maybe some of the bugs bothering you have
been fixed (and maybe new ones introduces - please open a bug report if
you find new ones).

The new SOAP-Lite package may be downloaded from sourceforge's download
page at https://sourceforge.net/project/showfiles.php?group_id=66000

It will also be available from CPAN in around a day or so - please allow
some time to let the CPAN indexer catch up.

Thanks for all bug reports and patches,

Martin

[Soaplite-devel] [ann]VTD-XML 2.2

[<cra...@co...>]

XimpleWare is proud to announce the the release of version 2.2 of VTD-XML, the next generation open source XML parsers/indexer/slicer/editor. This release significantly expands VTD-XML's ability to slice, split, edit and incrementally update the XML documents. To this end, we introduce the concept of namespace-compensated element fragment. This release also adds VTD+XML index writing capability to the VTD Navigator class. Other enhancements in this release include index size pre-computation, support for HTTP get, and some bug fixes. 

To download the latest release, please go to http://sourceforge.net/project/showfiles.php?group_id=110612.  

Re: [Soaplite-devel] SOAP-Lite 0.70_01 release

[Matthew R. <mr...@za...>]

Thank you for your hard work on this.

+--------------------------------------------------------+
  | Matthew Runo
  | Zappos Development
  | mr...@za...
  | 702-943-7833
+--------------------------------------------------------+


On Oct 18, 2007, at 1:58 PM, Martin Kutter wrote:

> Hi there,
>
> I just wanted to let you know that there's a new SOAP-Lite-0.70_01
> pre-release available on CPAN & sourceforge.
>
> Thank you for all your help in putting the stuff together.
>
> Martin
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>

[Soaplite-devel] SOAP-Lite 0.70_01 release

[Martin K. <mar...@fe...>]

Hi there,

I just wanted to let you know that there's a new SOAP-Lite-0.70_01
pre-release available on CPAN & sourceforge.

Thank you for all your help in putting the stuff together.

Martin