RE: MP2 - New Install - Make Test Errors - Resolved
Thanks for the fixes Stas, I appear to be up and running now.. Just a FYI for reference, I updated the source via CVS and tried it again. That time around I didn't get the TestConfig error but I got pretty much all the same errors that I got on the first (non-cvs) build where it couldn't find init::first, protocol, echo etc. If you want to see the info on that its here. Report http://tagteam.prevare.com/mp2pr1.txt Error Log http://tagteam.prevare.com/mp2pr1log.txt I tried adding them to the init.pm and got the same results. The last thing I did was kill the entire source directory, made sure I was just a standard user, downloaded the source via CVS again and then did the build, make and make test as that standard user and then SU'ed to root just for make install and everything went worked like a charm. Now I can see the only thing I ever want to see in my error log: Apache/2.0.44 (Unix) mod_perl/1.99_09-dev Perl/v5.8.0 configured Sweet! Thanks -Chris -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Saturday, March 22, 2003 11:54 PM To: Chris Faust Cc: Modperl Subject: Re: MP2 - New Install - Make Test Errors Chris Faust wrote: Thanks Stas, I tried getting it via CVS and all those other problems went away but I have a new one.. Can't locate Apache/TestConfig.pm This happens right at the end of the make and the module is within @INC. Thanks Chris, this is now fixed in cvs. Please run 'cvs up' and try again. I've missed the problem, since I had an installed Apache/Test. Once I've removed it, the problem was right there. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ANNOUNCE: Bricolage-Devel 1.5.1
The Bricolage team is pleased to announce the release of Bricolage-Devel 1.5.1, a beta release for what will soon become Bricolage 1.6.0. In addition to all of the new features of the 1.5.0 release, this version of the open-source content management system fixes many bugs and adds many new features and significant performance enhancements. The most significant changes include: * A new, complete internationalization and localization implementation. All messages, text buttons, JavaScript messages, and help files may be localized. Some Portuguese and Italian localization has already been done. Translators needed going forward! Thanks to Claudio Valente. * New Super Bulk Edit interface to allow story editors to edit multiple fields in a single textarea field using simple tags. Thanks to Macworld Magazine for sponsoring this development. * A further overhaul of groups and permissions. These changes make the permission checking and therefore the UI much more responsive. Thanks to Portugal Telecom for sponsoring this development. * The addition of a WebDAV distribution mover. Thanks to Joao Pedro Goncalves. * Extensive refactoring of most of the business classes, including stories, media, and templates, greatly enhancing the speed at which objects are retrieved from the database. Thanks Portugal Telecom and to Mark Jaroski. * Added a per-Apache request object cache. The prevents an object from being looked up in the database multiple times in a single request. Such was often the case during publishes, which are speeded up by this change by up to 33%. Thanks to Portugal Telecom for sponsoring this development. * Added a preview link to all subelement profiles within a story, thanks to Scott Lanning. * Switched exceptions from home-grown to using Exception::Class, thanks to Scott Lanning. * Added category group association -- including the ability to cascade membership assignments into subcategories -- to the category profile Thanks to Joao Pedro Goncalves. * The Content section of story, media, and subelement profiles now attempts to display a bit of text from the first text field in each listed subelement so that it's easier to see at a glance which subelement is which. Thanks to Joao Pedro Goncalves. * Subelement can now nest. That is, they can contain themselves. Not in a story, of course, but in the document model (element administration). * Over twenty bug fixes and a much more extensive test suite. For a complete list of the changes, see the changes file at https://sourceforge.net/project/shownotes.php?release_id=148352 Although this release gives every appearance of being as stable as any previous release of Bricolage, it does contain a fair bit of new code that needs to be put through the ringer. It is, however, feature complete for 1.6.0, which we expect to release in April. ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason and HTML::Template support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage has been hailed as Most Impressive in 2002 by eWeek. Learn more about Bricolage and download it from the Bricolage home page, http://bricolage.cc/. Enjoy! --The Bricolage Team
ANNOUNCE: Bricolage-Devel 1.5.1
The Bricolage team is pleased to announce the release of Bricolage-Devel 1.5.1, a beta release for what will soon become Bricolage 1.6.0. In addition to all of the new features of the 1.5.0 release, this version of the open-source content management system fixes many bugs and adds many new features and significant performance enhancements. The most significant changes include: * A new, complete internationalization and localization implementation. All messages, text buttons, JavaScript messages, and help files may be localized. Some Portuguese and Italian localization has already been done. Translators needed going forward! Thanks to Claudio Valente. * New Super Bulk Edit interface to allow story editors to edit multiple fields in a single textarea field using simple tags. Thanks to Macworld Magazine for sponsoring this development. * A further overhaul of groups and permissions. These changes make the permission checking and therefore the UI much more responsive. Thanks to Portugal Telecom for sponsoring this development. * The addition of a WebDAV distribution mover. Thanks to Joao Pedro Goncalves. * Extensive refactoring of most of the business classes, including stories, media, and templates, greatly enhancing the speed at which objects are retrieved from the database. Thanks Portugal Telecom and to Mark Jaroski. * Added a per-Apache request object cache. The prevents an object from being looked up in the database multiple times in a single request. Such was often the case during publishes, which are speeded up by this change by up to 33%. Thanks to Portugal Telecom for sponsoring this development. * Added a preview link to all subelement profiles within a story, thanks to Scott Lanning. * Switched exceptions from home-grown to using Exception::Class, thanks to Scott Lanning. * Added category group association -- including the ability to cascade membership assignments into subcategories -- to the category profile Thanks to Joao Pedro Goncalves. * The Content section of story, media, and subelement profiles now attempts to display a bit of text from the first text field in each listed subelement so that it's easier to see at a glance which subelement is which. Thanks to Joao Pedro Goncalves. * Subelement can now nest. That is, they can contain themselves. Not in a story, of course, but in the document model (element administration). * Over twenty bug fixes and a much more extensive test suite. For a complete list of the changes, see the changes file at https://sourceforge.net/project/shownotes.php?release_id=148352 Although this release gives every appearance of being as stable as any previous release of Bricolage, it does contain a fair bit of new code that needs to be put through the ringer. It is, however, feature complete for 1.6.0, which we expect to release in April. ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason and HTML::Template support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage has been hailed as Most Impressive in 2002 by eWeek. Learn more about Bricolage and download it from the Bricolage home page, http://bricolage.cc/. Enjoy! --The Bricolage Team -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: MP2 - New Install - Make Test Errors - Resolved
Chris Faust wrote: Thanks for the fixes Stas, I appear to be up and running now.. Just a FYI for reference, I updated the source via CVS and tried it again. That time around I didn't get the TestConfig error but I got pretty much all the same errors that I got on the first (non-cvs) build where it couldn't find init::first, protocol, echo etc. If you want to see the info on that its here. Report http://tagteam.prevare.com/mp2pr1.txt Error Log http://tagteam.prevare.com/mp2pr1log.txt I tried adding them to the init.pm and got the same results. Well, if the problem is not there anymore with the fresh tree, can we consider it solved? The last thing I did was kill the entire source directory, made sure I was just a standard user, downloaded the source via CVS again and then did the build, make and make test as that standard user and then SU'ed to root just for make install and everything went worked like a charm. Now I can see the only thing I ever want to see in my error log: Apache/2.0.44 (Unix) mod_perl/1.99_09-dev Perl/v5.8.0 configured Sweet! ;) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] CGI redirects incorrectly handled?
Stas Bekman wrote: Mark James wrote: STDOUT is flushed prior to a fork to exec an external binary (rcs). I understand the cause. But I hope that you agree with me that this is an application's problem. If you haven't sent anything to STDOUT yet, don't flush. And if this is not under your control, reopen STDOUT to /dev/null before you call that piece of code, that flushes and then re-tie STDOUT again. (See t/response/TestModperl/request_rec_tie_api.pm) I guess the best way to fix the problem in-application would be to either run nph, or do the /dev/null redirect you suggest. Interestingly, commenting out the pre-fork flush fixes the problem under mod_perl because close in mod_perl seems to be a no-op rather than a flush. If the close is also no problem under mod_cgi then is there any real need for such a pre-fork flush in my script? I see. But why is there no problem when using mod_cgi? That's an interesting question. mod_cgi is a generic handler, which can run applications written in any language. Therefore it has no clue of what flush is. It simply creates a pipe to the application, and expects the headers headers followed by the data. In your case, when cgi script flushes STDOUT, nothing happens at all, because there is no data to flush. So mod_cgi gets the headers and the data and all is cool When the same code is run under mod_perl, flush generates a special bucket which is sent out to the filters chain, and since no headers are generated yet, they get generated and sent out. Well, even under mod_cgi a program can still fflush or write. The difference between mod_cgi and mod_perl is that mod_cgi does not activate the filter brigade until it has read all the headers. Why would a perl handler script want to flush data down the filter chain before it had finished writing all of it? Here is an example: You have a long running process, you want the headers to be sent immediately, but the data won't follow for a while. So you create the headers, do $r-rflush, and later on send the data. OK. So would there be a problem if mod_perl waited for the blank line end of headers, or at least a Status header, before passing the buckets down the line, just like mod_cgi? mod_cgi uses spilling buckets, each of size 8K, to buffer script output, including during the header scan, while mod_perl seems to scan the headers when the first 8K buffer is either filled or flushed.
Apache::GD::Thumbnail Question
Does anyone use this handler to make on-the-fly thumbs? I've used the standard example code in my apache (1.3.27 with MP1) and it seems to ignore the handler. Any suggestions? -- Steven A. Adams [EMAIL PROTECTED]
Re: [mp2] CGI redirects incorrectly handled?
Mark James wrote: Stas Bekman wrote: Mark James wrote: STDOUT is flushed prior to a fork to exec an external binary (rcs). I understand the cause. But I hope that you agree with me that this is an application's problem. If you haven't sent anything to STDOUT yet, don't flush. And if this is not under your control, reopen STDOUT to /dev/null before you call that piece of code, that flushes and then re-tie STDOUT again. (See t/response/TestModperl/request_rec_tie_api.pm) I guess the best way to fix the problem in-application would be to either run nph, or do the /dev/null redirect you suggest. Interestingly, commenting out the pre-fork flush fixes the problem under mod_perl because close in mod_perl seems to be a no-op rather than a flush. If the close is also no problem under mod_cgi then is there any real need for such a pre-fork flush in my script? Since the mod_perl's internal STDOUT buffer isn't mangled if you re-tie it later, and it'll be always flushed at the end of the request, there is no *need* to flush on CLOSE. However in order to be consistent with perl fh close behavior, it probably needs to be changed to flush its buffer. What do you think? I see. But why is there no problem when using mod_cgi? That's an interesting question. mod_cgi is a generic handler, which can run applications written in any language. Therefore it has no clue of what flush is. It simply creates a pipe to the application, and expects the headers headers followed by the data. In your case, when cgi script flushes STDOUT, nothing happens at all, because there is no data to flush. So mod_cgi gets the headers and the data and all is cool When the same code is run under mod_perl, flush generates a special bucket which is sent out to the filters chain, and since no headers are generated yet, they get generated and sent out. Well, even under mod_cgi a program can still fflush or write. Ah, of course! The difference between mod_cgi and mod_perl is that mod_cgi does not activate the filter brigade until it has read all the headers. But in the case of mod_perl, this event is valid only for handlers which print their own headers, rather than using mod_perl API to set them. In the generic case, there is no way to tell whether a handler is going to set more headers or it has done with it. I suppose that we could prevent flushing in the case the handler is configured to parse headers. Does it make sense? Why would a perl handler script want to flush data down the filter chain before it had finished writing all of it? Here is an example: You have a long running process, you want the headers to be sent immediately, but the data won't follow for a while. So you create the headers, do $r-rflush, and later on send the data. OK. So would there be a problem if mod_perl waited for the blank line end of headers, or at least a Status header, before passing the buckets down the line, just like mod_cgi? See above. mod_cgi uses spilling buckets, each of size 8K, to buffer script output, including during the header scan, while mod_perl seems to scan the headers when the first 8K buffer is either filled or flushed. I don't think this is related to the issue in question. Since the problem is what to do on flush. Also we might have a problem if the headers to parse are bigger than the size of the buffer (8k). Do you think someone will ever need to send headers bigger than 8k? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
run_access_check
Hi All,
I am getting the following error mesg:
Can't locate object method run_access_checker via package Apache::RequestRec at
/usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx/.pm
for the section:
sub handler {
my Apache::Connection $c = shift;
my APR::Socket $socket = $c-client_socket;
my $r = Apache::RequestRec-new($c);
$r-location_merge(__PACKAGE__);
my $rc = $r-run_access_checker();
..
Any idea why?
I am using 2.0.44 with mp2 from cvs.
Sincerely,
Jie
Re: run_access_check
Jie Gao wrote:
Hi All,
I am getting the following error mesg:
Can't locate object method run_access_checker via package Apache::RequestRec at /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx/.pm
for the section:
sub handler {
my Apache::Connection $c = shift;
my APR::Socket $socket = $c-client_socket;
my $r = Apache::RequestRec-new($c);
$r-location_merge(__PACKAGE__);
my $rc = $r-run_access_checker();
..
Any idea why?
I am using 2.0.44 with mp2 from cvs.
Guessing that you haven't loaded Apache::HookRun.
% lookup run_access_checker
to use method 'run_access_checker' add:
use Apache::HookRun ();
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups
Linked to from:
http://perl.apache.org/docs/2.0/user/compat/compat.html#Code_Porting
and:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Figuring_Out_What_Modules_Need_to_be_Loaded
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] CGI redirects incorrectly handled?
Stas Bekman wrote: Since the mod_perl's internal STDOUT buffer isn't mangled if you re-tie it later, and it'll be always flushed at the end of the request, there is no *need* to flush on CLOSE. However in order to be consistent with perl fh close behavior, it probably needs to be changed to flush its buffer. What do you think? Dunno. But the problem I had would have been even harder to track down if commenting out the flush hadn't fixed it. The difference between mod_cgi and mod_perl is that mod_cgi does not activate the filter brigade until it has read all the headers. But in the case of mod_perl, this event is valid only for handlers which print their own headers, rather than using mod_perl API to set them. In the generic case, there is no way to tell whether a handler is going to set more headers or it has done with it. So can flushing be held off until either (1) blank line is printed, (2) the 8k buffer fills, or (3) send_http_header is called? I suppose that we could prevent flushing in the case the handler is configured to parse headers. Does it make sense? No. Could you explain your reasoning. mod_cgi uses spilling buckets, each of size 8K, to buffer script output, including during the header scan, while mod_perl seems to scan the headers when the first 8K buffer is either filled or flushed. I don't think this is related to the issue in question. Since the problem is what to do on flush. Also we might have a problem if the headers to parse are bigger than the size of the buffer (8k). Do you think someone will ever need to send headers bigger than 8k? Yes, I mentioned the buffer size in case your objection to my proposal to wait until end of headers was seen was based on the possiblity of more than 8k of headers. With the current mp2 code, if you decide to wait for the end of headers before doing cgi parsing and flushing then the code is assuming that either the headers are less than 8k or that any Status header is in the first 8k. Otherwise the code would have to be re-written to use continuous (spilling and merging) buffer buckets like mod_cgi. It can hold off on flushing indefinitely.
Re: [mp2] CGI redirects incorrectly handled?
The
difference between mod_cgi and mod_perl is that mod_cgi does not
activate the filter brigade until it has read all the headers.
But in the case of mod_perl, this event is valid only for handlers
which print their own headers, rather than using mod_perl API to set
them. In the generic case, there is no way to tell whether a handler
is going to set more headers or it has done with it.
So can flushing be held off until either (1) blank line is printed,
(2) the 8k buffer fills, or (3) send_http_header is called?
1) is relevant only for handler that print headers, rather than set them
2) absolutely not, what if you want to flush data before?
3) send_http_header doesn't exist in Apache2/mod_perl2
I suppose that we could prevent flushing in the case the handler is
configured to parse headers. Does it make sense?
No. Could you explain your reasoning.
Only in the case that your handler is configured with:
PerlOptions +ParseHeaders
*and*
it prints headers ala:
print Content-type:
In all other cases where headers are set via the API, e.g. $r-content_type,
$r-headers_out, etc, there is no such a thing as the handler has send an
empty line signaling the end of sending headers, because it never sends any
headers at all, but uses api to set them.
Are we on the same page now?
mod_cgi uses spilling buckets, each of size 8K, to buffer script output,
including during the header scan, while mod_perl seems to scan the
headers
when the first 8K buffer is either filled or flushed.
I don't think this is related to the issue in question. Since the
problem is what to do on flush.
Also we might have a problem if the headers to parse are bigger than
the size of the buffer (8k). Do you think someone will ever need to
send headers bigger than 8k?
Yes, I mentioned the buffer size in case your objection to my proposal
to wait until end of headers was seen was based on the possiblity of
more than 8k of headers.
Again, the concept of the end of headers exists only in certain cases.
With the current mp2 code, if you decide to
wait for the end of headers before doing cgi parsing and flushing then
the code is assuming that either the headers are less than 8k or that any
Status header is in the first 8k. Otherwise the code would have to
be re-written to use continuous (spilling and merging) buffer buckets
like mod_cgi. It can hold off on flushing indefinitely.
That approach will break this handler:
sub handler {
my $r = shift;
$r-content_type('text/plain');
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
However notice that it doesn't have to set content_type() because some earlier
handler could have done that and that should work as well:
sub handler {
my $r = shift;
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
So as you can see, this handler doesn't tell us when it's done with headers.
OK, you may say that that previous handler should have marked the end of
headers settings, but that would be wrong if the response handler wants to set
other headers as well.
Do we now agree that the event of end of sending headers is possible only in
the case explained at the top?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make errors with mod_perl-1.99_08 on aix 4.3.3 5.1
I've applied some fixes for mod_perl to build on aix. I could only test with aix 5.1 on powerpc. Please test that things work on other configurations. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
