Loading ...
Sorry, an error occurred while loading the content.

server script package puzzlement

Expand Messages
  • gyles19
    I m prototyping a distributed build system modeled vaguely after Mozilla s Tinderbox, but using SOAP for the message passing. I have a client/server pair which
    Message 1 of 4 , Mar 1 5:03 PM
    • 0 Attachment
      I'm prototyping a distributed build system modeled vaguely after
      Mozilla's Tinderbox, but using SOAP for the message passing.

      I have a client/server pair which allows me to trigger a build and
      receive a result. That's working just fine.

      The problem I'm having is possibly just a misunderstanding on my part
      regarding packages and SOAP methods, so I expect the answer is a
      'duh', but I sure can't find it.

      Here's a snippet of code I've been working on all afternoon:

      use SOAP::Lite +trace => 'all';
      use SOAP::Transport::HTTP;

      SOAP::Transport::HTTP::CGI
      -> dispatch_to('cvsBuildC')
      -> options({compress_threshold => 10000})
      -> handle;

      package cvsBuildC;

      use strict;
      use vars qw($foobar);
      $foobar = "Baz";

      sub build {
      my $self=shift;
      ....
      print STDERR "Foobar=";
      print STDERR $foobar;
      print STDERR $cvsBuildC::foobar;
      print STDERR $self->foobar;
      }

      Basically, I have been totally unsuccessful at getting my soap methods
      to access global variables of *any* sort. If I don't define it
      directly within the method, it doesn't exist when I need it later.

      I've studied every exmaple of soap server code I can find using global
      or package variables, and duplicated the presense/absense of 'use
      strict', 'use vars qw($foobar)', and package reference methods, but
      every one of them ends up giving me "Foobar=" with no value. The only
      version that works is when I explicitly define 'my $foobar="crap!"'
      directly in the build method.

      What I really want to do is to be able to define globals that contain
      static information like the paths to data, local commands, settings,
      etc. The lack of a functional global variable has already cost me
      time today because I've had to put them directly into the various
      methods, and I missed a change. :p


      I'm using perl 5.6.1 and SoapLite 0.51, along with everything needed
      from CPAN as of Monday morning, so I'm pretty sure everything is current.

      Any suggestions as to what might be wrong with my code would be most
      welcome. Thanks for your time!
    • Duncan Cameron
      ... Unless you are running under mod_perl, there s no persistence when you run a CGI script. The web server runs your script as a separate process for each
      Message 2 of 4 , Mar 2 1:24 AM
      • 0 Attachment
        On 2002-03-02 gyles19 wrote:
        >I'm prototyping a distributed build system modeled vaguely after
        >Mozilla's Tinderbox, but using SOAP for the message passing.
        >
        >I have a client/server pair which allows me to trigger a build and
        >receive a result. That's working just fine.
        >
        >The problem I'm having is possibly just a misunderstanding on my part
        >regarding packages and SOAP methods, so I expect the answer is a
        >'duh', but I sure can't find it.
        >
        >Here's a snippet of code I've been working on all afternoon:
        >
        > use SOAP::Lite +trace => 'all';
        > use SOAP::Transport::HTTP;
        >
        > SOAP::Transport::HTTP::CGI
        > -> dispatch_to('cvsBuildC')
        > -> options({compress_threshold => 10000})
        > -> handle;
        >
        > package cvsBuildC;
        >
        > use strict;
        > use vars qw($foobar);
        > $foobar = "Baz";
        >
        > sub build {
        > my $self=shift;
        > ....
        > print STDERR "Foobar=";
        > print STDERR $foobar;
        > print STDERR $cvsBuildC::foobar;
        > print STDERR $self->foobar;
        > }
        >
        >Basically, I have been totally unsuccessful at getting my soap methods
        >to access global variables of *any* sort. If I don't define it
        >directly within the method, it doesn't exist when I need it later.
        >
        >I've studied every exmaple of soap server code I can find using global
        > or package variables, and duplicated the presense/absense of 'use
        >strict', 'use vars qw($foobar)', and package reference methods, but
        >every one of them ends up giving me "Foobar=" with no value. The only
        >version that works is when I explicitly define 'my $foobar="crap!"'
        >directly in the build method.
        >
        >What I really want to do is to be able to define globals that contain
        >static information like the paths to data, local commands, settings,
        >etc. The lack of a functional global variable has already cost me
        >time today because I've had to put them directly into the various
        >methods, and I missed a change. :p
        >
        >
        >I'm using perl 5.6.1 and SoapLite 0.51, along with everything needed
        >from CPAN as of Monday morning, so I'm pretty sure everything is current.
        >
        >Any suggestions as to what might be wrong with my code would be most
        >welcome. Thanks for your time!
        >
        Unless you are running under mod_perl, there's no persistence when
        you run a CGI script. The web server runs your script as a separate
        process for each SOAP message. So, any global variables which one
        instance uses are not available to other instances.

        This isn't a problem with SOAP::Lite, just the way that CGI works.
        If you run your code as a http daemon, then you can have global
        variables, but note that the variables will disappear when the
        server process terminates. Maybe you want to consider writing
        them to a file after each request message, or maybe use DB::File
        to tie a hash to a file.

        Regards,
        Duncan Cameron
      • Joi Ellis
        ... Thanks for responding. I m still confused, though. I ve been writing CGI scripts without mod_perl for years, so I m quite familar with the data
        Message 3 of 4 , Mar 2 10:09 AM
        • 0 Attachment
          On Sat, 2 Mar 2002, Duncan Cameron wrote:

          > Unless you are running under mod_perl, there's no persistence when
          > you run a CGI script. The web server runs your script as a separate
          > process for each SOAP message. So, any global variables which one
          > instance uses are not available to other instances.
          >
          > This isn't a problem with SOAP::Lite, just the way that CGI works.
          > If you run your code as a http daemon, then you can have global
          > variables, but note that the variables will disappear when the
          > server process terminates. Maybe you want to consider writing
          > them to a file after each request message, or maybe use DB::File
          > to tie a hash to a file.
          >
          > Regards,
          > Duncan Cameron

          Thanks for responding. I'm still confused, though. I've been writing
          CGI scripts without mod_perl for years, so I'm quite familar with the
          data persistence issues. However, If I call a cgi script that
          has the format:

          use vars qw($foo);
          $foo="bar";
          print &page();

          sub page {
          return "Foo: $foo";
          }

          Then the result will print "Foo=bar".

          This isn't happening with my calls to SOAP::Lite, even when I model
          my definitions exactly as shown in some of the examples. Is there
          an unstated difference in that he's writing them for mod_perl and
          I'm not?

          It as if SOAP::Lite isn't even running my global setup code. I'm
          only calling the service once, so why are the globals getting lost?
          Why aren't they getting written to my package namespace where they
          can be accessed during THE SAME EXECUTION? How do I define constants
          without having to explicitly repeat them in every single service method?
          Do I need to make a setGlobals() routine to do it and call that from
          the service methods? None of his examples do this.

          This is what I don't understand.

          --
          Joi Ellis Software Engineer
          Aravox Technologies joi@..., gyles19@...

          No matter what we think of Linux versus FreeBSD, etc., the one thing I
          really like about Linux is that it has Microsoft worried. Anything
          that kicks a monopoly in the pants has got to be good for something.
          - Chris Johnson
        • Paul Kulchenko
          Hi, Joi! ... They are not the same. you re trying to do this: use vars qw($foo); print &page(); $foo= bar ; sub page { return Foo: $foo ; } It s not
          Message 4 of 4 , Mar 2 10:30 AM
          • 0 Attachment
            Hi, Joi!

            > use vars qw($foo);
            > $foo="bar";
            > print &page();
            >
            > sub page {
            > return "Foo: $foo";
            > }
            >
            > This isn't happening with my calls to SOAP::Lite, even when I model
            > my definitions exactly as shown in some of the examples. Is there
            They are not the same. you're trying to do this:

            use vars qw($foo);
            print &page();

            $foo="bar";

            sub page {
            return "Foo: $foo";
            }

            It's not SOAP::Lite's problem; it's the way Perl works. Let's walk
            through your code:

            use SOAP::Lite +trace => 'all';
            use SOAP::Transport::HTTP;

            SOAP::Transport::HTTP::CGI
            -> dispatch_to('cvsBuildC')
            -> options({compress_threshold => 10000})
            -> handle;

            package cvsBuildC;

            use strict;
            use vars qw($foobar);
            $foobar = "Baz";

            sub build {
            my $self=shift;
            ....
            print STDERR "Foobar=";
            print STDERR $foobar;
            print STDERR $cvsBuildC::foobar;
            print STDERR $self->foobar;
            }

            ->handle method gets executed BEFORE '$foobar = "Baz";' line is seen
            (during run-time phase), so your global variable isn't initialized at
            this point. To do what you want you have several options:

            1. use BEGIN{}

            use SOAP::Transport::HTTP;

            SOAP::Transport::HTTP::CGI
            ......
            -> handle;

            BEGIN {
            package cvsBuildC;

            ....
            }

            2. change order

            package cvsBuildC;

            ....

            package main;

            use SOAP::Transport::HTTP;

            SOAP::Transport::HTTP::CGI
            ......
            -> handle;

            3. create separate module (cvsBuildC.pm) and move your package there:

            --- cvsBuildC.pm ---

            package cvsBuildC;

            ......

            --- cvsBuildC.cgi ---

            use SOAP::Transport::HTTP;

            SOAP::Transport::HTTP::CGI
            ......
            -> handle;

            You'll face exactly the same problem if instead of initializing
            global variables you'll try to do inheritance using @ISA = 'Foo';
            It was discussed on this list a couple of times. Hope it helps.

            Best wishes, Paul.

            --- Joi Ellis <joi@...> wrote:
            > On Sat, 2 Mar 2002, Duncan Cameron wrote:
            >
            > > Unless you are running under mod_perl, there's no persistence
            > when
            > > you run a CGI script. The web server runs your script as a
            > separate
            > > process for each SOAP message. So, any global variables which one
            > > instance uses are not available to other instances.
            > >
            > > This isn't a problem with SOAP::Lite, just the way that CGI
            > works.
            > > If you run your code as a http daemon, then you can have global
            > > variables, but note that the variables will disappear when the
            > > server process terminates. Maybe you want to consider writing
            > > them to a file after each request message, or maybe use DB::File
            > > to tie a hash to a file.
            > >
            > > Regards,
            > > Duncan Cameron
            >
            > Thanks for responding. I'm still confused, though. I've been
            > writing
            > CGI scripts without mod_perl for years, so I'm quite familar with
            > the
            > data persistence issues. However, If I call a cgi script that
            > has the format:
            >
            > use vars qw($foo);
            > $foo="bar";
            > print &page();
            >
            > sub page {
            > return "Foo: $foo";
            > }
            >
            > Then the result will print "Foo=bar".
            >
            > This isn't happening with my calls to SOAP::Lite, even when I model
            > my definitions exactly as shown in some of the examples. Is there
            > an unstated difference in that he's writing them for mod_perl and
            > I'm not?
            >
            > It as if SOAP::Lite isn't even running my global setup code. I'm
            > only calling the service once, so why are the globals getting lost?
            > Why aren't they getting written to my package namespace where they
            > can be accessed during THE SAME EXECUTION? How do I define
            > constants
            > without having to explicitly repeat them in every single service
            > method?
            > Do I need to make a setGlobals() routine to do it and call that
            > from
            > the service methods? None of his examples do this.
            >
            > This is what I don't understand.
            >
            > --
            > Joi Ellis Software Engineer
            > Aravox Technologies joi@..., gyles19@...
            >
            > No matter what we think of Linux versus FreeBSD, etc., the one
            > thing I
            > really like about Linux is that it has Microsoft worried. Anything
            > that kicks a monopoly in the pants has got to be good for
            > something.
            > - Chris Johnson
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            >
            > To unsubscribe from this group, send an email to:
            > soaplite-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to
            > http://docs.yahoo.com/info/terms/
            >
            >


            __________________________________________________
            Do You Yahoo!?
            Yahoo! Sports - sign up for Fantasy Baseball
            http://sports.yahoo.com
          Your message has been successfully submitted and would be delivered to recipients shortly.