soaplite-devel — SOAP::Lite developers

Re: [Soaplite-devel] [rt.cpan.org #29505] Namespace having prefix soap in WSDL file used in soap envelope

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

Actually, I fell into the same pit in SOAP::WSDL some time ago.

Am Samstag, den 15.03.2008, 17:29 -0400 schrieb Martin Kutter via RT:
> <URL: http://rt.cpan.org/Ticket/Display.html?id=29505 >
> 
> This is due to the way namespaces are handled in SOAP::Lite - prefixes
> and namespaces are placed into a hash with namespaces as keys and
> prefixes as values. When the envelope is created, the hash is reversed,
> thus namespaces registered with conflicting prefixes wipe out each other.
> 
> The required fix is to reverse namespace handling - namespaces must be
> registered with their associated prefixes as keys, and the namespace
> names as values. This is required for associating multiple prefixes with
> the same namespace, too.
> 
> 
> 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] [rt.cpan.org #29505] Namespace having prefix soap in WSDL file used in soap envelope

[Martin K. v. R. <bug...@rt...>]

<URL: http://rt.cpan.org/Ticket/Display.html?id=29505 >

This is due to the way namespaces are handled in SOAP::Lite - prefixes
and namespaces are placed into a hash with namespaces as keys and
prefixes as values. When the envelope is created, the hash is reversed,
thus namespaces registered with conflicting prefixes wipe out each other.

The required fix is to reverse namespace handling - namespaces must be
registered with their associated prefixes as keys, and the namespace
names as values. This is required for associating multiple prefixes with
the same namespace, too.


Martin

[Soaplite-devel] SOAP::Lite namespaces

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

Some time ago, Paul has argued against moving the SOAP::Lite modules
into the SOAP::Lite namespace. After some sleep on the issue, there's
some point in it: Paul wrote a book about SOAP::Lite (and other
modules), and the book would become useless if we changed every name.

However, I think that using alien namespaces is one of the rather
misfortunate design choices in SOAP::Lite. I think we should move
everything we can, but leave the stuff documented in the book.

The list of modules from the book is here:

SOAP::Client
SOAP::Constants
SOAP::Data
SOAP::Header
SOAP::Lite
SOAP::SOM
SOAP::Fault
SOAP::Transport (and all below)
SOAP::Schema
SOAP::Schema::WSDL

SOAP::Serializer - namespace clash with SOAP package
SOAP::Server (and below)
SOAP::Trace
Apache::SOAP
UDDI::Lite
UDDI::Data
UDDI::SOM
UDDI::Serializer
UDDI::Deserializer

As you might have noted, theres one module in the list -
SOAP::Serializer - which causes a conflict with the SOAP distribution
(and effectively prevents using SOAP and SOAP::Lite in the same program
- the one loaded later breaks the other). I think this one should be
moved as well, but a dummy package adde in SOAP::Lite, which does
nothing else than loading SOAP::Lite::Serializer

Martin

Re: [Soaplite-devel] Data type detection

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

Hi David,

Convert::Scalar unfortunately is not an option, as it requires at least
perl 5.8.0

SOAP::Lite currently supports perls as old as 5.5.4, and will continue
to support 5.6 for some time (there's still systems shipped with 5.6 as
their default perl).

Thanks for the idea,

Martin

Am Samstag, den 08.03.2008, 15:38 -0800 schrieb David Aguilar:
> NOTE: I am not subscribed to the devel list, so please CC: me on all
> replies.  Thank you!
> 
> 
> The last time I checked (which may have been around the 0.67 days)
> SOAP::Lite was using regular expressions to decide how to encode a
> value.  So, for instance, a string that looked like "1.40" would get
> interpreted as being a (?) xsd:float and we'd lose the trailing zero
> when it makes it to the receiver (assuming the server is soap::lite
> and is generating the "1.40" string).
> 
> The simplest way to reproduce this is to return a hash ref such as:
> {
>   "this should be a string" => "1.40",
> }
> 
> After digging into this further I discovered the Sv*OK family of
> perlapi macros.  These allow you to test the underlying C datatype and
> determine the true "type" of a scalar without having to use regular
> expressions (and thus, is probably faster too).
> 
> Currently, these macros are exported by the Convert::Scalar module:
> http://search.cpan.org/~mlehmann/Convert-Scalar-1.04/Scalar.pm
> 
> I just finished helping the c::s author update the API so that it is
> compatible with perl 5.10's perlapi.  If you are using 5.10 (or
> debian, which has backported the api changes to 5.8.8) then use c::s
> 1.04.  c::s 1.03 is suitable for pre-5.10.
> 
> So.. long story short:
> Would the developers of SOAP::Lite be adverse to adding a dependency
> on Convert::Scalar so that SOAP::Lite's value type-detection routine
> can use Convert::Scalar's nok and pok functions for helping to
> determine a scalar's underlying type?
> 
> I'm asking because I haven't yet written these patches and would like
> to know whether an additional dependency would be accepted upstream or
> whether this is a change that I'll have to apply to my local tree and
> maintain separately.
> 
> As it is, there is no other way to test the type of a perl scalar.
> Perl scalars are too magical because of the autoconversion between
> double, int, and string.  Convert::Scalar lets us cheat and use the
> perlapi to ask these questions, which is both more robust and faster
> than using regular expressions.
> 
> Thoughts?
> 

[Soaplite-devel] Data type detection

[David A. <da...@gm...>]

NOTE: I am not subscribed to the devel list, so please CC: me on all
replies.  Thank you!


The last time I checked (which may have been around the 0.67 days)
SOAP::Lite was using regular expressions to decide how to encode a
value.  So, for instance, a string that looked like "1.40" would get
interpreted as being a (?) xsd:float and we'd lose the trailing zero
when it makes it to the receiver (assuming the server is soap::lite
and is generating the "1.40" string).

The simplest way to reproduce this is to return a hash ref such as:
{
  "this should be a string" => "1.40",
}

After digging into this further I discovered the Sv*OK family of
perlapi macros.  These allow you to test the underlying C datatype and
determine the true "type" of a scalar without having to use regular
expressions (and thus, is probably faster too).

Currently, these macros are exported by the Convert::Scalar module:
http://search.cpan.org/~mlehmann/Convert-Scalar-1.04/Scalar.pm

I just finished helping the c::s author update the API so that it is
compatible with perl 5.10's perlapi.  If you are using 5.10 (or
debian, which has backported the api changes to 5.8.8) then use c::s
1.04.  c::s 1.03 is suitable for pre-5.10.

So.. long story short:
Would the developers of SOAP::Lite be adverse to adding a dependency
on Convert::Scalar so that SOAP::Lite's value type-detection routine
can use Convert::Scalar's nok and pok functions for helping to
determine a scalar's underlying type?

I'm asking because I haven't yet written these patches and would like
to know whether an additional dependency would be accepted upstream or
whether this is a change that I'll have to apply to my local tree and
maintain separately.

As it is, there is no other way to test the type of a perl scalar.
Perl scalars are too magical because of the autoconversion between
double, int, and string.  Convert::Scalar lets us cheat and use the
perlapi to ask these questions, which is both more robust and faster
than using regular expressions.

Thoughts?

-- 
    David

p.s. here is the link to the perlapi reference.  The "pok" and "nok"
are the Convert::Scalar exported names for SvPOK and SvNOK:
http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perlapi.pod#SV_Manipulation_Functions

(scroll down a little from the link or search for "SvPOK")
Thanks for SOAP::Lite, btw!

Re: [Soaplite-devel] Soaplite-devel Digest, Vol 15, Issue 2

[Eric S. <sau...@as...>]

> As we're free to use Test::More now (5.005's gone :-), the best way
> probably is:
>
> ... in .t script:
>
> use Test::More;
> eval "require Net::Jabber" or plan "skip_all";
> plan tests => 42;
>

If it's just one or two tests that fail due to explicit dependencies, then 
you might consider skipping them explicitly in a named block, rather than 
bypassing the whole .t. From the Test::More manpage:

                SKIP: {
                    eval { require HTML::Lint };

                    skip "HTML::Lint not installed", 2 if $@;

                    my $lint = new HTML::Lint;
                    isa_ok( $lint, "HTML::Lint" );

                    $lint->parse( $html );
                    is( $lint->errors, 0, "No errors found in HTML" );
                }

            If the user does not have HTML::Lint installed, the whole block
            of code won't be run at all.  Test::More will output special
            ok's which Test::Harness interprets as skipped, but passing,
            tests.

Cheers

Eric

Re: [Soaplite-devel] [Soaplite-commit] SF.net SVN: soaplite: [208] trunk

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

The test_perls.pl won't help without the perls installed - it's actually
as simple as

use Test::More;
my @perl_from = (
	'/opt/perl5.6.2/bin/perl',
        '/opt/perl-5.8.7/bin/perl',
        '/opt/perl5.10/bin/perl',
        '/usr/bin/perl'
);
plan tests => scalar @perl_from;
for my $perl (@perl_from) {
        ok ! system("make clean > /dev/null 2>&1; \\
                $perl Makefile.PL --noprompt > /dev/null 2>&1 \\
                && make > /dev/null 2>&1 \\
                && make test > /dev/null 2>&1")
        ), $perl;
}

Martin

Am Sonntag, den 02.03.2008, 22:57 +0000 schrieb Robbie Bow:
> Excellent! There's a couple that fail on one of my machines -
> 
> not ok 73 - Syntax check ../lib/SOAP/Transport/JABBER.pm
> # Can't locate Net/Jabber.pm in @INC (@INC contains: ../lib
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
> 
> not ok 75 - Syntax check ../lib/SOAP/Transport/MQ.pm
> # Can't locate MQClient/MQSeries.pm in @INC (@INC contains: ../lib
> .....) at ../lib/SOAP/Transport/MQ.pm line 17.
> 
> As these are optional, what would be the best way to check for the
> required dependencies and gracefully bow out if they aren't installed?
> I was thinking something along the lines of:
> 
> eval "use Net::Jabber";
> die "Problem loading pre-requisite Net::Jabber - is this installed?" if $@;
> 
> Or I suppose we could add them to the prerequisites for SOAP::Lite anyway?
> 
> Also, could you give me a copy of your test_perls.pl script? Sounds handy.
> 
> Robbie
> 
> On Sun, Mar 2, 2008 at 10:46 PM, Martin Kutter <mar...@fe...> wrote:
> > Well done: Test suite passes under all my perls.
> >
> >  martin@cyclops:~/workspace/SOAP-Lite$ perl test_perls.pl
> >  1..4
> >  ok 1 - /opt/perl5.6.2/bin/perl
> >  ok 2 - /opt/perl-5.8.7/bin/perl
> >  ok 3 - /opt/perl5.10/bin/perl
> >  ok 4 - /usr/bin/perl (5.8.8)
> >
> >  Martin
> >
> >  Am Sonntag, den 02.03.2008, 13:35 -0800 schrieb
> >  rob...@us...:
> >
> >
> > > Revision: 208
> >  >           http://soaplite.svn.sourceforge.net/soaplite/?rev=208&view=rev
> >  > Author:   robbiebow
> >  > Date:     2008-03-02 13:35:00 -0800 (Sun, 02 Mar 2008)
> >  >
> >  > Log Message:
> >  > -----------
> >  > Added strict and syntax checking for lib/ and t/ directories. Modified files to pass these tests
> >  >
> >  > Modified Paths:
> >  > --------------
> >  >     trunk/lib/SOAP/Cloneable.pm
> >  >     trunk/lib/SOAP/Constants.pm
> >  >     trunk/lib/SOAP/Data.pm
> >  >     trunk/lib/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.pm
> >  >     trunk/lib/SOAP/Lite.pm
> >  >     trunk/lib/SOAP/Utils.pm
> >  >     trunk/lib/XMLRPC/Lite.pm
> >  >     trunk/t/01-core.t
> >  >     trunk/t/013-array-deserialization.t
> >  >     trunk/t/014_UNIVERSAL_use.t
> >  >     trunk/t/015_UNIVERSAL_can.t
> >  >     trunk/t/02-payload.t
> >  >     trunk/t/03-server.t
> >  >     trunk/t/04-attach.t
> >  >     trunk/t/05-customxml.t
> >  >     trunk/t/06-modules.t
> >  >     trunk/t/07-xmlrpc_payload.t
> >  >     trunk/t/08-schema.t
> >  >     trunk/t/099_pod_coverage.t
> >  >     trunk/t/11-cgi.t
> >  >     trunk/t/12-cgi_https.t
> >  >     trunk/t/13-mod_perl.t
> >  >     trunk/t/14-cgi_apache.t
> >  >     trunk/t/15-daemon.t
> >  >     trunk/t/16-tcp.t
> >  >     trunk/t/17-mod_soap.t
> >  >     trunk/t/19-apachesoap.t
> >  >     trunk/t/21-public.t
> >  >     trunk/t/22-interop_apache.t
> >  >     trunk/t/23-ppm.t
> >  >     trunk/t/24-wsdl.t
> >  >     trunk/t/25-uddi.t
> >  >     trunk/t/26-xmlrpc.t
> >  >     trunk/t/27-xmlparserlite.t
> >  >     trunk/t/28-uddi_search.t
> >  >     trunk/t/29-uddi_publishing.t
> >  >     trunk/t/36-leaks.t
> >  >     trunk/t/37-mod_xmlrpc.t
> >  >     trunk/t/38-packager.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema1999.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema2001.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_1.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.t
> >  >     trunk/t/SOAP/Schema/WSDL.t
> >  >     trunk/t/TEST.pl
> >  >
> >  > Added Paths:
> >  > -----------
> >  >     trunk/lib/OldDocs/SOAP/Lite.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/IO.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pod
> >  >     trunk/t/00-strict.t
> >  >
> >  > Removed Paths:
> >  > -------------
> >  >     trunk/lib/OldDocs/SOAP/Lite.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/IO.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pm
> >  >
> >  >
> >  > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> >  >
> >  > -------------------------------------------------------------------------
> >  > 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-commit mailing list
> >  > soa...@li...
> >  > https://lists.sourceforge.net/lists/listinfo/soaplite-commit
> >  >
> >
> >
> 
> -------------------------------------------------------------------------
> 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] [Soaplite-commit] SF.net SVN: soaplite: [208] trunk

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

oops, gotcha (or better: me).

As we're free to use Test::More now (5.005's gone :-), the best way
probably is:

... in .t script:

use Test::More;
eval "require Net::Jabber" or plan "skip_all";
plan tests => 42;

Which of the test scripts failed?

Martin


Am Sonntag, den 02.03.2008, 22:57 +0000 schrieb Robbie Bow:
> Excellent! There's a couple that fail on one of my machines -
> 
> not ok 73 - Syntax check ../lib/SOAP/Transport/JABBER.pm
> # Can't locate Net/Jabber.pm in @INC (@INC contains: ../lib
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
> 
> not ok 75 - Syntax check ../lib/SOAP/Transport/MQ.pm
> # Can't locate MQClient/MQSeries.pm in @INC (@INC contains: ../lib
> .....) at ../lib/SOAP/Transport/MQ.pm line 17.
> 
> As these are optional, what would be the best way to check for the
> required dependencies and gracefully bow out if they aren't installed?
> I was thinking something along the lines of:
> 
> eval "use Net::Jabber";
> die "Problem loading pre-requisite Net::Jabber - is this installed?" if $@;
> 
> Or I suppose we could add them to the prerequisites for SOAP::Lite anyway?
> 
> Also, could you give me a copy of your test_perls.pl script? Sounds handy.
> 
> Robbie
> 
> On Sun, Mar 2, 2008 at 10:46 PM, Martin Kutter <mar...@fe...> wrote:
> > Well done: Test suite passes under all my perls.
> >
> >  martin@cyclops:~/workspace/SOAP-Lite$ perl test_perls.pl
> >  1..4
> >  ok 1 - /opt/perl5.6.2/bin/perl
> >  ok 2 - /opt/perl-5.8.7/bin/perl
> >  ok 3 - /opt/perl5.10/bin/perl
> >  ok 4 - /usr/bin/perl (5.8.8)
> >
> >  Martin
> >
> >  Am Sonntag, den 02.03.2008, 13:35 -0800 schrieb
> >  rob...@us...:
> >
> >
> > > Revision: 208
> >  >           http://soaplite.svn.sourceforge.net/soaplite/?rev=208&view=rev
> >  > Author:   robbiebow
> >  > Date:     2008-03-02 13:35:00 -0800 (Sun, 02 Mar 2008)
> >  >
> >  > Log Message:
> >  > -----------
> >  > Added strict and syntax checking for lib/ and t/ directories. Modified files to pass these tests
> >  >
> >  > Modified Paths:
> >  > --------------
> >  >     trunk/lib/SOAP/Cloneable.pm
> >  >     trunk/lib/SOAP/Constants.pm
> >  >     trunk/lib/SOAP/Data.pm
> >  >     trunk/lib/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.pm
> >  >     trunk/lib/SOAP/Lite.pm
> >  >     trunk/lib/SOAP/Utils.pm
> >  >     trunk/lib/XMLRPC/Lite.pm
> >  >     trunk/t/01-core.t
> >  >     trunk/t/013-array-deserialization.t
> >  >     trunk/t/014_UNIVERSAL_use.t
> >  >     trunk/t/015_UNIVERSAL_can.t
> >  >     trunk/t/02-payload.t
> >  >     trunk/t/03-server.t
> >  >     trunk/t/04-attach.t
> >  >     trunk/t/05-customxml.t
> >  >     trunk/t/06-modules.t
> >  >     trunk/t/07-xmlrpc_payload.t
> >  >     trunk/t/08-schema.t
> >  >     trunk/t/099_pod_coverage.t
> >  >     trunk/t/11-cgi.t
> >  >     trunk/t/12-cgi_https.t
> >  >     trunk/t/13-mod_perl.t
> >  >     trunk/t/14-cgi_apache.t
> >  >     trunk/t/15-daemon.t
> >  >     trunk/t/16-tcp.t
> >  >     trunk/t/17-mod_soap.t
> >  >     trunk/t/19-apachesoap.t
> >  >     trunk/t/21-public.t
> >  >     trunk/t/22-interop_apache.t
> >  >     trunk/t/23-ppm.t
> >  >     trunk/t/24-wsdl.t
> >  >     trunk/t/25-uddi.t
> >  >     trunk/t/26-xmlrpc.t
> >  >     trunk/t/27-xmlparserlite.t
> >  >     trunk/t/28-uddi_search.t
> >  >     trunk/t/29-uddi_publishing.t
> >  >     trunk/t/36-leaks.t
> >  >     trunk/t/37-mod_xmlrpc.t
> >  >     trunk/t/38-packager.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema1999.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema2001.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_1.t
> >  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.t
> >  >     trunk/t/SOAP/Schema/WSDL.t
> >  >     trunk/t/TEST.pl
> >  >
> >  > Added Paths:
> >  > -----------
> >  >     trunk/lib/OldDocs/SOAP/Lite.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/IO.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pod
> >  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pod
> >  >     trunk/t/00-strict.t
> >  >
> >  > Removed Paths:
> >  > -------------
> >  >     trunk/lib/OldDocs/SOAP/Lite.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/IO.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pm
> >  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pm
> >  >
> >  >
> >  > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> >  >
> >  > -------------------------------------------------------------------------
> >  > 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-commit mailing list
> >  > soa...@li...
> >  > https://lists.sourceforge.net/lists/listinfo/soaplite-commit
> >  >
> >
> >
> 
> -------------------------------------------------------------------------
> 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] [Soaplite-commit] SF.net SVN: soaplite: [208] trunk

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

Excellent! There's a couple that fail on one of my machines -

not ok 73 - Syntax check ../lib/SOAP/Transport/JABBER.pm
# Can't locate Net/Jabber.pm in @INC (@INC contains: ../lib
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi

not ok 75 - Syntax check ../lib/SOAP/Transport/MQ.pm
# Can't locate MQClient/MQSeries.pm in @INC (@INC contains: ../lib
.....) at ../lib/SOAP/Transport/MQ.pm line 17.

As these are optional, what would be the best way to check for the
required dependencies and gracefully bow out if they aren't installed?
I was thinking something along the lines of:

eval "use Net::Jabber";
die "Problem loading pre-requisite Net::Jabber - is this installed?" if $@;

Or I suppose we could add them to the prerequisites for SOAP::Lite anyway?

Also, could you give me a copy of your test_perls.pl script? Sounds handy.

Robbie

On Sun, Mar 2, 2008 at 10:46 PM, Martin Kutter <mar...@fe...> wrote:
> Well done: Test suite passes under all my perls.
>
>  martin@cyclops:~/workspace/SOAP-Lite$ perl test_perls.pl
>  1..4
>  ok 1 - /opt/perl5.6.2/bin/perl
>  ok 2 - /opt/perl-5.8.7/bin/perl
>  ok 3 - /opt/perl5.10/bin/perl
>  ok 4 - /usr/bin/perl (5.8.8)
>
>  Martin
>
>  Am Sonntag, den 02.03.2008, 13:35 -0800 schrieb
>  rob...@us...:
>
>
> > Revision: 208
>  >           http://soaplite.svn.sourceforge.net/soaplite/?rev=208&view=rev
>  > Author:   robbiebow
>  > Date:     2008-03-02 13:35:00 -0800 (Sun, 02 Mar 2008)
>  >
>  > Log Message:
>  > -----------
>  > Added strict and syntax checking for lib/ and t/ directories. Modified files to pass these tests
>  >
>  > Modified Paths:
>  > --------------
>  >     trunk/lib/SOAP/Cloneable.pm
>  >     trunk/lib/SOAP/Constants.pm
>  >     trunk/lib/SOAP/Data.pm
>  >     trunk/lib/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.pm
>  >     trunk/lib/SOAP/Lite.pm
>  >     trunk/lib/SOAP/Utils.pm
>  >     trunk/lib/XMLRPC/Lite.pm
>  >     trunk/t/01-core.t
>  >     trunk/t/013-array-deserialization.t
>  >     trunk/t/014_UNIVERSAL_use.t
>  >     trunk/t/015_UNIVERSAL_can.t
>  >     trunk/t/02-payload.t
>  >     trunk/t/03-server.t
>  >     trunk/t/04-attach.t
>  >     trunk/t/05-customxml.t
>  >     trunk/t/06-modules.t
>  >     trunk/t/07-xmlrpc_payload.t
>  >     trunk/t/08-schema.t
>  >     trunk/t/099_pod_coverage.t
>  >     trunk/t/11-cgi.t
>  >     trunk/t/12-cgi_https.t
>  >     trunk/t/13-mod_perl.t
>  >     trunk/t/14-cgi_apache.t
>  >     trunk/t/15-daemon.t
>  >     trunk/t/16-tcp.t
>  >     trunk/t/17-mod_soap.t
>  >     trunk/t/19-apachesoap.t
>  >     trunk/t/21-public.t
>  >     trunk/t/22-interop_apache.t
>  >     trunk/t/23-ppm.t
>  >     trunk/t/24-wsdl.t
>  >     trunk/t/25-uddi.t
>  >     trunk/t/26-xmlrpc.t
>  >     trunk/t/27-xmlparserlite.t
>  >     trunk/t/28-uddi_search.t
>  >     trunk/t/29-uddi_publishing.t
>  >     trunk/t/36-leaks.t
>  >     trunk/t/37-mod_xmlrpc.t
>  >     trunk/t/38-packager.t
>  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema1999.t
>  >     trunk/t/SOAP/Lite/Deserializer/XMLSchema2001.t
>  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_1.t
>  >     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.t
>  >     trunk/t/SOAP/Schema/WSDL.t
>  >     trunk/t/TEST.pl
>  >
>  > Added Paths:
>  > -----------
>  >     trunk/lib/OldDocs/SOAP/Lite.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/IO.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pod
>  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pod
>  >     trunk/t/00-strict.t
>  >
>  > Removed Paths:
>  > -------------
>  >     trunk/lib/OldDocs/SOAP/Lite.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/FTP.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/HTTP.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/IO.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/JABBER.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/MQ.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/POP3.pm
>  >     trunk/lib/OldDocs/SOAP/Transport/TCP.pm
>  >
>  >
>  > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>  >
>  > -------------------------------------------------------------------------
>  > 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-commit mailing list
>  > soa...@li...
>  > https://lists.sourceforge.net/lists/listinfo/soaplite-commit
>  >
>
>

Re: [Soaplite-devel] [Soaplite-commit] SF.net SVN: soaplite: [208] trunk

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

Well done: Test suite passes under all my perls.

martin@cyclops:~/workspace/SOAP-Lite$ perl test_perls.pl 
1..4
ok 1 - /opt/perl5.6.2/bin/perl
ok 2 - /opt/perl-5.8.7/bin/perl
ok 3 - /opt/perl5.10/bin/perl
ok 4 - /usr/bin/perl (5.8.8)

Martin

Am Sonntag, den 02.03.2008, 13:35 -0800 schrieb
rob...@us...:
> Revision: 208
>           http://soaplite.svn.sourceforge.net/soaplite/?rev=208&view=rev
> Author:   robbiebow
> Date:     2008-03-02 13:35:00 -0800 (Sun, 02 Mar 2008)
> 
> Log Message:
> -----------
> Added strict and syntax checking for lib/ and t/ directories. Modified files to pass these tests
> 
> Modified Paths:
> --------------
>     trunk/lib/SOAP/Cloneable.pm
>     trunk/lib/SOAP/Constants.pm
>     trunk/lib/SOAP/Data.pm
>     trunk/lib/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.pm
>     trunk/lib/SOAP/Lite.pm
>     trunk/lib/SOAP/Utils.pm
>     trunk/lib/XMLRPC/Lite.pm
>     trunk/t/01-core.t
>     trunk/t/013-array-deserialization.t
>     trunk/t/014_UNIVERSAL_use.t
>     trunk/t/015_UNIVERSAL_can.t
>     trunk/t/02-payload.t
>     trunk/t/03-server.t
>     trunk/t/04-attach.t
>     trunk/t/05-customxml.t
>     trunk/t/06-modules.t
>     trunk/t/07-xmlrpc_payload.t
>     trunk/t/08-schema.t
>     trunk/t/099_pod_coverage.t
>     trunk/t/11-cgi.t
>     trunk/t/12-cgi_https.t
>     trunk/t/13-mod_perl.t
>     trunk/t/14-cgi_apache.t
>     trunk/t/15-daemon.t
>     trunk/t/16-tcp.t
>     trunk/t/17-mod_soap.t
>     trunk/t/19-apachesoap.t
>     trunk/t/21-public.t
>     trunk/t/22-interop_apache.t
>     trunk/t/23-ppm.t
>     trunk/t/24-wsdl.t
>     trunk/t/25-uddi.t
>     trunk/t/26-xmlrpc.t
>     trunk/t/27-xmlparserlite.t
>     trunk/t/28-uddi_search.t
>     trunk/t/29-uddi_publishing.t
>     trunk/t/36-leaks.t
>     trunk/t/37-mod_xmlrpc.t
>     trunk/t/38-packager.t
>     trunk/t/SOAP/Lite/Deserializer/XMLSchema1999.t
>     trunk/t/SOAP/Lite/Deserializer/XMLSchema2001.t
>     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_1.t
>     trunk/t/SOAP/Lite/Deserializer/XMLSchemaSOAP1_2.t
>     trunk/t/SOAP/Schema/WSDL.t
>     trunk/t/TEST.pl
> 
> Added Paths:
> -----------
>     trunk/lib/OldDocs/SOAP/Lite.pod
>     trunk/lib/OldDocs/SOAP/Transport/FTP.pod
>     trunk/lib/OldDocs/SOAP/Transport/HTTP.pod
>     trunk/lib/OldDocs/SOAP/Transport/IO.pod
>     trunk/lib/OldDocs/SOAP/Transport/JABBER.pod
>     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pod
>     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pod
>     trunk/lib/OldDocs/SOAP/Transport/MQ.pod
>     trunk/lib/OldDocs/SOAP/Transport/POP3.pod
>     trunk/lib/OldDocs/SOAP/Transport/TCP.pod
>     trunk/t/00-strict.t
> 
> Removed Paths:
> -------------
>     trunk/lib/OldDocs/SOAP/Lite.pm
>     trunk/lib/OldDocs/SOAP/Transport/FTP.pm
>     trunk/lib/OldDocs/SOAP/Transport/HTTP.pm
>     trunk/lib/OldDocs/SOAP/Transport/IO.pm
>     trunk/lib/OldDocs/SOAP/Transport/JABBER.pm
>     trunk/lib/OldDocs/SOAP/Transport/LOCAL.pm
>     trunk/lib/OldDocs/SOAP/Transport/MAILTO.pm
>     trunk/lib/OldDocs/SOAP/Transport/MQ.pm
>     trunk/lib/OldDocs/SOAP/Transport/POP3.pm
>     trunk/lib/OldDocs/SOAP/Transport/TCP.pm
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> -------------------------------------------------------------------------
> 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-commit mailing list
> soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-commit
> 

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

I think consistency has the benefit of making development easier for
developers that contribute in the future. Not a major concern but it
can significantly increase productivity in my experience.

On Sun, Mar 2, 2008 at 6:31 PM, Martin Kutter <mar...@fe...> wrote:
> Hi Paul,
>
>  This has not been so much a problem when all packages were in Lite.pm -
>  now, as we're separating packages for maintainability, it is.
>
>  SOAP is still being used - so I'd prefer to resolve the existing
>  conflicts on SOAP::Lite's side.
>
>  The overlapping names are
>
>   SOAP::Serializer
>   SOAP::Packager
>   SOAP::Transport::HTTP::CGI
>   SOAP::Transport::HTTP::Client
>   SOAP::Transport::HTTP::Server
>
>  We could move those and leave the rest - it's a bit inconsistent, but
>  actually I don't care, except for those conflicts.
>
>  Martin
>
>  Am Sonntag, den 02.03.2008, 09:51 -0800 schrieb Paul Kulchenko:
>
>
> > Martin/Robbie,
>  >
>  > I was aware of the SOAP:: namespace when the module was created and I
>  > was careful not to overlap with the modules that were in the SOAP
>  > namespace. It was possible to use both SOAP::Lite and SOAP modules in
>  > the same application for some time. However, after several years I
>  > stopped paying attention to this as the SOAP module didn't seem to be
>  > supported at all and didn't seem to be used much.
>  >
>  > Would it be easier to resolve namespace conflicts in favor of
>  > SOAP::Lite given the current state of the SOAP module instead of
>  > migrating/renaming everything under SOAP::Lite namespace? We can ask
>  > Keith Brown, the author of the SOAP.pm module, if he is okay with
>  > transferring the namespace. The (original) idea was that the main
>  > module is under S::L namespace, while others, like ::Transport and
>  > ::Data will be under SOAP:: namespace to avoid too many levels in the
>  > hierarchy. Probably not the best way, but it seemed to be the most
>  > straightforward at the time. Even now, I don't like the idea of
>  > having everything under S::L namespace.
>  >
>  > Paul.
>  >
>  > --- Martin Kutter <mar...@fe...> wrote:
>  >
>  > > Hi Robbie,
>  > >
>  > > I've just had my first run on the split up SOAP::Lite you did.
>  > > After
>  > > some adjustments, the test suite passed again.
>  > >
>  > > I started moving most modules from the SOAP:: namespace into
>  > > SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
>  > > namespace), so SOAP::Lite won't get indexed on CPAN when containing
>  > > conflicting packages.
>  > > (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
>  > >
>  > > There's a few packages I don't like to be moved in the first run:
>  > >
>  > > SOAP::Data and SOAP::Header: Both are so widely used that moving
>  > > them
>  > > would break almost every SOAP client/server
>  > >
>  > > SOAP::Transport::*: The transport layer is sometimes used from
>  > > other
>  > > distributions.
>  > >
>  > > I'd suggest providing these modules twice - as SOAP:: and
>  > > SOAP::Lite::
>  > > variant in the next release, and marking them as deprecated. This
>  > > way
>  > > users have a chance to catch up...
>  > >
>  > > 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] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Hi Paul,

This has not been so much a problem when all packages were in Lite.pm -
now, as we're separating packages for maintainability, it is.

SOAP is still being used - so I'd prefer to resolve the existing
conflicts on SOAP::Lite's side.

The overlapping names are

 SOAP::Serializer
 SOAP::Packager
 SOAP::Transport::HTTP::CGI
 SOAP::Transport::HTTP::Client
 SOAP::Transport::HTTP::Server

We could move those and leave the rest - it's a bit inconsistent, but
actually I don't care, except for those conflicts.

Martin

Am Sonntag, den 02.03.2008, 09:51 -0800 schrieb Paul Kulchenko:
> Martin/Robbie,
> 
> I was aware of the SOAP:: namespace when the module was created and I
> was careful not to overlap with the modules that were in the SOAP
> namespace. It was possible to use both SOAP::Lite and SOAP modules in
> the same application for some time. However, after several years I
> stopped paying attention to this as the SOAP module didn't seem to be
> supported at all and didn't seem to be used much.
> 
> Would it be easier to resolve namespace conflicts in favor of
> SOAP::Lite given the current state of the SOAP module instead of
> migrating/renaming everything under SOAP::Lite namespace? We can ask
> Keith Brown, the author of the SOAP.pm module, if he is okay with
> transferring the namespace. The (original) idea was that the main
> module is under S::L namespace, while others, like ::Transport and
> ::Data will be under SOAP:: namespace to avoid too many levels in the
> hierarchy. Probably not the best way, but it seemed to be the most
> straightforward at the time. Even now, I don't like the idea of
> having everything under S::L namespace.
> 
> Paul.
> 
> --- Martin Kutter <mar...@fe...> wrote:
> 
> > Hi Robbie,
> > 
> > I've just had my first run on the split up SOAP::Lite you did.
> > After
> > some adjustments, the test suite passed again.
> > 
> > I started moving most modules from the SOAP:: namespace into
> > SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
> > namespace), so SOAP::Lite won't get indexed on CPAN when containing
> > conflicting packages.
> > (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
> > 
> > There's a few packages I don't like to be moved in the first run:
> > 
> > SOAP::Data and SOAP::Header: Both are so widely used that moving
> > them
> > would break almost every SOAP client/server
> > 
> > SOAP::Transport::*: The transport layer is sometimes used from
> > other
> > distributions.
> > 
> > I'd suggest providing these modules twice - as SOAP:: and
> > SOAP::Lite::
> > variant in the next release, and marking them as deprecated. This
> > way
> > users have a chance to catch up...
> > 
> > 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] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Martin/Robbie,

I was aware of the SOAP:: namespace when the module was created and I
was careful not to overlap with the modules that were in the SOAP
namespace. It was possible to use both SOAP::Lite and SOAP modules in
the same application for some time. However, after several years I
stopped paying attention to this as the SOAP module didn't seem to be
supported at all and didn't seem to be used much.

Would it be easier to resolve namespace conflicts in favor of
SOAP::Lite given the current state of the SOAP module instead of
migrating/renaming everything under SOAP::Lite namespace? We can ask
Keith Brown, the author of the SOAP.pm module, if he is okay with
transferring the namespace. The (original) idea was that the main
module is under S::L namespace, while others, like ::Transport and
::Data will be under SOAP:: namespace to avoid too many levels in the
hierarchy. Probably not the best way, but it seemed to be the most
straightforward at the time. Even now, I don't like the idea of
having everything under S::L namespace.

Paul.

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

> Hi Robbie,
> 
> I've just had my first run on the split up SOAP::Lite you did.
> After
> some adjustments, the test suite passed again.
> 
> I started moving most modules from the SOAP:: namespace into
> SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
> namespace), so SOAP::Lite won't get indexed on CPAN when containing
> conflicting packages.
> (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
> 
> There's a few packages I don't like to be moved in the first run:
> 
> SOAP::Data and SOAP::Header: Both are so widely used that moving
> them
> would break almost every SOAP client/server
> 
> SOAP::Transport::*: The transport layer is sometimes used from
> other
> distributions.
> 
> I'd suggest providing these modules twice - as SOAP:: and
> SOAP::Lite::
> variant in the next release, and marking them as deprecated. This
> way
> users have a chance to catch up...
> 
> 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] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Am Sonntag, den 02.03.2008, 09:46 +0000 schrieb Robbie Bow:
> On Sun, Mar 2, 2008 at 8:19 AM, Martin Kutter <mar...@fe...> wrote:
> > Ah, I forgot to mention that I have not deleted the modules moved into
> >  the SOAP/Lite/ hierarchy, so for now they are there in two places.
> >
> 
> Will that be the case for release or is it a temporary state of affairs?

I don't know yet - I guess we'll have to deside that before the next
release. Could make sense to keep some to still allow subclassing - like
SOAP::Serializer - but I think most can be deleted.

Martin

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Ah, I forgot to mention that I have not deleted the modules moved into
the SOAP/Lite/ hierarchy, so for now they are there in two places.

Martin

[Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Hi Robbie,

I've just had my first run on the split up SOAP::Lite you did. After
some adjustments, the test suite passed again.

I started moving most modules from the SOAP:: namespace into
SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
namespace), so SOAP::Lite won't get indexed on CPAN when containing
conflicting packages.
(theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).

There's a few packages I don't like to be moved in the first run:

SOAP::Data and SOAP::Header: Both are so widely used that moving them
would break almost every SOAP client/server

SOAP::Transport::*: The transport layer is sometimes used from other
distributions.

I'd suggest providing these modules twice - as SOAP:: and SOAP::Lite::
variant in the next release, and marking them as deprecated. This way
users have a chance to catch up...

Martin

[Soaplite-devel] Revision 206

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

Hi

This revision merges my branch changes back into trunk, abstracting
*most* of the packages in SOAP/Lite.pm into their own files. They did
pass all tests in branch so hopefully I cleared up the missing
dependencies, e.g. adding use SOAP::Fault in SOAP::SOM. It's highly
likely some of the new packages will be missing some basics, such as
version numbers or use strict, for example. So there's room for a
couple more tests: test for version number present and test for use
strict. I can add these in the next few days unless anyone else offers
to...

Re: [Soaplite-devel] bug and comments

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

Hi Kostas,

I opened a bug report on sf.net and fixed this in SVN.

Thanks for reporting,

Martin

Am Donnerstag, den 28.02.2008, 19:38 +0100 schrieb Kostas
Chatzikokolakis:
> Hello,
> 
> I'd like to report a bug in SOAP::Serializer (appeared, as far as I can
> tell, in version 0.65-beta6), that prevents XMLRPC::Serializer from
> being subclassed. From SOAP::Serializer::encode_object
> 
>   } elsif (UNIVERSAL::isa($object => 'ARRAY')) {
>       # Added in SOAP::Lite 0.65_6 to fix an XMLRPC bug
>       return $self->encodingStyle eq "" ||
>              ref $self eq 'XMLRPC::Serializer' ?
> 	  $self->encode_array($object, $name, $type, $attr) :
> 	  $self->encode_literal_array($object, $name, $type, $attr);
> 
> if you use My::Serializer instead of XMLRPC::Serializer, then the test
>   $self eq 'XMLRPC::Serializer'
> will fail and arrays will not be encoded correctly. A simple fix is to
> change the test to
>   UNIVERSAL::isa($self, 'XMLRPC::Serializer')
> 
> 
> Another comment wrt subclassing the serializers: many functions call
> new() on an object, due do statements of the form:
>   my $self = shift->new;
> As a consequence, when you subclass a serializer your constructor is
> called multiple times, unless you add a test like
>   return $self if ref $self;
> This is an unnatural behaviour and should be written in the
> documentation. Or better, these statements should be replaced by the
> faster and saner:
>   my $self = ref $_[0] ? shift : shift->new;
> or something similar.
> 
> 
> That's all for now. Thanks a lot for this great module. I was also
> pleased to see the announcement of 0.70 and the recent activity in the
> mailing list.
> 
> Kostas
> 
> 
> 
> -------------------------------------------------------------------------
> 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] bug and comments

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

Meant to send this to the list...

---------- Forwarded message ----------
From: Jason Stewart <jas...@gm...>
Date: 29 Feb 2008 08:26
Subject: Re: [Soaplite-devel] bug and comments
To: Kostas Chatzikokolakis <ko...@ch...>


Hey,


 On 29/02/2008, Kostas Chatzikokolakis <ko...@ch...> wrote:

 >  if you use My::Serializer instead of XMLRPC::Serializer, then the test
 >   $self eq 'XMLRPC::Serializer'
 >  will fail and arrays will not be encoded correctly. A simple fix is to
 >  change the test to
 >   UNIVERSAL::isa($self, 'XMLRPC::Serializer')


looks like a bug...


 >  Another comment wrt subclassing the serializers: many functions call
 >  new() on an object, due do statements of the form:
 >   my $self = shift->new;
 >  As a consequence, when you subclass a serializer your constructor is
 >  called multiple times


hmmm...

 I'm not sure what the purpose of that code is, but it looks like a
 typical copy constructor idiom. The method wants to use a temporary
 copy of your object so as not to change the state so it makes a copy
 by calling new() on the object. If that is so, then your solution of
 just returning the object could lead into strange behavior.

 Perhaps Martin or others can clarify.

 Cheers, jas.

[Soaplite-devel] SOAP-Lite-0.71

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

Hi,

I just put SOAP-Lite-0.71 on CPAN and sf.net

A PPM package is available from sf.net, too.

Enjoy,

Martin

[Soaplite-devel] bug and comments

[Kostas C. <ko...@ch...>]

Hello,

I'd like to report a bug in SOAP::Serializer (appeared, as far as I can
tell, in version 0.65-beta6), that prevents XMLRPC::Serializer from
being subclassed. From SOAP::Serializer::encode_object

  } elsif (UNIVERSAL::isa($object => 'ARRAY')) {
      # Added in SOAP::Lite 0.65_6 to fix an XMLRPC bug
      return $self->encodingStyle eq "" ||
             ref $self eq 'XMLRPC::Serializer' ?
	  $self->encode_array($object, $name, $type, $attr) :
	  $self->encode_literal_array($object, $name, $type, $attr);

if you use My::Serializer instead of XMLRPC::Serializer, then the test
  $self eq 'XMLRPC::Serializer'
will fail and arrays will not be encoded correctly. A simple fix is to
change the test to
  UNIVERSAL::isa($self, 'XMLRPC::Serializer')


Another comment wrt subclassing the serializers: many functions call
new() on an object, due do statements of the form:
  my $self = shift->new;
As a consequence, when you subclass a serializer your constructor is
called multiple times, unless you add a test like
  return $self if ref $self;
This is an unnatural behaviour and should be written in the
documentation. Or better, these statements should be replaced by the
faster and saner:
  my $self = ref $_[0] ? shift : shift->new;
or something similar.


That's all for now. Thanks a lot for this great module. I was also
pleased to see the announcement of 0.70 and the recent activity in the
mailing list.

Kostas

[Soaplite-devel] Logging Patch to 0.67

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

I recently had the need to log SOAP method calls to a log file.  With 
several hundred existing methods, changing each wasn't really an option. 
  I hacked the SOAP/Lite.pm handle method so it would log the incoming 
method name and parameters.  It does this if running in the MOD_PERL 
environment, and if a dir_config is set.

It's not fancy. But it logs in the following format:

[Wed Feb  6 16:00:01 2008] 1.2.3.4 soap_call_method_name ("key1", 
"value1",...)

I've attached diff -u output.

In a perfect world, the code would lock the logfile, or at least check 
to see if it could be opened...  As I said... it was just hacked in. 
And so far, has been incredibly useful, at least to me.

If this looks like a useful feature to others, I can clean it up a bit 
for the 0.70 release.

Rob

[Soaplite-devel] Fault to locate method

[Enrique J. H. B. <ejh...@wa...>]

Hi all,

We're using SOAP::Lite in eBox [1], a SME server. We're using SOAP::Lite
in both sides, client and server.

We are experiencing some problems related to the module loading in
server side when more than one process are serving requests. The
obtained "faultstring" is as follows:


Failed to locate method (foo) in class (EBox::Services::MockService)
at /usr/share/perl5/SOAP/Lite.pm line 2589.

I have read about issues regarding to the URI. However, we are testing
with Apache2 mpm-worker. It completely works when a single instance is
set.

We've done some researching and we have found that
EBox::Services::MockService is not loaded (%INC) when the exception
arises, which happens from time to time. Loading manually that module on
Lite.pm code works flawlessly. 

There is any solution to make it work with several servers working at
once in a server.

I dump my configuration to make it clearer:

apache2.conf:

<IfModule mpm_worker_module>
    StartServers          1
    MaxClients          150
    MinSpareThreads      5
    MaxSpareThreads      10
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

<VirtualHost 10.200.0.30>
...
        <Location /soap>
                SetHandler perl-script
                PerlResponseHandler Apache2::SOAP
                PerlSetVar dispatch_to "/usr/share/perl5,
EBox::Services::MockService"
        </Location>
...
</VirtualHost>

Client side:

my $soapConn = new SOAP::Lite(
      uri   => 'http://ebox-services.com/EBox/Services/MockService',
      proxy => 'https://10.200.0.30/soap,
);

$soapConn->call(foo => @params);

My configuration:

SOAP::Lite 0.69
Apache2::SOAP 0.72
Mod_perl 2.0.2-2.4
Apache worker-mpm 2.2.3
Debian etch

Any help will be appreciated to make it work with more than one
listening server.

Thanks very much for your project!

Re: [Soaplite-devel] SOAP-Lite-0.70_07

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

Yup, looks just fine...
...I'll push it out tomorrow...

Am Mittwoch, den 27.02.2008, 22:35 +0000 schrieb Robbie Bow:
> On Mon, Feb 25, 2008 at 9:51 PM, Martin Kutter <mar...@fe...> wrote:
> >
> >  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.
> >
> 
> Just checked the Testers report: looks good to go...
> 

[Soaplite-devel] VTD-XML 2.3 released

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

VTD-XML 2.3 is now released. To download the latest version please visit
http://sourceforge.net/project/showfiles.php?group_id=110612&package_id=120172.

Below is a list of new features and enhancements in this version.

  a.. VTDException is now introduced as the root class for all other
VTD-XML's exception classes (per suggestion of Max Rahder).
  b.. Transcoding capability is now added for inter-document cut and paste.
You can cut a chuck of bytes in a UTF-8 encoded document and paste it into a
UTF-16 encoded document and the output document is still well-formed.
  c.. ISO-8859-10, ISO-8859-11, ISO-8859-12, ISO-8859-13, ISO-8859-14 and
ISO-8859-15 support has now been added
  d.. Zero length Text node is now possible.
  e.. Ability to dump in-memory copy of text is added.
  f.. Various code cleanup, enhancement and bug fixes.

Below are some new articles related to VTD-XML

  a.. Index XML documents with VTD-XML
http://xml.sys-con.com/read/453082.htm
  b.. Manipulate XML content the Ximple Way
http://www.devx.com/xml/Article/36379
  c.. VTD-XML: A new vision of XML
http://www.developer.com/xml/article.php/3714051
  d.. VTD-XML: XML Processing for the future
http://www.codeproject.com/KB/cs/vtd-xml_examples.aspx

If you (or someone you know) like the concept of VTD-XML, think that it can
help solve enterprises' XML processing related issues (particularly those
related to SOA), and would like to directly influence and contribute to the
development of the future of Internet, please email me
cra...@co...). We are looking for open source software developers
and project management people to take VTD-XML to the next level.