>J S wrote:
>
>>I need to keep the mod_perl dynamic so that I can upgrade it later if need
>>be, and also I don't want to have to rebuild Apache as well. I did get the
>>libperl.so to build today by adding -DUSE_HSREGEX to EXTRA_CFLAGS in the
>>Makefile. Not sure if that was right but it at least got the compile to
>>work.
>
>Great
>
>>The problem now is I can't get apache to start:
>>
>>smpd9$ /opt/apache_1.3.27/bin/apachectl configtest
>>Syntax error on line 208 of /opt/apache_1.3.27/conf/httpd.conf:
>>Cannot load /opt/apache_1.3.27/libexec/libperl.so into server: ld.so.1:
>>/opt/apache_1.3.27/bin/httpd: fatal: relocation error: file
>>/opt/apache_1.3.27/libexec/libperl.so: symbol Perl_vmess: referenced
>>symbol not found
>
>[...]
>
>>I have a bit more debug for you but I'm not sure how meaningful this is:
>
>All, but one bit is missing from the puzzle
>
>># ldd ../libexec/libperl.so
>>        libperl.so =>
>>/opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so
>
>># nm -r ../libexec/libperl.so
>
>>[1356]  |         0|       0|FUNC |GLOB |0    |UNDEF
>>|libperl.so:Perl_vmess
>
>What's the output of
>
>nm /opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so |  grep
>Perl_vmess
>

smpd9$ nm /opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so |  grep
Perl_vmess
[368]   |    995152|     716|FUNC |GLOB |0    |8      |Perl_vmess


_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger

J S wrote:
>
>
>
>> J S wrote:
>>
>>> I need to keep the mod_perl dynamic so that I can upgrade it later if
>>> need be, and also I don't want to have to rebuild Apache as well. I
>>> did get the libperl.so to build today by adding -DUSE_HSREGEX to
>>> EXTRA_CFLAGS in the Makefile. Not sure if that was right but it at
>>> least got the compile to work.
>>
>>
>> Great
>>
>>> The problem now is I can't get apache to start:
>>>
>>> smpd9$ /opt/apache_1.3.27/bin/apachectl configtest
>>> Syntax error on line 208 of /opt/apache_1.3.27/conf/httpd.conf:
>>> Cannot load /opt/apache_1.3.27/libexec/libperl.so into server:
>>> ld.so.1: /opt/apache_1.3.27/bin/httpd: fatal: relocation error: file
>>> /opt/apache_1.3.27/libexec/libperl.so: symbol Perl_vmess: referenced
>>> symbol not found
>>
>>
>> [...]
>>
>>> I have a bit more debug for you but I'm not sure how meaningful this is:
>>
>>
>> All, but one bit is missing from the puzzle
>>
>>> # ldd ../libexec/libperl.so
>>>        libperl.so =>
>>> /opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so

are you sure that ../libexec/libperl.so is
/opt/apache_1.3.27/libexec/libperl.so? Since you show below that
/opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so has the symbol
Perl_vmess defined and it's the one ldd sees in
/opt/apache_1.3.27/libexec/libperl.so it should work just fine. Usually when
this problem happens when you get the wrong .so loaded.

>>> # nm -r ../libexec/libperl.so
>>
>>
>>> [1356]  |         0|       0|FUNC |GLOB |0    |UNDEF
>>> |libperl.so:Perl_vmess
>>
>>
>> What's the output of
>>
>> nm /opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so |  grep
>> Perl_vmess
>>
>
> smpd9$ nm /opt/perl-5.8.0/lib/5.8.0/sun4-solaris/CORE/libperl.so |  grep
> Perl_vmess
> [368]   |    995152|     716|FUNC |GLOB |0    |8      |Perl_vmess
>
>
> _________________________________________________________________
> Stay in touch with absent friends - get MSN Messenger
> http://www.msn.co.uk/messenger


--


__________________________________________________________________
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

> Niko Järvinen wrote:
>
> >>>When I´m installing modperl and I´m running make test all tests fail.
> >>>I have mod_perl-2.0 and Apache/2.0.45 (Unix).  I´m running redhat 9.0.
> >>>My Perl version is v5.8.0
> >>
> >
> >>Red Hat 9.0 comes with mod_perl and Apache 2 already installed for you.
> >>Why are you doing it again??
>
> RH9.0 comes with a very old mp2, so if you can install the new one, so
much
> better for you.

Could someone explain what mp2 is, as I´m pretty new with linux.
Unless if you mean mod_perl2.


> You had this really long ping-pong thread, I still have no clue what
version
> do you try to install. Make sure that you use mod_perl 1.99_09 that you
can
> download from here:
> http://perl.apache.org/download/index.html

I do use mod_perl 1.99_09. I tried CVS and tar.gz packet and neither worked.

Niko Järvinen

Niko Järvinen wrote:

>
> Could someone explain what mp2 is, as I´m pretty new with linux.
> Unless if you mean mod_perl2.

mp2 is mod_perl2.


> I do use mod_perl 1.99_09. I tried CVS and tar.gz packet and neither worked.

1.99_9 is mp2 :)

Carl

On Thursday 01 May 2003 1:11 am, Jeremy Cowgar wrote:
> I've been trying to use that, now I know why it was not working. I am
> shooting for XHTML 1.0 strict, therefore I did not include and name="..."
> in my INPUT fields. (http://www.w3.org/TR/xhtml1/#h-4.10).

Hmmm.  INPUT is not one of the elements listed as being changed in that
document.  FORM is, but not INPUT.

> I then placed id and name attributes in my INPUT fields (still valid for
> the current XHTML but are depriciated. Then things started to work as they
> should.
>
> Does anyone know if this is a problem with the browsers or with
> Apache::Request?

Well, what do you expect to happen if you don't name your inputs?  How would
you know which one was which?

Calling @params = $apr->param() will give you everything that was submitted,
but you still won't know which input is which.

- Perrin

On Thursday 01 May 2003 5:27 am, Niko Järvinen wrote:
> I do use mod_perl 1.99_09. I tried CVS and tar.gz packet and neither
> worked.

I built 1.99_09 last night on Red Hat 9 with Apache 2.0.45 without any
problems.  Please send the information described here as Stas requested:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems

Also, what is your $LANG environment variable set to?

- Perrin

On Thu, 1 May 2003 07:36:56 -0400, Perrin Harkins <perrin@...> wrote:

> Hmmm.  INPUT is not one of the elements listed as being changed in that
> document.  FORM is, but not INPUT.

Opps. I misread.

> Well, what do you expect to happen if you don't name your inputs?  How
> would you know which one was which?
>
> Calling @params = $apr->param() will give you everything that was
> submitted, but you still won't know which input is which.

With my misreading, I thought that the id replaced the name attribute.
That's what I expected, however that was due to misreading. Thank you for
pointing me straight.

Jeremy
http://cowgar.com

Guys,

I sometimes see advise in this list with the following codefragment:

>         my $apr = Apache::Request->new($r);

Now as I understand using 'new' can (and almost certainly will) leave you
without parsed request information if you do this too often. To avoid
this you need to either use your own scheme, use Apache::RequestNotes or
use the ->instance method.
My question is: shouldn't we stop using new and always advise to use
instance? If not, can somebody explain why one would choose new above
instance?

--Frank

On Thu, 01 May 2003 12:56:53 +1000, Stas Bekman wrote:

>> We're still getting SEGVs.  They've migrated somewhat with the patches
>> I've applied but they're now coming in:
>>
>>       ap_soft_timeout() on line 1762 which is:
>>
>>       ap_set_callback_and_alarm(timeout, r->server->timeout);
>>
>> When I examine *r I get back a structure with a whole pile of stuff,
>> all of which is 0.  It's like the call in XS_Apache_print line 1795
>> which is:
>>
>>       r = sv2request_rec(ST(0), "Apache", cv);
>>
>> is returing a block of memory with nothing (all zeros) in it.  I
>> cant look at r or ST but I can see that cv is a structure with 3
>> fields which don't seem to have a particular type.
>
>what do you get when you print *cv? why can't you see r?

It says "No symbol r in current context" or something like that, I don't
have the specifics in front of me.  I've no idea why it doesn't see
some of the symbols but does see others and why it's only within mod_perl
code that I can't seem to look at symbols.  It knows line numbers and
the like but not the local variables.

I don't remember exactly what it showed for *cv other than it was either
one of the structs that starts with sv_any or it was a long list of vars
that I couldn't make any sense of.

>Could it be some hardware problems? I do see occasional problems like this on
>my machine which seems to have a faulty AMD CPU :( I can't even reliably run
>'make'.
>
>Do you have this problem on a single machine or can you reproduce it elsewhere
>too?

If I move the site, the problem moves with it.

>Since you are using RH and mp-1.27 which is used by so many people the
>problems that you report are very unlikely to be a problem with mod_perl.

I disagree.  Even if it's something being done in the perl code we have
running on the server, there should be some sort of protection built
into mod_perl that keeps the daemon from crashing.   Given that applying
patches to mod_perl has resolved some of the crashing (probably only
relocating the problem each time I patch an occurance), that says it's
in that part of the system.  On top of that, it seems to occur in one
particular script at this point, although not at all consistantly.

>> I *NEED* to get this resolved.  I'm open to suggestions and/or someone
>> with more specific knowledge taking a poke at some online (IRC)
>> exploration of a crashed httpd.
>
>Try:
>
>/server irc.rhizomatic.net
>/join #modperl

I'm there now (9:22 AM EDT) and seem to be the life of the party.
Hopefully I'll see some signs of life and someone there will have
some insight into this.

    Michael

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

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.  When I remove the attribute it 'works'
(right now it prints double, but that's undoubtedly some other error).

Are these attributes actually necessary?  What do they do?  How do I get
them to work?

I thought I had seen a post regarding this but can't find it now.

I am using:

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

I downloaded all packages as binaries.

thx,
mma

> 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

"Frank Maas" <frank.maas@...> writes:

[...]

> My question is: shouldn't we stop using new and always advise
> to use instance?

For apreq-2 I'd rather see new() and instance() aliased together
into a single constructor.  Subrequests that use Apache::Request
would automatically share the POST data with the main request, but
not the query-string args.

> If not, can somebody explain why one would choose new above instance?

AFAICT there's no technical reason why "new" should be used over
"instance".  The very first discussion on apreq-dev was about this
issue:

   http://marc.theaimsgroup.com/?t=104840533400002&r=1&w=2

What I took away from the discussion at the time was that
Doug was reluctant to introduce any behavioral changes to
the existing Apache::Request codebase.

--
Joe Schaefer

>>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

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

> 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

This release fixes a number of bugs, adds a new $m->notes method, and
speeds up execution when configured via the Apache httpd.conf file.


1.20  May 1, 2003 (May Day)

[ ENHANCEMENTS ]

- Added an $m->notes() method, which is similar to $r->pnotes() but
may be used outside a mod_perl environment.  Task id #449.

- Mason will now only convert non-reference exceptions to
HTML::Mason::Exception objects, so it should cooperate better with
modules like Error.pm.  Task id #446.

- Added more documentation on Mason's error handling and exception
system.  Task id #446.

- If Mason was configured via the Apache httpd.conf file, it could in
many cases be quite a bit slower than configuration via a custom
handler subroutine.  Now configuration via the httpd.conf is much
faster, and is only about 5% slower than a custom handler subroutine.
Reported by Jeremy Blain.

- Mason's test harness now gives verbose output when the TEST_VERBOSE
environment variable is true.  This eliminates the need for setting
MASON_VERBOSE.

- ** It is now an error to have a subcomponent and method with the
same name in a single component.

[ BUG FIXES ]

- Mason would die if asked to compile a component that evaluates
to a false value.  Task id #444.  Reported by David Wheeler.

- Mason now gives a better error message if you try to call a
component's methods or subcomponents from its <%shared> block.  Task
id #448.  Reported by Randy Harmon.

- If in_package was set, Mason would die if output was generated after
a subrequest.  Task id #453.  Reported by David R. Baird.

- If Perl's print() was called after a subrequest, Mason would die
when run with any Perl before 5.8.0.  Task id #458.

- If a component called $m->cache_self, and then $m->decline, no
output would be generated.  Task id #454.  Patch by Vadim Ustiansky.




/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

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

> > 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

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

> 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

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

Hello,

I'm trying to upgrade an old mod_perl  module to  v2.0 on RedHat 8.0 (apache
2.0.40 mod_perl 1.99_05-3)

It fail on:
Can't locate object method "RequestRec" via package ... line 41.

=== Some of the code :
use Apache::Connection;
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::Const qw(OK DECLINED);
use Apache::Log;
...
sub handler : method {
   my $r = shift;
   return DECLINED unless $r->RequestRec->is_initial_req;  # <== line 41
...
===

I read in previous posts that RequestRec was not fully implemented.
Should I upgrade to the latest mod_perl 1.99_09 or csv ?

If I need/want to upgrade what to set as MP_AP_PREFIX ?
>perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
I'm using the binary installation of apache came with RedHat 8.0

thanks,
addady

Addady wrote:
> Hello,
>
> I'm trying to upgrade an old mod_perl  module to  v2.0 on RedHat 8.0 (apache
> 2.0.40 mod_perl 1.99_05-3)
>
> It fail on:
> Can't locate object method "RequestRec" via package ... line 41.
>
> === Some of the code :
> use Apache::Connection;
> use Apache::RequestRec;
> use Apache::RequestUtil;
> use Apache::Const qw(OK DECLINED);
> use Apache::Log;
> ...
> sub handler : method {
>   my $r = shift;
>   return DECLINED unless $r->RequestRec->is_initial_req;  # <== line 41

eh? where is this code from?

Should be:

return DECLINED unless unless $r->is_initial_req

> ===
>
> I read in previous posts that RequestRec was not fully implemented.
> Should I upgrade to the latest mod_perl 1.99_09 or csv ?

You should do that in any case. 1.99_05 is a way too old and so many things
have changed since that version was released.

> If I need/want to upgrade what to set as MP_AP_PREFIX ?
>
>>perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2

if that's where you apache is, that's correct.

> I'm using the binary installation of apache came with RedHat 8.0


--


__________________________________________________________________
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

> 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 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

> > 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

>> If I need/want to upgrade what to set as MP_AP_PREFIX ?
>>>perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
>
>if that's where you apache is, that's correct.

I'm using the binary installation of apache came with RedHat 8.0,
I don't know where should I point MP_AP_PREFIX ?

Addady





----- Original Message -----
From: "Stas Bekman" <stas@...>
To: "Addady" <addady@...>
Cc: <modperl@...>
Sent: Friday, May 02, 2003 9:16 AM
Subject: Re: Can't locate object method "RequestRec", upgrade ?


> Addady wrote:
> > Hello,
> >
> > I'm trying to upgrade an old mod_perl  module to  v2.0 on RedHat 8.0
(apache
> > 2.0.40 mod_perl 1.99_05-3)
> >
> > It fail on:
> > Can't locate object method "RequestRec" via package ... line 41.
> >
> > === Some of the code :
> > use Apache::Connection;
> > use Apache::RequestRec;
> > use Apache::RequestUtil;
> > use Apache::Const qw(OK DECLINED);
> > use Apache::Log;
> > ...
> > sub handler : method {
> >   my $r = shift;
> >   return DECLINED unless $r->RequestRec->is_initial_req;  # <== line 41
>
> eh? where is this code from?
>
> Should be:
>
> return DECLINED unless unless $r->is_initial_req
>
> > ===
> >
> > I read in previous posts that RequestRec was not fully implemented.
> > Should I upgrade to the latest mod_perl 1.99_09 or csv ?
>
> You should do that in any case. 1.99_05 is a way too old and so many
things
> have changed since that version was released.
>
> > If I need/want to upgrade what to set as MP_AP_PREFIX ?
> >
> >>perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
>
> if that's where you apache is, that's correct.
>
> > I'm using the binary installation of apache came with RedHat 8.0
>
>
> --
>
>
> __________________________________________________________________
> 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
>

Hi

I need to give a 30min presentation on the basic concepts and advantages of
mod_perl. I remember that there are existing presentations around.

If you have one I d'like to receive it, if it is in English, German or French.
Would help me be quicker (lazier) :-)

Thanks, Christian

> >> If I need/want to upgrade what to set as MP_AP_PREFIX ?
> >>>perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
> >
> >if that's where you apache is, that's correct.
>
> I'm using the binary installation of apache came with RedHat 8.0,
> I don't know where should I point MP_AP_PREFIX ?

Having not built mod_perl I'm not sure what MP_AP_PREFIX is supposed to be,
whether it's the location of the binary, library, or source directory.

If I recall properly, many Apache installations have an installation
directory that contains all of the above, a symbolic link from
/usr/bin/httpd (or something like that) to the binary in the installation
directory, and some configuration files somewhere under /etc.  You're
probably looking for the installation directory, but that's just a guess.

For the binary you might try (if I recall properly):

	 whereis httpd

For everything else, there's always the arcane:

	 find / -name 'apache*' -print

which will search your entire hard disk and (probably) find your
source/library/configuration directories.

YMMV and I'm working mostly on W2K these days so I might be wa-a-ay off
here.

mma