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

Re: Handler attributes

Expand Messages
  • Geoffrey Young
    ... I saw this recently - the cause IIRC was that I didn t preload the module with PerlModule first, so try that if you haven t already. other than that, the
    Message 1 of 13 , May 1, 2003
      Marc M. Adkins wrote:
      > I have yet to be able to append an attribute to a handler function, e.g.:
      >
      > # ...
      >
      > use base qw(Apache::Filter);
      >
      > # ...
      >
      > sub handler : FilterRequestHandler # $filter
      >
      > # ...
      >
      > When I do this I get no information in the Apache error log. The page hangs
      > for a moment and then goes away.

      I saw this recently - the cause IIRC was that I didn't preload the module
      with PerlModule first, so try that if you haven't already.

      other than that, the examples in t/filter/TestFilter should be enough to get
      you going - if you can run them on your mod_perl installation successfully
      then the problem is probably just something simple. I haven't tried it on
      Win32 before, but you could also try runningthe test suite and then altering
      the code from

      http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz

      which is the example from the perl.com article

      http://www.perl.com/pub/a/2003/04/17/filters.html

      good luck and HTH

      --Geoff
    • Marc M. Adkins
      ... I ve been using: SetHandler modperl PerlOutputFilterHandler +Site::Filter The + is supposed to implicitly call
      Message 2 of 13 , May 1, 2003
        > I saw this recently - the cause IIRC was that I didn't preload the module
        > with PerlModule first, so try that if you haven't already.

        I've been using:

        <Location /filter>
        SetHandler modperl
        PerlOutputFilterHandler +Site::Filter
        </Location>

        The '+' is supposed to implicitly call PerlModule (and apparently does).

        When I attempt to use the PerlModule directive separately (outside of the
        <Location> tag) I get an error related to the @INC value not including my
        code directory, which is in fact set up in startup.pl. So far the directive
        above is the only configuration that I've managed to get working.

        > which is the example from the perl.com article
        >
        > http://www.perl.com/pub/a/2003/04/17/filters.html

        Ah, yes, there's that thing where the filter is invoked multiple times...I
        had read about that but forgotten. Doubtless that is why I'm getting double
        output. D'oh!

        Note that your example from the article does not actually use the
        FilterRequestHandler attribute (I'm still wondering just exactly what it is
        supposed to do...I suppose I'll have to traipse through the code sometime).
        Meanwhile, I had apparently gotten the right configuration (using the '+' as
        discussed above) and not re-checked my code with the attribute because _now
        it works_ for me.

        Double d'oh!

        thx,
        marc

        P.S.

        Now I've fixed my code to do single output. A side note, in case anyone
        cares...the method Filter::seen_eos() will _never_ be true unless the code
        calls Filter::read() enough times to go through all of the input. An
        obvious thing, once it happens. Perhaps worth a note in the doc, perhaps
        not. I only found out because I was ignoring the input in my simplistic
        test code, an unrealistic situation for an output handler. -- mma
      • Stas Bekman
        ... I ll check why this doesn t work without preloading. ... + is fine. but when do you load startup.pl? This should work: PerlRequire /path/to/startup.pl
        Message 3 of 13 , May 1, 2003
          Marc M. Adkins wrote:
          >>I saw this recently - the cause IIRC was that I didn't preload the module
          >>with PerlModule first, so try that if you haven't already.

          I'll check why this doesn't work without preloading.

          > I've been using:
          >
          > <Location /filter>
          > SetHandler modperl
          > PerlOutputFilterHandler +Site::Filter
          > </Location>
          >
          > The '+' is supposed to implicitly call PerlModule (and apparently does).
          >
          > When I attempt to use the PerlModule directive separately (outside of the
          > <Location> tag) I get an error related to the @INC value not including my
          > code directory, which is in fact set up in startup.pl. So far the directive
          > above is the only configuration that I've managed to get working.

          + is fine.

          but when do you load startup.pl? This should work:

          PerlRequire /path/to/startup.pl (where @INC is adjusted)
          PerlModule Site::Filter
          <Location /filter>
          SetHandler modperl
          PerlOutputFilterHandler Site::Filter
          </Location>

          Actually you don't need 'SetHandler modperl' if you don't run a response phase
          in mod_perl.

          >>which is the example from the perl.com article
          >>
          >>http://www.perl.com/pub/a/2003/04/17/filters.html
          >
          >
          > Ah, yes, there's that thing where the filter is invoked multiple times...I
          > had read about that but forgotten. Doubtless that is why I'm getting double
          > output. D'oh!

          Use $filter->ctx to ensure that something happens once (this is documented).
          Or $filter->remove. I'll update the filter docs soonish.

          > Note that your example from the article does not actually use the
          > FilterRequestHandler attribute (I'm still wondering just exactly what it is
          > supposed to do...I suppose I'll have to traipse through the code sometime).
          > Meanwhile, I had apparently gotten the right configuration (using the '+' as
          > discussed above) and not re-checked my code with the attribute because _now
          > it works_ for me.

          FilterRequestHandler marks the handler as a request filter handler (which is
          the default, so you don't have to use that attribute). However if you want to
          use a connection filter you have to use the FilterConnectionHandler attribute.

          Why do you need to mark these? Because the configuration directive doesn't say
          anything about the type of the filter:

          PerlOutputFilterHandler Site::Filter

          So if we don't know if it's a connection filter or a request one, we don't
          know when to invoke it. Perhaps reading the whole filters document and working
          through all examples will make it more clear.

          > Now I've fixed my code to do single output. A side note, in case anyone
          > cares...the method Filter::seen_eos() will _never_ be true unless the code
          > calls Filter::read() enough times to go through all of the input. An
          > obvious thing, once it happens. Perhaps worth a note in the doc, perhaps
          > not. I only found out because I was ignoring the input in my simplistic
          > test code, an unrealistic situation for an output handler. -- mma

          That's correct. $f->seen_eos() is a special function for streaming filters and
          you have to read all the input in a loop to get it set. This will be
          documented in the Apache::Filter manpage.


          __________________________________________________________________
          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
          mailto:stas@... http://use.perl.org http://apacheweek.com
          http://modperlbook.org http://apache.org http://ticketmaster.com
        • Geoffrey Young
          ... tricky, isn t it :) ... no, it doesn t. that the filter is an output filter is assumed. I have gotten the filter to work with it, though (which is
          Message 4 of 13 , May 1, 2003
            >>which is the example from the perl.com article
            >>
            >>http://www.perl.com/pub/a/2003/04/17/filters.html
            >
            >
            > Ah, yes, there's that thing where the filter is invoked multiple times...I
            > had read about that but forgotten. Doubtless that is why I'm getting double
            > output. D'oh!

            tricky, isn't it :)

            >
            > Note that your example from the article does not actually use the
            > FilterRequestHandler attribute

            no, it doesn't. that the filter is an output filter is assumed. I
            have gotten the filter to work with it, though (which is required when
            using the FilterInitHandler, which was going to be the subject of
            another article :)

            > (I'm still wondering just exactly what it is
            > supposed to do...I suppose I'll have to traipse through the code sometime).

            stas can explain that better than I can. I think it has to do
            something with source filters being used to add your handler to the
            proper filter chain - the attributes are used as part of the source
            filter mechanism.

            > Meanwhile, I had apparently gotten the right configuration (using the '+' as
            > discussed above) and not re-checked my code with the attribute because _now
            > it works_ for me.

            cool :)

            --Geoff
          • Stas Bekman
            ... Doh! Must be the order of executing PerlRequire and PerlModule entries. Was this configuration inside a VirtualHost container? If not it s PerlRequire
            Message 5 of 13 , May 1, 2003
              Marc M. Adkins wrote:
              >>PerlRequire /path/to/startup.pl (where @INC is adjusted)
              >>PerlModule Site::Filter
              >><Location /filter>
              >> SetHandler modperl
              >> PerlOutputFilterHandler Site::Filter
              >></Location>
              >
              >
              > That's what I was doing. I kept getting error messages at Apache startup
              > saying that it couldn't find the module. It showed me the @INC and it
              > wasn't what startup.pl was supposed to be setting.
              >
              > Just tried it again:
              >
              > [Thu May 01 18:15:17 2003] [error]
              > Can't locate Site/Wrapper.pm in @INC
              > (@INC contains: C:/Perl/lib C:/Perl/site/lib . C:/Apache2/
              > C:/Apache2/lib/perl) at (eval 1) line 3.
              >
              > But using the '+' notation works jus' fine. Weird.

              Doh! Must be the order of executing PerlRequire and PerlModule entries. Was
              this configuration inside a VirtualHost container?

              If not it's PerlRequire that is executed first, followed by PerlModule entries.

              The vhost is need was the other way around, I'll commit the fix that changes
              the order now.

              > What's weird now is that I'm not sure that the output filter is getting
              > invoked properly on 'default' pages. That is to say, just using an output
              > filter to wrap formatting around a plain 'ole HTML page as opposed to
              > wrapping the output of a PerlResponseHandler.
              >
              > To be more specific...if I configure:
              >
              > AddHandler modperl html
              > PerlResponseHandler Site::Dummy
              >
              > PerlOutputFilterHandler +Site::Wrapper
              >
              > where Site::Dummy simply reads the target HTML file from disk and sends it
              > out via the request object, everything works fine. But if I just use:
              >
              > PerlOutputFilterHandler +Site::Wrapper
              >
              > by itself the pages don't 'complete.' The tail end of each page is for some
              > reason lost. It's like I'm hitting the EOS marker before processing all of
              > the data from the source page, but I know that I'm not.
              >
              > The core code from my output filter is in fact:
              >
              > # We only process HTML documents:
              > return Apache::DECLINED
              > unless $filter->r->content_type =~ m|text/html|i;

              what you really want to do here is:

              unless ($filter->r->content_type =~ m|text/html|i){
              $filter->remove;
              return Apache::DECLINED;
              }

              I know this new feature is not documented yet. Will be soon.

              $filter->remove completely removes the filter from the chain, so it's not
              going to be invoked at all. Much faster.

              Alternatively (a tiny bit more efficient) consider to insert the filter in
              TransHandler only if you need it:

              package MyTransHandler;
              ...
              sub handler {
              my $r = shift;
              $r->add_input_filter("myfilter")
              if $filter->r->content_type =~ m|text/html|i
              ...
              }

              > while ($filter->read(my $buffer, 1024)) {
              > # process $buffer appropriately
              > }

              of course, you have to print the data out. unless you have stripped that code
              in this example. If you did, what happens if your filter simply prints out
              data unmodified? Does it get all the data?

              > # Don't do anything until the page is finished:
              > return Apache::OK
              > unless $filter->seen_eos;
              >
              > # At this point the page is finished and I send all data
              > # out via the $filter object

              Ah, you want to do that. Use $filter->ctx for that. I suppose that that's what
              you do:

              my $data = $filter->ctx;
              $data = '' unless defined $data;
              while ($filter->read(my $buffer, 1024)) {
              $data .= $buffer;
              }
              $filter->ctx($data);

              if ($filter->seen_eos) {
              print $filter->ctx;
              }

              > I've been wondering if there was some Apache::Filter::flush() call I was
              > missing, but it _works_ when I use the Site::Dummy PerlResponseHandler. It
              > only misses the end when I just let the page be fed in _without_ the
              > response handler.

              Yes, mod_perl's response handler flushes data. But so does the filter handler.

              Look at line 670 in src/modules/perl/modperl_filter.c. It skips the flush only
              if it had already sent EOS before.

              Could you change one of the filter tests to reproduce this problem?

              __________________________________________________________________
              Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
              http://stason.org/ mod_perl Guide ---> http://perl.apache.org
              mailto:stas@... http://use.perl.org http://apacheweek.com
              http://modperlbook.org http://apache.org http://ticketmaster.com
            • Marc M. Adkins
              ... That s what I was doing. I kept getting error messages at Apache startup saying that it couldn t find the module. It showed me the @INC and it wasn t
              Message 6 of 13 , May 1, 2003
                > PerlRequire /path/to/startup.pl (where @INC is adjusted)
                > PerlModule Site::Filter
                > <Location /filter>
                > SetHandler modperl
                > PerlOutputFilterHandler Site::Filter
                > </Location>

                That's what I was doing. I kept getting error messages at Apache startup
                saying that it couldn't find the module. It showed me the @INC and it
                wasn't what startup.pl was supposed to be setting.

                Just tried it again:

                [Thu May 01 18:15:17 2003] [error]
                Can't locate Site/Wrapper.pm in @INC
                (@INC contains: C:/Perl/lib C:/Perl/site/lib . C:/Apache2/
                C:/Apache2/lib/perl) at (eval 1) line 3.

                But using the '+' notation works jus' fine. Weird.

                > Actually you don't need 'SetHandler modperl' if you don't run a
                > response phase in mod_perl.

                Yeah, I've been discovering that.

                -------------------------------------------------------

                What's weird now is that I'm not sure that the output filter is getting
                invoked properly on 'default' pages. That is to say, just using an output
                filter to wrap formatting around a plain 'ole HTML page as opposed to
                wrapping the output of a PerlResponseHandler.

                To be more specific...if I configure:

                AddHandler modperl html
                PerlResponseHandler Site::Dummy

                PerlOutputFilterHandler +Site::Wrapper

                where Site::Dummy simply reads the target HTML file from disk and sends it
                out via the request object, everything works fine. But if I just use:

                PerlOutputFilterHandler +Site::Wrapper

                by itself the pages don't 'complete.' The tail end of each page is for some
                reason lost. It's like I'm hitting the EOS marker before processing all of
                the data from the source page, but I know that I'm not.

                The core code from my output filter is in fact:

                # We only process HTML documents:
                return Apache::DECLINED
                unless $filter->r->content_type =~ m|text/html|i;

                while ($filter->read(my $buffer, 1024)) {
                # process $buffer appropriately
                }

                # Don't do anything until the page is finished:
                return Apache::OK
                unless $filter->seen_eos;

                # At this point the page is finished and I send all data
                # out via the $filter object

                I've been wondering if there was some Apache::Filter::flush() call I was
                missing, but it _works_ when I use the Site::Dummy PerlResponseHandler. It
                only misses the end when I just let the page be fed in _without_ the
                response handler.

                mma
              • Stas Bekman
                ... Can you please test the current modperl-2.0 cvs or alternatively apply this patch and let me know if this works now without the workaround?
                Message 7 of 13 , May 1, 2003
                  Marc M. Adkins wrote:
                  >>>But using the '+' notation works jus' fine. Weird.
                  >>
                  >>Doh! Must be the order of executing PerlRequire and PerlModule
                  >>entries. Was
                  >>this configuration inside a VirtualHost container?
                  >
                  >
                  > Like this:
                  >
                  > <VirtualHost *:80>
                  > PerlOutputFilterHandler +Site::Wrapper
                  > </VirtualHost>
                  >
                  >>The vhost is need was the other way around, I'll commit the fix
                  >>that changes the order now.
                  >
                  >
                  > Cool. Though I have a work-around, so I'm happy anyway.

                  Can you please test the current modperl-2.0 cvs or alternatively apply this
                  patch and let me know if this works now without the workaround?
                  http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2

                  >>$filter->remove completely removes the filter from the chain, so it's not
                  >>going to be invoked at all. Much faster.
                  >
                  >
                  > I'm assuming that this is on a per connect basis. That the handler is not
                  > removed permanently from the chain, but only for the rest of the calls on a
                  > given page.

                  That's correct.

                  >>> while ($filter->read(my $buffer, 1024)) {
                  >>> # process $buffer appropriately
                  >>> }
                  >>
                  >>of course, you have to print the data out. unless you have
                  >>stripped that code
                  >>in this example. If you did, what happens if your filter simply
                  >>prints out
                  >>data unmodified? Does it get all the data?
                  >
                  >
                  > Yeah, I have app-specific code collecting the incoming data and then I spew
                  > it at the end after seeing EOS. I've tinkered some and can't reproduce
                  > without
                  > my code so I'm guessing it's my problem. If I can reproduce w/o my code
                  > I'll certainly pass along the example.

                  I don't think we have a filter test that has no mod_perl handler that produces
                  the response. If you can write one, that would be great! If you need help, ask.

                  __________________________________________________________________
                  Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                  http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                  mailto:stas@... http://use.perl.org http://apacheweek.com
                  http://modperlbook.org http://apache.org http://ticketmaster.com
                • Marc M. Adkins
                  ... Like this: PerlOutputFilterHandler +Site::Wrapper ... Cool. Though I have a work-around, so I m happy anyway. ... I m
                  Message 8 of 13 , May 1, 2003
                    > > But using the '+' notation works jus' fine. Weird.
                    >
                    > Doh! Must be the order of executing PerlRequire and PerlModule
                    > entries. Was
                    > this configuration inside a VirtualHost container?

                    Like this:

                    <VirtualHost *:80>
                    PerlOutputFilterHandler +Site::Wrapper
                    </VirtualHost>

                    > The vhost is need was the other way around, I'll commit the fix
                    > that changes the order now.

                    Cool. Though I have a work-around, so I'm happy anyway.

                    > $filter->remove completely removes the filter from the chain, so it's not
                    > going to be invoked at all. Much faster.

                    I'm assuming that this is on a per connect basis. That the handler is not
                    removed permanently from the chain, but only for the rest of the calls on a
                    given page.

                    > > while ($filter->read(my $buffer, 1024)) {
                    > > # process $buffer appropriately
                    > > }
                    >
                    > of course, you have to print the data out. unless you have
                    > stripped that code
                    > in this example. If you did, what happens if your filter simply
                    > prints out
                    > data unmodified? Does it get all the data?

                    Yeah, I have app-specific code collecting the incoming data and then I spew
                    it at the end after seeing EOS. I've tinkered some and can't reproduce
                    without
                    my code so I'm guessing it's my problem. If I can reproduce w/o my code
                    I'll certainly pass along the example.

                    mma
                  • Stas Bekman
                    ... Don t worry, I m pretty sure that my patch fixes the problem. It was obviously different from the execution order on non-vhost server. As for M$ building
                    Message 9 of 13 , May 1, 2003
                      Marc M. Adkins wrote:
                      >>Can you please test the current modperl-2.0 cvs or alternatively
                      >>apply this
                      >>patch and let me know if this works now without the workaround?
                      >>http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2
                      >
                      >
                      > Unfortunately I'm not building Apache or mod_perl right at the moment. I
                      > get sooooo frustrated building open-source / cross-platform packages on
                      > Windows I'm in kind of avoidance mode right now. You could probably talk
                      > (or guilt) me into it but probably not before next week. All that
                      > downloading and fussing and breaking of furniture to consider.
                      >
                      > Seems ungrateful I know...but I really have had a lot of serious pain
                      > building stuff on Windows and my fuse has gotten short. I went to build APR
                      > or Apache just a few weeks ago and ran into some 'usual problem' (like I
                      > would have to give M$ money for new versions of software or download 133Mb
                      > of software over a 56K line or something like that) and just blew it off and
                      > downloaded binaries. Sigh.
                      >
                      > So right now I'm running:
                      >
                      > Apache 2.0.45
                      > mod_perl 1.99_09-dev
                      > ActiveState Perl build 804 (5.8.0)
                      > Windows 2000
                      >
                      > all from binaries _including_ mod_perl which I got from wherever
                      > perl.apache.org said to get it.
                      >
                      > Yell at me some offline and I'll probably acquire the proverbial round tuit.

                      Don't worry, I'm pretty sure that my patch fixes the problem. It was obviously
                      different from the execution order on non-vhost server.

                      As for M$ building probs, consider getting an unix flavor OS, I have heard
                      people reporting good results with using vmware if you can't afford dropping M$.

                      [...]

                      > So when I demonstrated the problem to myself I went back to the doc and lo
                      > and behold, there it was:
                      >
                      > HTTP request output filters should probably also unset the C-L header,
                      > if they change the size of the data that goes through it. (e.g. lc()
                      > filter shouldn't do it).
                      >
                      > $filter->r->headers_out->unset('Content-Length');
                      >
                      > A good candidate for boldface in the final documentation revision, but all
                      > my own problem even so.

                      ;)

                      > Note that my dummy PerlResponseHandler made it work OK where using the file
                      > straight from Apache did not. Well, whaddyaknow, my dummy
                      > PerlResponseHandler never set the content length. Apache probably does.
                      > Mystery solved (I think).

                      Yes, that must be it. Cool!

                      While you work through the filter docs, if you have any suggestions please
                      mentions those. doc patches to improve language, clarity, etc. are very welcome.

                      __________________________________________________________________
                      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                      mailto:stas@... http://use.perl.org http://apacheweek.com
                      http://modperlbook.org http://apache.org http://ticketmaster.com
                    • Marc M. Adkins
                      ... Unfortunately I m not building Apache or mod_perl right at the moment. I get sooooo frustrated building open-source / cross-platform packages on Windows
                      Message 10 of 13 , May 1, 2003
                        > Can you please test the current modperl-2.0 cvs or alternatively
                        > apply this
                        > patch and let me know if this works now without the workaround?
                        > http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2

                        Unfortunately I'm not building Apache or mod_perl right at the moment. I
                        get sooooo frustrated building open-source / cross-platform packages on
                        Windows I'm in kind of avoidance mode right now. You could probably talk
                        (or guilt) me into it but probably not before next week. All that
                        downloading and fussing and breaking of furniture to consider.

                        Seems ungrateful I know...but I really have had a lot of serious pain
                        building stuff on Windows and my fuse has gotten short. I went to build APR
                        or Apache just a few weeks ago and ran into some 'usual problem' (like I
                        would have to give M$ money for new versions of software or download 133Mb
                        of software over a 56K line or something like that) and just blew it off and
                        downloaded binaries. Sigh.

                        So right now I'm running:

                        Apache 2.0.45
                        mod_perl 1.99_09-dev
                        ActiveState Perl build 804 (5.8.0)
                        Windows 2000

                        all from binaries _including_ mod_perl which I got from wherever
                        perl.apache.org said to get it.

                        Yell at me some offline and I'll probably acquire the proverbial round tuit.

                        > > Yeah, I have app-specific code collecting the incoming data and
                        > then I spew
                        > > it at the end after seeing EOS. I've tinkered some and can't reproduce
                        > > without
                        > > my code so I'm guessing it's my problem. If I can reproduce w/o my code
                        > > I'll certainly pass along the example.
                        >
                        > I don't think we have a filter test that has no mod_perl handler
                        > that produces
                        > the response. If you can write one, that would be great! If you
                        > need help, ask.

                        After much fussing I finally determined that I got the problem when I
                        changed the content length during the filtration. Yes, I have in fact read
                        the documentation, but of course the importance of the 'details' doesn't
                        always become apparent until after spending an hour or so wondering WTFO.

                        And of course my test scripts prior to the last posting did exactly what you
                        suggested: they just passed input to output. Which doesn't alter the
                        length, wouldn't ya know it. Not that I wouldna thunk up the same test
                        myself, the obvious next step, just took another little bit to go on to a
                        simple handler that made the output length longer in passing like my real
                        handler does.

                        So when I demonstrated the problem to myself I went back to the doc and lo
                        and behold, there it was:

                        HTTP request output filters should probably also unset the C-L header,
                        if they change the size of the data that goes through it. (e.g. lc()
                        filter shouldn't do it).

                        $filter->r->headers_out->unset('Content-Length');

                        A good candidate for boldface in the final documentation revision, but all
                        my own problem even so.

                        Note that my dummy PerlResponseHandler made it work OK where using the file
                        straight from Apache did not. Well, whaddyaknow, my dummy
                        PerlResponseHandler never set the content length. Apache probably does.
                        Mystery solved (I think).

                        mma
                      • Stas Bekman
                        ... Does it build from the source or downloads a binary? ... Well, the problem with mp2 manpages is very simple: we wanted to get an automatic conversion of
                        Message 11 of 13 , May 2, 2003
                          Marc M. Adkins wrote:
                          >>Don't worry, I'm pretty sure that my patch fixes the problem. It
                          >>was obviously
                          >>different from the execution order on non-vhost server.
                          >
                          >
                          > I just updated mod_perl using mpinstall.pl (as described on
                          > perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
                          > loading order problem (I was running 199_9-dev earlier today). I'll try to
                          > remember to check back on this periodically and confirm the fix.

                          Does it build from the source or downloads a binary?

                          >>While you work through the filter docs, if you have any
                          >>suggestions please
                          >>mentions those. doc patches to improve language, clarity, etc.
                          >>are very welcome.
                          >
                          >
                          > I'd been thinking of doing some of the boilerplate fill-in that is needed.
                          > Like there is a fairly useful set of tutorial-type doc on handlers but the
                          > methods for Apache::RequestRec and Apache::Filter and other classes are
                          > still blank. Is this stuff in the source tree (which I don't have right
                          > now)? If so I could maybe fill in the few of the easy ones (that I may
                          > actually understand) and send in patches.

                          Well, the problem with mp2 manpages is very simple: we wanted to get an
                          automatic conversion of the docs from the C header files. However for some
                          reason folks who have worked on this sub-project are busy with other things.
                          The plan was to import the existing docs automatically and then polish the.
                          I'm CC'ing Gerald. May be he has some updates on this issue.



                          __________________________________________________________________
                          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                          mailto:stas@... http://use.perl.org http://apacheweek.com
                          http://modperlbook.org http://apache.org http://ticketmaster.com
                        • Marc M. Adkins
                          ... I just updated mod_perl using mpinstall.pl (as described on perl.apache.org). Now I ve got mod_perl/1.99_10-dev, which has the same loading order problem
                          Message 12 of 13 , May 2, 2003
                            > Don't worry, I'm pretty sure that my patch fixes the problem. It
                            > was obviously
                            > different from the execution order on non-vhost server.

                            I just updated mod_perl using mpinstall.pl (as described on
                            perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
                            loading order problem (I was running 199_9-dev earlier today). I'll try to
                            remember to check back on this periodically and confirm the fix.

                            > As for M$ building probs, consider getting an unix flavor OS, I
                            > have heard
                            > people reporting good results with using vmware if you can't
                            > afford dropping M$.

                            Actually, I have Mandrake Linux running on a separate partition, but all my
                            email and useful utilities are on Windows so I don't boot over all that
                            often. I used to have a separate Linux machine but when the wife spilled
                            coffee in the laptop I had to give up my Linux box for her use. Heavy sigh.

                            > While you work through the filter docs, if you have any
                            > suggestions please
                            > mentions those. doc patches to improve language, clarity, etc.
                            > are very welcome.

                            I'd been thinking of doing some of the boilerplate fill-in that is needed.
                            Like there is a fairly useful set of tutorial-type doc on handlers but the
                            methods for Apache::RequestRec and Apache::Filter and other classes are
                            still blank. Is this stuff in the source tree (which I don't have right
                            now)? If so I could maybe fill in the few of the easy ones (that I may
                            actually understand) and send in patches.

                            mma
                          • Marc M. Adkins
                            ... BFM. It _looks_ like it uses PPM for some of it and installs a pre-built .so module. I found it under binary installs on perl.apache.org. So far it
                            Message 13 of 13 , May 2, 2003
                              > > I just updated mod_perl using mpinstall.pl (as described on
                              > > perl.apache.org). Now I've got mod_perl/1.99_10-dev, which has the same
                              > > loading order problem (I was running 199_9-dev earlier today).
                              > I'll try to
                              > > remember to check back on this periodically and confirm the fix.
                              >
                              > Does it build from the source or downloads a binary?

                              BFM. It _looks_ like it uses PPM for some of it and installs a pre-built
                              .so module. I found it under binary installs on perl.apache.org. So far it
                              appears to work pretty well. I tried to do it manually at one point and
                              remember being somewhat frustrated.

                              I don't know how often the binary is rebuilt, how up-to-date it is, etc.
                              Like I said, BFM. I'm just happy it works, it saves me much time and
                              frustration.

                              mma
                            Your message has been successfully submitted and would be delivered to recipients shortly.