Re: [Re: [Re: again - more then one PerlTransHandler]]
Doug MacEachern wrote:
> > At least that's what I thought !
> >
> > In fact now Apache lets me use more then one
> > PerlTransHandler, but it doesn't care
> > of what is the return codes are!!!
> >
> > Even I return OK, it still calls
> > next registered handlers. Really weird!
>
> mod_perl does care. but, mod_perl stacked handlers are not quite the same
> as Apache C handlers. unless the return status from a Perl handler is
> something other than OK or DECLINED, mod_perl propagates the status code
> of the last handler run back up to Apache.
> originally, stacked handlers were introduced for chaining multiple content
> handlers. if the OK status from the first handler was propagated back to
> Apache, there would be no chain, and little use for stacked handlers.
>
> you can always override this behavior by using a single Perl*Handler which
> decides what path to take based on the return status, or use a
> PerlDispatchHandler, or PerlDirectiveHandlers, to name a few.
I've got round this by having a module which adds a JournalsTrans directive,
which says which trans handlers to apply, then have just one PerlTransHandler,
which processes them all:
httpd.conf:
PerlTransHandlerJournals::Frontend::handle_trans
JournalsTrans /EJ Journals::EJ::handle_trans
JournalsTrans /EJ/Admin Journals::EJ::Admin::handle_trans
JournalsTrans /Journals Journals::Info::handle_trans
sub Journals::Frontend::handle_trans{
my($r)=@_;
# Fetch handlers configured by Journals::Config
if(my $cfg=Apache::ModuleConfig->get($r,'Journals::Config')){
if(my $trans=$cfg->{JournalsTrans}){
my $uri=$r->uri;
foreach(@$trans){
my($test_uri,$uri_sub,$sub)=@$_;
if($uri_sub->($uri)){
my $code=$sub->($r,$test_uri);
return $code
if $code!=DECLINED;
}
}
$r->log->error("No handler matching $uri found");
}else{
$r->log->crit('No JournalsTrans module config found');
}
}else{
$r->log->crit("Can't retrieve module config");
}
return DECLINED;
}
--
Peter Haworth [EMAIL PROTECTED]
If a packet hits a pocket on a socket on a port
& the bus is interrupted as a very last resort
& the memory address makes your processes abort
then the socket packet pocket has an error to report!
Re: [Re: [Re: again - more then one PerlTransHandler]]
I believe this should be reflected in the documentation. Because after reading Eagle book one gets absolutely different understanding. It doesn't diffirentiate Perl stacked handlers and Apache handlers. From Doug's words (and from practice :) those are slightly different in the way how their return codes are treated. BTW. Do I understand it correctly now that if my PERL handler returns either OK or DECLINED then the next PERL handler (if any) for this phase will be called anyway, but Apache "native" handlers will be called depending on what is the phase. Ie. for URL translation the "native" handler will be called only if last Perl handler returned DECLINED. Andrei On Tue, Dec 21, 1999 at 01:45:40PM -0800, Doug MacEachern wrote: > > At least that's what I thought ! > > > > In fact now Apache lets me use more then one > > PerlTransHandler, but it doesn't care > > of what is the return codes are!!! > > > > Even I return OK, it still calls > > next registered handlers. Really weird! > > mod_perl does care. but, mod_perl stacked handlers are not quite the same > as Apache C handlers. unless the return status from a Perl handler is > something other than OK or DECLINED, mod_perl propagates the status code > of the last handler run back up to Apache. > originally, stacked handlers were introduced for chaining multiple content > handlers. if the OK status from the first handler was propagated back to > Apache, there would be no chain, and little use for stacked handlers. > > you can always override this behavior by using a single Perl*Handler which > decides what path to take based on the return status, or use a > PerlDispatchHandler, or PerlDirectiveHandlers, to name a few. > > --
Re: [Re: [Re: again - more then one PerlTransHandler]]
> At least that's what I thought ! > > In fact now Apache lets me use more then one > PerlTransHandler, but it doesn't care > of what is the return codes are!!! > > Even I return OK, it still calls > next registered handlers. Really weird! mod_perl does care. but, mod_perl stacked handlers are not quite the same as Apache C handlers. unless the return status from a Perl handler is something other than OK or DECLINED, mod_perl propagates the status code of the last handler run back up to Apache. originally, stacked handlers were introduced for chaining multiple content handlers. if the OK status from the first handler was propagated back to Apache, there would be no chain, and little use for stacked handlers. you can always override this behavior by using a single Perl*Handler which decides what path to take based on the return status, or use a PerlDispatchHandler, or PerlDirectiveHandlers, to name a few.
Re: [Re: [Re: again - more then one PerlTransHandler]]
Thanks for the answers!
I was using RedHat rpm and it was giving the problem
as it was suggested. After I built mod_perl with apache
(mod_perl 1.21, apache 1.3.9, the problem was resolved.
At least that's what I thought !
In fact now Apache lets me use more then one
PerlTransHandler, but it doesn't care
of what is the return codes are!!!
Even I return OK, it still calls
next registered handlers. Really weird!
Thanks!
Evg
Eric Cholet <[EMAIL PROTECTED]> wrote:
On Thu, 16 Dec 1999, you wrote:
> Waa!!! So far nobody who answered even doubted that
> it should be possible to have more then one
> PerlTransHandler. The "Eagle" book also says
> that it should be possible. People suggested that
> either my mod_perl built with wrong flags or I messed
> up return codes OK/DECLINED (which I didn't!).
>
> Is what you saying documented somewhere?!!!
Here's a simple test I just ran (with the CVS version of mod_perl, but 1.21
should work as well, although I haven't tested it):
Foo.pm:
package Foo;
sub handler
{
$r = shift;
$r->warn("Foo translating " . $r->uri);
return DECLINED;
}
1;
Bar.pm:
package Bar;
sub handler
{
$r = shift;
$r->warn("Bar translating " . $r->uri);
return DECLINED;
}
1;
in httpd.conf:
PerlTransHandler +Foo
PerlTransHandler +Bar
after accessing the server, in error.log:
[Fri Dec 17 00:44:22 1999] [warn] Foo translating /
[Fri Dec 17 00:44:22 1999] [warn] Bar translating /
So yes it's possible to have several TransHandlers.
--
Eric Cholet
Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: [Re: again - more then one PerlTransHandler]
On Thu, 16 Dec 1999, you wrote:
> Waa!!! So far nobody who answered even doubted that
> it should be possible to have more then one
> PerlTransHandler. The "Eagle" book also says
> that it should be possible. People suggested that
> either my mod_perl built with wrong flags or I messed
> up return codes OK/DECLINED (which I didn't!).
>
> Is what you saying documented somewhere?!!!
Here's a simple test I just ran (with the CVS version of mod_perl, but 1.21
should work as well, although I haven't tested it):
Foo.pm:
package Foo;
sub handler
{
$r = shift;
$r->warn("Foo translating " . $r->uri);
return DECLINED;
}
1;
Bar.pm:
package Bar;
sub handler
{
$r = shift;
$r->warn("Bar translating " . $r->uri);
return DECLINED;
}
1;
in httpd.conf:
PerlTransHandler +Foo
PerlTransHandler +Bar
after accessing the server, in error.log:
[Fri Dec 17 00:44:22 1999] [warn] Foo translating /
[Fri Dec 17 00:44:22 1999] [warn] Bar translating /
So yes it's possible to have several TransHandlers.
--
Eric Cholet
Re: [Re: again - more then one PerlTransHandler]
Waa!!! So far nobody who answered even doubted that it should be possible to have more then one PerlTransHandler. The "Eagle" book also says that it should be possible. People suggested that either my mod_perl built with wrong flags or I messed up return codes OK/DECLINED (which I didn't!). Is what you saying documented somewhere?!!! Thanks, Evg darren chamberlain <[EMAIL PROTECTED]> wrote: You're not missing anything. You can only have one translation handler. In the case of the two TransHandlers, the second definition masks the first. Can't you just rewrite the SimpleTranslation::handler to be ModeratelyComplexTranslation::handler, and do the Right Thing in that one handler? I.e., if every request is being passed through 2 handlers, why not consolidate them into one handler? darren Evgenii Bazarov ([EMAIL PROTECTED]) wrote: > Hi everybody, > > Sorry for the poor wording of my question. Once again: > > I am trying to install and use more then one translation > handler. I tried two approaches to specifying handlers > in the Apache config file (both recommended in the > "Eagle" book.) First, have both handlers on the same line, > e.g. in httpd.conf > > PerlTransHandler SimpleTranslation::handler FancyTranslation::handler > > In this case Apache spits out error: > > Syntax error on line 29 of /etc/httpd/conf/perl.conf > PerlTransHandler takes one argument, the Perl Translation handler routine > name. > > and exits. > > Secondly I tried to put two lines in config: > > PerlTransHandler SimpleTranslation::handler > PerlTransHandler FancyTranslation::handler > > In this case, only second handler gets invoked. > Am I missing something?!!! > > Evg -- If God had not given us sticky tape, it would have been necessary to invent it. Get free email and a permanent address at http://www.netaddress.com/?N=1
