soaplite-devel — SOAP::Lite developers

[Soaplite-devel] soaplite-commit@lists.sourceforge.net

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

Hi,

I just set up a mailing list for SVN commit messages.

The list address is 

 soa...@li...

The list info (and subscription page) can be found here:

https://lists.sourceforge.net/lists/listinfo/soaplite-commit/ 

All SVN commit messages (without diffs) get posted to this list - so if
you really want to be up to date ;-)

Please don't post to it (posts should be rejected...) - the list is
read-only to non-commiters.

Martin

[Soaplite-devel] SOAP-Lite-0.70_07

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

Hi,

I just wrapped up everything for 0.71 but...
...it hasn't been tested yet.

So I'll just put in CPAN as 0.70_08, and re-release it as 0.71 after
CPAN testers have had their run on it.

(0.70_07 skipped, because I accidentally uploaded a ppm to CPAN...)

Stay tuned,

Martin

Re: [Soaplite-devel] SOAP::Lite communication

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

Either way is fine for me.

Paul.

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

> Hi Robbie,
> 
> I've been thinking about setting up a soaplite-commits mailing list
> today. I already get e-mailed on commits - maybe you (and others)
> would
> like to have that, too.
> 
> And maybe we should always cc the soap-devel list in our e-mails...
> ...so the others hanging around see what's happening...
> 
> Martin
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Soaplite-devel] New SOAP::Lite developer

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

Congratulations =p

Good luck!

Matthew Runo
Software Developer
Zappos.com
702.943.7833

On Feb 25, 2008, at 12:24 PM, Martin Kutter wrote:

> Hi there,
>
> today I have the pleasure of introducing a new helping hand on
> SOAP::Lite's development.
>
> Robbie Bow has joined me pushing SOAP::Lite ahead.
>
> I'm very happy about this help - my time is limited (as everyone's) -
> and I'm sure he'll make SOAP::Lite better than I could have done.
>
> Robbie is currently working on splitting up SOAP/Lite.pm, and he  
> started
> to update the docs.
>
> I guess you're going to read more soon,
>
> Martin
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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 communication

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

Hi Robbie,

I've been thinking about setting up a soaplite-commits mailing list
today. I already get e-mailed on commits - maybe you (and others) would
like to have that, too.

And maybe we should always cc the soap-devel list in our e-mails...
...so the others hanging around see what's happening...

Martin

[Soaplite-devel] New SOAP::Lite developer

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

Hi there,

today I have the pleasure of introducing a new helping hand on
SOAP::Lite's development. 

Robbie Bow has joined me pushing SOAP::Lite ahead.

I'm very happy about this help - my time is limited (as everyone's) -
and I'm sure he'll make SOAP::Lite better than I could have done.

Robbie is currently working on splitting up SOAP/Lite.pm, and he started
to update the docs.

I guess you're going to read more soon,

Martin

Re: [Soaplite-devel] proper use of on_action

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

Hi Charles,

it's a bit hard to tell you what perl code to write without the perl
code you tried.

The usual usage is something like this:

my $soap = SOAP::Lite->new();
$soap->on_action( sub { 
	return 'http://paypercall.ingenio.com/ListingsQuery' } 
);

# ... prepare header and body stuff in @data

$soap->default_ns('some namespace');
$soap->call('listingsReq', @data);

Martin

Am Mittwoch, den 20.02.2008, 15:02 -0800 schrieb Charles:
> Hi all,
> 
> I am trying to create a SOAP request with the following schema:
> 
> SOAPAction: "http://paypercall.ingenio.com/ListingsQuery"
> 
> <?xml version="1.0" encoding="utf-8"?>
> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> 
>   <soap:Header>
>     <IngenioHeader xmlns="some namespace">
>       <pid>string</pid>
>       <secCode>string</secCode>
>       <version>string</version>xml
>      </IngenioHeader>
>   </soap:Header>
> 
>   <soap:Body>
>     <listingsReq xmlns="some namespace">
>       <totalListingsCountLimit>int</totalListingsCountLimit>
>       <ipAddress>string</ipAddress>
>     </listingsReq>
>   </soap:Body>
> </soap:Envelope>
> 
> 
> The problem is that the SOAPAction function is called ListingsQuery,
> so in the <soap:Body> I get an object named <ListingsQuery>. I know
> that you can use on_action to overwrite this, but how do I do this?
> 
> At best, I've gotten the following structure:
> 
> <soap:Body>
>    <ListingsQuery xmlns="...">
>       <listingsReq xmlns="...">
>          ...
>       </listingsReq>
>    <ListingsQuery>
> </soap:Body>
> 
> I'm not sure if I explained this well enough, but any help or example
> code would be greatly appreciated. Thanks!
> 
> -Charles
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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] UTF8 Strings Not Marked

[rich c. <ri...@lr...>]

> On Wed, Feb 06, 2008 at 08:52:39AM +0100, Martin Kutter wrote:
> > There are two suggested resolutions:
> > 
> > 1. Don't serialize utf8-strings as base64binary.
> > This only works in perls >= 5.8, as there's no way to detect utf8
> > strings in perls before.

Doesn't something like

{eval{unpack('U0U', $_);};return $@;}

work on old perl versions, I seem to remember having something like that
working on some pretty old systems....

[Soaplite-devel] proper use of on_action

[Charles <cha...@gm...>]

Hi all,

I am trying to create a SOAP request with the following schema:

SOAPAction: "http://paypercall.ingenio.com/ListingsQuery"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="
http://schemas.xmlsoap.org/soap/envelope/">

  <soap:Header>
    <IngenioHeader xmlns="some namespace">
      <pid>string</pid>
      <secCode>string</secCode>
      <version>string</version>xml
     </IngenioHeader>
  </soap:Header>

  <soap:Body>
    <listingsReq xmlns="some namespace">
      <totalListingsCountLimit>int</totalListingsCountLimit>
      <ipAddress>string</ipAddress>
    </listingsReq>
  </soap:Body>
</soap:Envelope>


The problem is that the SOAPAction function is called ListingsQuery, so in
the <soap:Body> I get an object named <ListingsQuery>. I know that you can
use on_action to overwrite this, but how do I do this?

At best, I've gotten the following structure:

<soap:Body>
   <ListingsQuery xmlns="...">
      <listingsReq xmlns="...">
         ...
      </listingsReq>
   <ListingsQuery>
</soap:Body>

I'm not sure if I explained this well enough, but any help or example code
would be greatly appreciated. Thanks!

-Charles

Re: [Soaplite-devel] soaplite.com

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

I do - I can give you access to the blog no problem.

Martin Kutter wrote:
> Hi,
>
> I've been asked by some attendees at German Perl Workshop to update
> http://soaplite.com, as it gives the impression of SOAP::Lite being
> unmaintained.
>
> Who has access to this site and can help me out?
>
> Thank you,
>
> Martin
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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] SOAP::Lite Subversion repository

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

Awesome!!

Martin Kutter wrote:
> Hi there,
>
> I'm glad to have some good news for SOAP::Lite: I finally managed to
> move SOAP::Lite's codebase to Subversion.
>
> SOAP::Lite's svn trunk (like CVS HEAD) is available at:
>
> https://soaplite.svn.sf.net/svnroot/soaplite/trunk/
>
> I blocked developer access on SOAP::Lite's CVS to avoid accidental
> commits , so if you need something from the CVS you'll have to use
> anonymous access.
>
> I only moved the soaplite-dist directory to SVN - please let me know if
> you need something else.
>
> SVN access instructions are provided by sf.net at
>
> http://alexandria.wiki.sourceforge.net/Subversion+-+Version+Control+for
> +Source+Code
>
> Martin
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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] soaplite.com

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

Hi,

I've been asked by some attendees at German Perl Workshop to update
http://soaplite.com, as it gives the impression of SOAP::Lite being
unmaintained.

Who has access to this site and can help me out?

Thank you,

Martin

[Soaplite-devel] SOAP::Lite Subversion repository

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

Hi there,

I'm glad to have some good news for SOAP::Lite: I finally managed to
move SOAP::Lite's codebase to Subversion.

SOAP::Lite's svn trunk (like CVS HEAD) is available at:

https://soaplite.svn.sf.net/svnroot/soaplite/trunk/

I blocked developer access on SOAP::Lite's CVS to avoid accidental
commits , so if you need something from the CVS you'll have to use
anonymous access.

I only moved the soaplite-dist directory to SVN - please let me know if
you need something else.

SVN access instructions are provided by sf.net at

http://alexandria.wiki.sourceforge.net/Subversion+-+Version+Control+for
+Source+Code

Martin

Re: [Soaplite-devel] Offer of help

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

Hi Robbie,

thanks for your offer - I greatly appreciate any help on SOAP::Lite.

Sorry for the late answer - I've been busy attending the German Perl
Workshop this week.

I've just posted my roadmap plans for SOAP::Lite to the list - maybe you
find something you'd like to work on there.

SOAP::Lite's development is currently CVS-based - I've tried moving it
to sf.net's SVN, but without success.

I'm looking forward to hear from you,

Martin

Am Dienstag, den 12.02.2008, 17:05 +0000 schrieb Robbie Bow:
> Hi
> 
> I'd like to offer to help with the development of SOAP::Lite or
> SOAP::Easy, whichever is more pertinent. I'm a reasonably competent
> developer with ideas, and some spare time on my hands (and also facing
> a lot of headaches dealing with doc-literal APIs, which is what led me
> here).
> 
> Cheers
> 
> 
> 
> Robbie
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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 Roadmap

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

Hi there,

after some discussion here on the list, and talking to people on the
German Perl Workshop, I have the following plans for SOAP::Lite

1. drop support for perl 5.005 after the next stable release
Rationale:
5.005 requires several workarounds, mostly avoiding "use warnings", and
thus don't allow fine-grained warnings control.

Nobody seems to have a perl that old. While some systems (like HP-UX)
may still have 5.6.x as default perl, nobody I talked to has seen a
5.005 during the last years.

Impact:
Users with 5.005 won't be able to use newer SOAP::Lite versions.

2. Resolve namespace issues.
Rational:
The last SOAP::Lite picked by the CPAN module during a automatic release
is 0.60a. This is due to namespace issues: Modules like SOAP::Packager
conflict with other distributions.
I would like to move all SOAP::Lite specific stuff into the SOAP::Lite
namespace

Impact: Existing programs using __PACKAGE__ =~m/SOAP::/
    && __PACKAGE__ !~m/SOAP::Lite/ packages from the SOAP::Lite
distribution directly have to change their code.

Though this is a BIG change (which will break things), there's no way
around it: The only alternative would be to delete the SOAP package (and
possibly others) from CPAN - and there's people using it.


4. Move non HTTP Transport out of the main SOAP-Lite distribution and
flag the resulting distributions as unmaintained/looking for maintainer

Rationale: 
Nobody seems to use non-HTTP transports.

Impact:
- The non-HTTP transport classes get no support from me any more. That's
hardly a change ;-)
- Other people interested in a specific transport can take over
maintenance for the transport layer they need.

4. Integrate WSDL based toolkits
Rationale:
I don't like the idea that a user has to pick from 4 different toolkits
(SOAP, SOAP::Lite, SOAP::WSDL, XML::Compile::SOAP) for just doing SOAP.
I'd like SOAP::Lite to be able to integrate different WSDL based
frameworks, so there's always the same API presented to the user.

Please tell me if one of these plans doesn't match your needs.

Martin

[Soaplite-devel] Offer of help

[Robbie B. <rob...@gm...>]

Hi

I'd like to offer to help with the development of SOAP::Lite or
SOAP::Easy, whichever is more pertinent. I'm a reasonably competent
developer with ideas, and some spare time on my hands (and also facing
a lot of headaches dealing with doc-literal APIs, which is what led me
here).

Cheers



Robbie

Re: [Soaplite-devel] CPAN RT #32952 (UTF8 Strings Not Marked as UTF8 If Base64 encoded)

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

Martin,

I also prefer option 1. As far as I understand, it would only
(potentially) impact non-UTF aware clients/servers. Would it be
better to add an option and keep the existing behavior by default,
but allow users to turn the base64 encoding off?

Paul.

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

> Hi there,
> 
> there's a bug report open on CPAN RT
> (http://rt.cpan.org//Ticket/Display.html?id=32952) about the
> (wrong)
> handling of unicode strings in SOAP::Lite.
> 
> The current SOAP::Lite serializes utf8-strings as base64binary with
> autotyping enabled. On deserialization, the utf8 flag is not
> restored
> (which is correct, as base64binary data is a sequence of octets).
> Thus,
> a utf8 string sent appears as a sequence of octet at the receiver.
> 
> There are two suggested resolutions:
> 
> 1. Don't serialize utf8-strings as base64binary.
> This only works in perls >= 5.8, as there's no way to detect utf8
> strings in perls before.
> 
> 2. Introduce a "utf8binary" type, which behaves as the
> base64binary,
> except that the utf8 flag is restored on deserialization.
> 
> I prefer 1), as there's no "utf8binary" type in the SOAP standard,
> and
> fixing it for perls before 5.8 is pretty useless (these can't
> handle
> utf8 data anyway)
> 
> SOAP 1.2 demands the use of utf-8 or utf-16 in HTTP transports, so
> there
> should be no encoding problem - and the transport layer has to
> re-encode
> the envelope if needed (like for using quoted-printable for
> E-Mails).
> 
> The problem is, 1) may break existing SOAP::Lite clients and
> servers
> relying on the encoding of utf8 data as base64binary. 
> 
> What do you think?
> 
> Regards,
> 
> Martin
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Soaplite-devel] CPAN RT #32952 (UTF8 Strings Not Marked as UTF8 If Base64 encoded)

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

On Wed, Feb 06, 2008 at 08:52:39AM +0100, Martin Kutter wrote:
> There are two suggested resolutions:
> 
> 1. Don't serialize utf8-strings as base64binary.
> This only works in perls >= 5.8, as there's no way to detect utf8
> strings in perls before.
> 
> 2. Introduce a "utf8binary" type, which behaves as the base64binary,
> except that the utf8 flag is restored on deserialization.
> 
> I prefer 1), as there's no "utf8binary" type in the SOAP standard, and
> fixing it for perls before 5.8 is pretty useless (these can't handle
> utf8 data anyway)

Perhaps it becomes a package variable that can be set, and leave it
off by default so that people who upgrade won't break. Breaking things
is really bad.

  $SOAP::Lite::NO_SERIALIZE_UT8 = 1;

or something like that.

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

[Soaplite-devel] CPAN RT #32952 (UTF8 Strings Not Marked as UTF8 If Base64 encoded)

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

Hi there,

there's a bug report open on CPAN RT
(http://rt.cpan.org//Ticket/Display.html?id=32952) about the (wrong)
handling of unicode strings in SOAP::Lite.

The current SOAP::Lite serializes utf8-strings as base64binary with
autotyping enabled. On deserialization, the utf8 flag is not restored
(which is correct, as base64binary data is a sequence of octets). Thus,
a utf8 string sent appears as a sequence of octet at the receiver.

There are two suggested resolutions:

1. Don't serialize utf8-strings as base64binary.
This only works in perls >= 5.8, as there's no way to detect utf8
strings in perls before.

2. Introduce a "utf8binary" type, which behaves as the base64binary,
except that the utf8 flag is restored on deserialization.

I prefer 1), as there's no "utf8binary" type in the SOAP standard, and
fixing it for perls before 5.8 is pretty useless (these can't handle
utf8 data anyway)

SOAP 1.2 demands the use of utf-8 or utf-16 in HTTP transports, so there
should be no encoding problem - and the transport layer has to re-encode
the envelope if needed (like for using quoted-printable for E-Mails).

The problem is, 1) may break existing SOAP::Lite clients and servers
relying on the encoding of utf8 data as base64binary. 

What do you think?

Regards,

Martin

Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

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

You may safely try the 0.70_x pre-releases - they're basically bug fix
releases.
I have fixed several bugs related to mod_perl in the 0.70 series, but
the only thing related to loading server classes I remember is #30945:
SOAP::Serializer::envelope: Client Denied access to method, but this is
a different issue.

Can you determine whether "fresh" or "old" child processes fail?

I don't know how spawning apache child processes works under AIX - you
might try adding a PerlChildInitHandler to pull in the module required
instead of requiring it in the startup.pl, but that's only a guess (see
http://perl.apache.org/docs/2.0/user/handlers/server.html#C_PerlChildInitHandler_ for writing a PerlChildInitHandler).

Which Apache MPM are you using? prefork or worker?

Martin

Am Montag, den 28.01.2008, 12:16 -0500 schrieb Bill Hess:
> Thanks for the reply - we control both server and client side of
> things in our setup, so I am pretty sure that there is not any older
> version without a search method and I am positive that the module
> exists and httpd.conf is not changing since we control it - and there
> is only one server accepting requests...
> 
> The strange thing in our situation is that we have stress tested this
> over and over again and have not missed one request - we were throwing
> 100's of simultaneous requests at it and it did not skip a beat.  It
> seems that something else in the OS or another app on the same box
> does something so that when the next httpd child apache starts is
> "lost" - it can find the module - but not the method.  If I kill that
> child process, apache will start another one and most times it is OK -
> rarely the new one starts up with "missing" methods, but when it does,
> that is when we see the error.  And this only occurs on AIX - we run
> the same modules on Linux, HPUX, even Windows - not a problem...
> 
> I was starting to think that the outside influence was the fact that
> we are mounted via NFS and if there is a small blip in the NFS
> connection the method cannot be found, but the module is loaded OK -
> just a theory - but a sys admin here claims that NFS would not have
> those problems - I really do not buy that...
> 
> I am going to try the latest development version of SOAP::Lite 0.70_X
> as well - but the issue is hard to reproduce - we basically have to
> wait until it happens.  Does anyone think that any fixes put in after
> 0.69 would address this issue?
> 
> 
> Thanks!
> 
> 
> Bill Hess
> 
> 
> 
> Robert Landrum wrote: 
> > Generally, what's happened is the module search path has found a
> > older version of ABC_DB_SOAP where there was no search method.  It
> > might also be that ABC_DB_SOAP doesn't exist.  This could be due to
> > a change in the remote httpd.conf.  The reason it might affect one
> > call and not the next could be because the SOAP server is actually
> > two or more SOAP servers behind a vip or dns rotor. 
> > 
> > At least that's what happens to me from time to time. 
> > 
> > Rob 
> > 
> > Bill Hess wrote: 
> > > After my Apache/mod_perl/SOAP::Lite based server is running (on
> > > AIX) for a while and working perfectly, I get the following error
> > > when making a call from a SOAP::Lite client (Linux based): 
> > > 
> > > Error occurred making remote request call 
> > > (Failed to locate method (search) in class (ABC_DB_SOAP) at 
> > > /usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.) 
> > > 
> > > where the method is 'search' and the module name is 'ABC_DB_SOAP' 
> > > 
> > > If I try to make the same call right away, it may work or I might
> > > get the same error. I assume this is because it tries to use the
> > > same httpd child process. As time goes on and the server is used
> > > more, the frequency of the errors is higher... 
> > > 
> > > The problem only occurs on AIX (currently using AIX 5.3) and we
> > > are using Apache 2.2.4 and Perl 5.8.8 (built with threading on)
> > > with SOAP::Lite 0.69 from CPAN. Also - the location to all of this
> > > is NFS mounted - I am wondering if it could be a file locking
> > > issue, which I have seen before on AIX. I know this configuration
> > > (NFS mounted) is probably not the best way to run - but in our
> > > environment we have little choice (politics). 
> > > 
> > > 
> > > The entry in my httpd.conf file is: 
> > > 
> > > <Location /server> 
> > > SetHandler perl-script 
> > > PerlHandler Apache::SOAP 
> > > PerlSetVar options "compress_threshold => 1048576" #30945:
> > > SOAP::Serializer::envelope: Client Denied access to method
> > > PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP" 
> > > </Location> 
> > > 
> > > 
> > > Reading the perldoc for SOAP::Lite, it mentions: 
> > > 
> > > For dynamic deployment you can specify the name either directly
> > > (in 
> > > that case it will be "require"d without any restriction) or 
> > > indirectly, with a PATH. In that case, the ONLY path that will be 
> > > available will be the PATH given to the dispatch_to( ) method).
> > > For 
> > > information how to handle this situation see "SECURITY" section.* 
> > > * 
> > > 
> > > I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use'
> > > them in a mod_perl startup script which is defined in httpd.conf
> > > using PerlRequire - for example: 
> > > 
> > > 
> > > PerlRequire /usr/local/mystuff/conf/startup.pl 
> > > 
> > > 
> > > So I think that this is synonymous to the methods offered in the
> > > SECURITY section of the perldoc. Here is what the startup.pl file
> > > looks like: 
> > > 
> > > #!/usr/local/ perl/bin/perl 
> > > 
> > > use ModPerl::Util (); 
> > > use Apache2::RequestRec (); 
> > > use Apache2::RequestIO (); 
> > > use Apache2::RequestUti l (); 
> > > use Apache2::ServerRec (); 
> > > use Apache2::ServerUtil (); 
> > > use Apache2::Connection (); 
> > > use Apache2::Log (); 
> > > use Apache2::Const -compile => ':common'; 
> > > use APR::Const -compile => ':common'; 
> > > use APR::Table (); 
> > > 
> > > use DBI; 
> > > use MyModule; 
> > > 1; 
> > > 
> > > 
> > > The DBI module is built into my Perl distro, but MyModule resides
> > > under /usr/local/mystuff/ lib. I use PERL5LIB to include this path
> > > to my @INC Could this be an issue? 
> > > 
> > > I have seen this issue mentioned before by Googling for it, Perl
> > > Monks, etc... - but have not found any definitive solutions.   I
> > > have posted this to the soaplite users list without a response. 
> > > 
> > > Any help would be greatly appreciated - Thanks... 
> > > 
> > > 
> > > Bill Hess 
> > > 
> > > 
> > > 
> > > ------------------------------------------------------------------------ 
> > > 
> > > ------------------------------------------------------------------------- 
> > > This SF.net email is sponsored by: Microsoft 
> > > Defy all challenges. Microsoft(R) Visual Studio 2008. 
> > > 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 2008.
> 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] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

This seems to only occur with newly spawned httpd processes - since I am 
typically killing the most recent child to clean up the issue without 
restarting apache.  I am using prefork - but the perl on AIX I am using 
was built with threading on - I do not think that should be an issue?

I can try the PerlChildInitHandler route - but isn't it the same as 
doing this in my httpd.conf file:

PerlRequire /usr/local/mystuff/conf/startup.pl


and in that file I use my module like this:

#!/usr/local/perl/bin/perl 

use ModPerl::Util (); 
use Apache2::RequestRec (); 
use Apache2::RequestIO (); 
use Apache2::RequestUti l (); 
use Apache2::ServerRec (); 
use Apache2::ServerUtil (); 
use Apache2::Connection (); 
use Apache2::Log (); 
use Apache2::Const -compile => ':common'; 
use APR::Const -compile => ':common'; 
use APR::Table (); 

use DBI; 
use MyModule; 
1; 



Thanks for the help!

Bill Hess




Martin Kutter wrote:
> You may safely try the 0.70_x pre-releases - they're basically bug fix
> releases.
> I have fixed several bugs related to mod_perl in the 0.70 series, but
> the only thing related to loading server classes I remember is #30945:
> SOAP::Serializer::envelope: Client Denied access to method, but this is
> a different issue.
>
> Can you determine whether "fresh" or "old" child processes fail?
>
> I don't know how spawning apache child processes works under AIX - you
> might try adding a PerlChildInitHandler to pull in the module required
> instead of requiring it in the startup.pl, but that's only a guess (see
> http://perl.apache.org/docs/2.0/user/handlers/server.html#C_PerlChildInitHandler_ for writing a PerlChildInitHandler).
>
> Which Apache MPM are you using? prefork or worker?
>
> Martin
>
> Am Montag, den 28.01.2008, 12:16 -0500 schrieb Bill Hess:
>   
>> Thanks for the reply - we control both server and client side of
>> things in our setup, so I am pretty sure that there is not any older
>> version without a search method and I am positive that the module
>> exists and httpd.conf is not changing since we control it - and there
>> is only one server accepting requests...
>>
>> The strange thing in our situation is that we have stress tested this
>> over and over again and have not missed one request - we were throwing
>> 100's of simultaneous requests at it and it did not skip a beat.  It
>> seems that something else in the OS or another app on the same box
>> does something so that when the next httpd child apache starts is
>> "lost" - it can find the module - but not the method.  If I kill that
>> child process, apache will start another one and most times it is OK -
>> rarely the new one starts up with "missing" methods, but when it does,
>> that is when we see the error.  And this only occurs on AIX - we run
>> the same modules on Linux, HPUX, even Windows - not a problem...
>>
>> I was starting to think that the outside influence was the fact that
>> we are mounted via NFS and if there is a small blip in the NFS
>> connection the method cannot be found, but the module is loaded OK -
>> just a theory - but a sys admin here claims that NFS would not have
>> those problems - I really do not buy that...
>>
>> I am going to try the latest development version of SOAP::Lite 0.70_X
>> as well - but the issue is hard to reproduce - we basically have to
>> wait until it happens.  Does anyone think that any fixes put in after
>> 0.69 would address this issue?
>>
>>
>> Thanks!
>>
>>
>> Bill Hess
>>
>>
>>
>> Robert Landrum wrote: 
>>     
>>> Generally, what's happened is the module search path has found a
>>> older version of ABC_DB_SOAP where there was no search method.  It
>>> might also be that ABC_DB_SOAP doesn't exist.  This could be due to
>>> a change in the remote httpd.conf.  The reason it might affect one
>>> call and not the next could be because the SOAP server is actually
>>> two or more SOAP servers behind a vip or dns rotor. 
>>>
>>> At least that's what happens to me from time to time. 
>>>
>>> Rob 
>>>
>>> Bill Hess wrote: 
>>>       
>>>> After my Apache/mod_perl/SOAP::Lite based server is running (on
>>>> AIX) for a while and working perfectly, I get the following error
>>>> when making a call from a SOAP::Lite client (Linux based): 
>>>>
>>>> Error occurred making remote request call 
>>>> (Failed to locate method (search) in class (ABC_DB_SOAP) at 
>>>> /usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.) 
>>>>
>>>> where the method is 'search' and the module name is 'ABC_DB_SOAP' 
>>>>
>>>> If I try to make the same call right away, it may work or I might
>>>> get the same error. I assume this is because it tries to use the
>>>> same httpd child process. As time goes on and the server is used
>>>> more, the frequency of the errors is higher... 
>>>>
>>>> The problem only occurs on AIX (currently using AIX 5.3) and we
>>>> are using Apache 2.2.4 and Perl 5.8.8 (built with threading on)
>>>> with SOAP::Lite 0.69 from CPAN. Also - the location to all of this
>>>> is NFS mounted - I am wondering if it could be a file locking
>>>> issue, which I have seen before on AIX. I know this configuration
>>>> (NFS mounted) is probably not the best way to run - but in our
>>>> environment we have little choice (politics). 
>>>>
>>>>
>>>> The entry in my httpd.conf file is: 
>>>>
>>>> <Location /server> 
>>>> SetHandler perl-script 
>>>> PerlHandler Apache::SOAP 
>>>> PerlSetVar options "compress_threshold => 1048576" #30945:
>>>> SOAP::Serializer::envelope: Client Denied access to method
>>>> PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP" 
>>>> </Location> 
>>>>
>>>>
>>>> Reading the perldoc for SOAP::Lite, it mentions: 
>>>>
>>>> For dynamic deployment you can specify the name either directly
>>>> (in 
>>>> that case it will be "require"d without any restriction) or 
>>>> indirectly, with a PATH. In that case, the ONLY path that will be 
>>>> available will be the PATH given to the dispatch_to( ) method).
>>>> For 
>>>> information how to handle this situation see "SECURITY" section.* 
>>>> * 
>>>>
>>>> I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use'
>>>> them in a mod_perl startup script which is defined in httpd.conf
>>>> using PerlRequire - for example: 
>>>>
>>>>
>>>> PerlRequire /usr/local/mystuff/conf/startup.pl 
>>>>
>>>>
>>>> So I think that this is synonymous to the methods offered in the
>>>> SECURITY section of the perldoc. Here is what the startup.pl file
>>>> looks like: 
>>>>
>>>> #!/usr/local/ perl/bin/perl 
>>>>
>>>> use ModPerl::Util (); 
>>>> use Apache2::RequestRec (); 
>>>> use Apache2::RequestIO (); 
>>>> use Apache2::RequestUti l (); 
>>>> use Apache2::ServerRec (); 
>>>> use Apache2::ServerUtil (); 
>>>> use Apache2::Connection (); 
>>>> use Apache2::Log (); 
>>>> use Apache2::Const -compile => ':common'; 
>>>> use APR::Const -compile => ':common'; 
>>>> use APR::Table (); 
>>>>
>>>> use DBI; 
>>>> use MyModule; 
>>>> 1; 
>>>>
>>>>
>>>> The DBI module is built into my Perl distro, but MyModule resides
>>>> under /usr/local/mystuff/ lib. I use PERL5LIB to include this path
>>>> to my @INC Could this be an issue? 
>>>>
>>>> I have seen this issue mentioned before by Googling for it, Perl
>>>> Monks, etc... - but have not found any definitive solutions.   I
>>>> have posted this to the soaplite users list without a response. 
>>>>
>>>> Any help would be greatly appreciated - Thanks... 
>>>>
>>>>
>>>> Bill Hess 
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> ------------------------------------------------------------------------- 
>>>> This SF.net email is sponsored by: Microsoft 
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. 
>>>> 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 2008.
>> 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] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

Thanks for the reply - we control both server and client side of things 
in our setup, so I am pretty sure that there is not any older version 
without a search method and I am positive that the module exists and 
httpd.conf is not changing since we control it - and there is only one 
server accepting requests...

The strange thing in our situation is that we have stress tested this 
over and over again and have not missed one request - we were throwing 
100's of simultaneous requests at it and it did not skip a beat.  It 
seems that something else in the OS or another app on the same box does 
something so that when the next httpd child apache starts is "lost" - it 
can find the module - but not the method.  If I kill that child process, 
apache will start another one and most times it is OK - rarely the new 
one starts up with "missing" methods, but when it does, that is when we 
see the error.  And this only occurs on AIX - we run the same modules on 
Linux, HPUX, even Windows - not a problem...

I was starting to think that the outside influence was the fact that we 
are mounted via NFS and if there is a small blip in the NFS connection 
the method cannot be found, but the module is loaded OK - just a theory 
- but a sys admin here claims that NFS would not have those problems - I 
really do not buy that...

I am going to try the latest development version of SOAP::Lite 0.70_X as 
well - but the issue is hard to reproduce - we basically have to wait 
until it happens.  Does anyone think that any fixes put in after 0.69 
would address this issue?


Thanks!


Bill Hess



Robert Landrum wrote:
> Generally, what's happened is the module search path has found a older 
> version of ABC_DB_SOAP where there was no search method.  It might 
> also be that ABC_DB_SOAP doesn't exist.  This could be due to a change 
> in the remote httpd.conf.  The reason it might affect one call and not 
> the next could be because the SOAP server is actually two or more SOAP 
> servers behind a vip or dns rotor.
>
> At least that's what happens to me from time to time.
>
> Rob
>
> Bill Hess wrote:
>> After my Apache/mod_perl/SOAP::Lite based server is running (on AIX) 
>> for a while and working perfectly, I get the following error when 
>> making a call from a SOAP::Lite client (Linux based):
>>
>> Error occurred making remote request call
>> (Failed to locate method (search) in class (ABC_DB_SOAP) at
>> /usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.)
>>
>> where the method is 'search' and the module name is 'ABC_DB_SOAP'
>>
>> If I try to make the same call right away, it may work or I might get 
>> the same error. I assume this is because it tries to use the same 
>> httpd child process. As time goes on and the server is used more, the 
>> frequency of the errors is higher...
>>
>> The problem only occurs on AIX (currently using AIX 5.3) and we are 
>> using Apache 2.2.4 and Perl 5.8.8 (built with threading on) with 
>> SOAP::Lite 0.69 from CPAN. Also - the location to all of this is NFS 
>> mounted - I am wondering if it could be a file locking issue, which I 
>> have seen before on AIX. I know this configuration (NFS mounted) is 
>> probably not the best way to run - but in our environment we have 
>> little choice (politics).
>>
>>
>> The entry in my httpd.conf file is:
>>
>> <Location /server>
>> SetHandler perl-script
>> PerlHandler Apache::SOAP
>> PerlSetVar options "compress_threshold => 1048576"
>> PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP"
>> </Location>
>>
>>
>> Reading the perldoc for SOAP::Lite, it mentions:
>>
>> For dynamic deployment you can specify the name either directly (in
>> that case it will be "require"d without any restriction) or
>> indirectly, with a PATH. In that case, the ONLY path that will be
>> available will be the PATH given to the dispatch_to( ) method). For
>> information how to handle this situation see "SECURITY" section.*
>> *
>>
>> I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use' them 
>> in a mod_perl startup script which is defined in httpd.conf using 
>> PerlRequire - for example:
>>
>>
>> PerlRequire /usr/local/mystuff/conf/startup.pl
>>
>>
>> So I think that this is synonymous to the methods offered in the 
>> SECURITY section of the perldoc. Here is what the startup.pl file 
>> looks like:
>>
>> #!/usr/local/ perl/bin/perl
>>
>> use ModPerl::Util ();
>> use Apache2::RequestRec ();
>> use Apache2::RequestIO ();
>> use Apache2::RequestUti l ();
>> use Apache2::ServerRec ();
>> use Apache2::ServerUtil ();
>> use Apache2::Connection ();
>> use Apache2::Log ();
>> use Apache2::Const -compile => ':common';
>> use APR::Const -compile => ':common';
>> use APR::Table ();
>>
>> use DBI;
>> use MyModule;
>> 1;
>>
>>
>> The DBI module is built into my Perl distro, but MyModule resides 
>> under /usr/local/mystuff/ lib. I use PERL5LIB to include this path to 
>> my @INC Could this be an issue?
>>
>> I have seen this issue mentioned before by Googling for it, Perl 
>> Monks, etc... - but have not found any definitive solutions.   I have 
>> posted this to the soaplite users list without a response.
>>
>> Any help would be greatly appreciated - Thanks...
>>
>>
>> Bill Hess
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> 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] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Robert L. <rla...@ao...>]

Generally, what's happened is the module search path has found a older 
version of ABC_DB_SOAP where there was no search method.  It might also 
be that ABC_DB_SOAP doesn't exist.  This could be due to a change in the 
remote httpd.conf.  The reason it might affect one call and not the next 
could be because the SOAP server is actually two or more SOAP servers 
behind a vip or dns rotor.

At least that's what happens to me from time to time.

Rob

Bill Hess wrote:
> After my Apache/mod_perl/SOAP::Lite based server is running (on AIX) for 
> a while and working perfectly, I get the following error when making a 
> call from a SOAP::Lite client (Linux based):
> 
> Error occurred making remote request call
> (Failed to locate method (search) in class (ABC_DB_SOAP) at
> /usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.)
> 
> where the method is 'search' and the module name is 'ABC_DB_SOAP'
> 
> If I try to make the same call right away, it may work or I might get 
> the same error. I assume this is because it tries to use the same httpd 
> child process. As time goes on and the server is used more, the 
> frequency of the errors is higher...
> 
> The problem only occurs on AIX (currently using AIX 5.3) and we are 
> using Apache 2.2.4 and Perl 5.8.8 (built with threading on) with 
> SOAP::Lite 0.69 from CPAN. Also - the location to all of this is NFS 
> mounted - I am wondering if it could be a file locking issue, which I 
> have seen before on AIX. I know this configuration (NFS mounted) is 
> probably not the best way to run - but in our environment we have little 
> choice (politics).
> 
> 
> The entry in my httpd.conf file is:
> 
> <Location /server>
> SetHandler perl-script
> PerlHandler Apache::SOAP
> PerlSetVar options "compress_threshold => 1048576"
> PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP"
> </Location>
> 
> 
> Reading the perldoc for SOAP::Lite, it mentions:
> 
> For dynamic deployment you can specify the name either directly (in
> that case it will be "require"d without any restriction) or
> indirectly, with a PATH. In that case, the ONLY path that will be
> available will be the PATH given to the dispatch_to( ) method). For
> information how to handle this situation see "SECURITY" section.*
> *
> 
> I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use' them in a 
> mod_perl startup script which is defined in httpd.conf using PerlRequire 
> - for example:
> 
> 
> PerlRequire /usr/local/mystuff/conf/startup.pl
> 
> 
> So I think that this is synonymous to the methods offered in the 
> SECURITY section of the perldoc. Here is what the startup.pl file looks 
> like:
> 
> #!/usr/local/ perl/bin/perl
> 
> use ModPerl::Util ();
> use Apache2::RequestRec ();
> use Apache2::RequestIO ();
> use Apache2::RequestUti l ();
> use Apache2::ServerRec ();
> use Apache2::ServerUtil ();
> use Apache2::Connection ();
> use Apache2::Log ();
> use Apache2::Const -compile => ':common';
> use APR::Const -compile => ':common';
> use APR::Table ();
> 
> use DBI;
> use MyModule;
> 1;
> 
> 
> The DBI module is built into my Perl distro, but MyModule resides under 
> /usr/local/mystuff/ lib. I use PERL5LIB to include this path to my @INC 
> Could this be an issue?
> 
> I have seen this issue mentioned before by Googling for it, Perl Monks, 
> etc... - but have not found any definitive solutions.   I have posted 
> this to the soaplite users list without a response.
> 
> Any help would be greatly appreciated - Thanks...
> 
> 
> Bill Hess
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

After my Apache/mod_perl/SOAP::Lite based server is running (on AIX) for 
a while and working perfectly, I get the following error when making a 
call from a SOAP::Lite client (Linux based):

Error occurred making remote request call
(Failed to locate method (search) in class (ABC_DB_SOAP) at
/usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.)

where the method is 'search' and the module name is 'ABC_DB_SOAP'

If I try to make the same call right away, it may work or I might get 
the same error. I assume this is because it tries to use the same httpd 
child process. As time goes on and the server is used more, the 
frequency of the errors is higher...

The problem only occurs on AIX (currently using AIX 5.3) and we are 
using Apache 2.2.4 and Perl 5.8.8 (built with threading on) with 
SOAP::Lite 0.69 from CPAN. Also - the location to all of this is NFS 
mounted - I am wondering if it could be a file locking issue, which I 
have seen before on AIX. I know this configuration (NFS mounted) is 
probably not the best way to run - but in our environment we have little 
choice (politics).


The entry in my httpd.conf file is:

<Location /server>
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar options "compress_threshold => 1048576"
PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP"
</Location>


Reading the perldoc for SOAP::Lite, it mentions:

For dynamic deployment you can specify the name either directly (in
that case it will be "require"d without any restriction) or
indirectly, with a PATH. In that case, the ONLY path that will be
available will be the PATH given to the dispatch_to( ) method). For
information how to handle this situation see "SECURITY" section.*
*

I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use' them in a 
mod_perl startup script which is defined in httpd.conf using PerlRequire 
- for example:


PerlRequire /usr/local/mystuff/conf/startup.pl


So I think that this is synonymous to the methods offered in the 
SECURITY section of the perldoc. Here is what the startup.pl file looks 
like:

#!/usr/local/ perl/bin/perl

use ModPerl::Util ();
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUti l ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile => ':common';
use APR::Const -compile => ':common';
use APR::Table ();

use DBI;
use MyModule;
1;


The DBI module is built into my Perl distro, but MyModule resides under 
/usr/local/mystuff/ lib. I use PERL5LIB to include this path to my @INC 
Could this be an issue?

I have seen this issue mentioned before by Googling for it, Perl Monks, 
etc... - but have not found any definitive solutions.   I have posted 
this to the soaplite users list without a response.

Any help would be greatly appreciated - Thanks...


Bill Hess

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

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

Hi Jason,

this sounds very good :-)

My first attemt to transfer SOAP::Lite's CVS to SVN failed on sf.net -
but my attempt to re-import a dump of SOAP::Lite's (currently hidden)
SVN failed, too, so I suspect sourceforge's import service to have been
out of order. I'll investigate on this next week - sf.net should be back
on normal operation then (the support desk was closed between christmas
and new year, and they've to catch up first).

I'm currently in the process of refactoring SOAP::Lite into several
modules - but first I need a decent test suite to be sure I don't break
things.

What exactly is the task you got offered: Does it just mean adding
document/literal capabilities to SOAP::Lite, or complete WSDL support
for document/literal in SOAP::Lite?

SOAP::Lite in general supports document/literal messages, but has little
to help developers construct interfaces with that messaging style (and
there's some stuff that gets in the way and has to be turned off for
document/literal messages).

I'm not yet sure about how to integrate complete WSDL support into
SOAP::Lite. Currently, there's three WSDL-based variants available on
CPAN.

First (and oldest) SOAP::Lite's stubmaker, which is not capable of
handling complexType definitions correctly (yet), and emits interfaces
suitable for use with SOAP::Lite's SOAP::Serializer and
SOAP::Deserializer class.

Second, there's SOAP::WSDL, which supports document/literal WSDL
definitions only. It has a wsdl2perl.pl script that emits interface
classes accepting either hash refs or objects of it's own XML Schema
implementation, SOAP::WSDL::XSD.
SOAP::WSDL has extension points for (among others) alternative
Serializers/Deserializers - one alternative Deserializer emits SOAP::SOM
objects, another one plain perl hash refs.
Perhaps the strongest point in SOAP::WSDL is that it also generates
interface documentations as POD - this means you don't need to read the
WSDL to get a interface description, but can refer to the generated pod
which provides information in a style familiar for perl developers.
And SOAP::WSDL is fast - it outruns SOAP::Lite by a factor of 2-5, and I
have a (not yet released) XS-based XML parser which outruns SOAP::Lite
by a factor of 4-20 (dependent on usage scenario).

Third, there's XML::Compile::SOAP, which features something probably
described best as parser generator based on WSDL files.
XML::Compile::SOAP basically creates recursive-descendent
parser/generator functions (as code references), which are then used to
parse or generate SOAP XML message with the help of XML::LibXML. The
strongest point in XML::Compile is probably the complete coverage of the
WSDL and XML Schema standard (this is what the author claims, I haven't
reviewd it yet). XML::Compile has little extension points yet (only for
the transport layer, as far as I know), but it's a young module, so
there may be more to come. 
XML::Compile currently performs around 1/3 faster than SOAP::Lite.

So, if your task means adding document/literal WSDL support, the
difficult part is to decide where the journey should go to - or to
define and create some common integration layer all of the current
variants can plug into (which I would prefer).

Looking forward to hear more from you,

Martin

Am Sonntag, den 06.01.2008, 01:12 +0530 schrieb Jason Stewart:
> 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.
> 
> -------------------------------------------------------------------------
> 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
>