Re: Help wanted with locations / configuration
Steve Hay wrote: Thomas Klausner wrote: Hi! On Mon, Sep 08, 2003 at 04:51:55PM +0100, Steve Hay wrote: The project is going to be written as a series of mod_perl handlers - one for the main home page, and others for various sub-components. Each handler is implemented by a separate module (all sub-classes of a common base class). I don't want to have to configure a separate Location for each sub-component. You might want to take a look at Apache::Dispatch, which does exactly this. Will do! I've grabbed it off CPAN and will take a good look at it. It does indeed look like exactly what I'm after. Does anybody have Apache::Dispatch working on Windows? I'm trying to build it on Windows XP (MSVC++ 6) with Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.28, but I get these errors: [...] link -out:blib\arch\auto\Apache\Dispatch\Dispatch.dll -dll -nologo -node faultlib -release -libpath:C:\perl5\lib\CORE -machine:x86 Dispatch.obj C:\ perl5\lib\CORE\perl58.lib libeay32.lib oldnames.lib kernel32.lib user32.lib gdi 32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib -def:Dispatch.def Creating library blib\arch\auto\Apache\Dispatch\Dispatch.lib and object blib\ arch\auto\Apache\Dispatch\Dispatch.exp Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_merge_dir_co nfig Dispatch.obj : error LNK2001: unresolved external symbol _perl_cmd_perl_TAKE1 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_register_clea [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_cmd_cleanup Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_null_cleanup Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_clear_symtab Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_remove_module @4 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_find_linked_m [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_get_startup_pool Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Apache\Dispatch\Dispatch.dll : fatal error LNK1120: 11 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Any ideas? - Steve
Re: Help wanted with locations / configuration
Marc Slagle wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] You might want to look at having a translation handler. As in a PerlTransHandler, yes? We're doing something similar to this, where images and javascripts live under the same directory structure as the handler is managing. Instead of trying to configure this via that httpd.conf file, we chose to have a translation handler look at the incoming uri and determine whether the request is for a static file or for the code. Is there a performance penalty with this? You're using Perl code to inspect the URI, and then handing control back to the Apache core if it is a static file. I wanted to avoid requests for static files wasting time by going to a Perl handler only to be returned to the Apache core to serve the file, hence my LocationMatch override that catches requests for static files. Thanks for the code snippet, though - it looks pretty good to me aside from that concern. - Steve
Re: Help wanted with locations / configuration
Perrin Harkins wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, They have, indeed. Thanks, everyone! but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: [snip] Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. - Steve
Re: Help wanted with locations / configuration
petersm wrote: Steve Hay [EMAIL PROTECTED] wrote Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch Correct me if I'm wrong, but can't you just say Location /myproject Location /myproject AddHandler perl-script .cgi PerlHandler MyProject-dispatcher /Location using AddHandler instead of SetHandler. This will not override the default handler for things like images/stylesheets/static html. This way you don't need the LocationMatch ^/myproject/(images|javascript|stylesheets) ... tags. I prefer for reasons that I can't really explain to have the Perl handler locations having no extension - e.g. things like /myproject/component1 rather than /myproject/component1.cgi. I can't see how to achieve that with an AddHandler. (And even if I did get that working somehow, then the Perl handler would have to hand control back to the Apache core when it receives a request for /myproject/images.) Thanks for the idea, though. If I manage to overcome my inexplicable aversion to file extensions then it certainly looks like the simplest solution. - Steve
Re: Help wanted with locations / configuration
On Tuesday 09 September 2003 11:16, Steve Hay wrote: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. I have achieved that using the configuration Perrin suggested. The prefix (/myproject) is a parameter of the configuration of the application called apache_location_root, and the config script fills a mod_perl.conf.tt2 like this: Alias [% apache_location_root %]/views [% prj_root %]/www/htdocs/views Alias [% apache_location_root %]/images [% prj_root %]/www/htdocs/images Alias [% apache_location_root %]/scripts [% prj_root %]/www/htdocs/scripts Alias [% apache_location_root %]/styles [% prj_root %]/www/htdocs/styles Location [% apache_location_root %] # Nothing to do with the filesystem, just handlers available in @INC. /Location In our case the motivation for that is that we don't know whether our application will run in its own Apache server, so you can hard-code that stuff, or will need to be added to an already functioning Apache. -- fxn
Re: Help wanted with locations / configuration
Hi!
On Tue, Sep 09, 2003 at 10:05:43AM +0100, Steve Hay wrote:
Location /myproject/css
SetHandler default
/Location
Location /myproject/img
SetHandler default
/Location
This is working as expected, i.e. request for /css/foo.css or /img/bar.png
are not handled by Apache::Dispatch
What about requests for /css or /img ? Are they handled by
Apache::Dispatch? The problem I found with my LocationMatch override is
that requests for files were caught, but requests for directories
slipped through to the Perl handler.
Unfourtunatly, request for /css are handled by Apache::Dispatch. At least it
seems so, but I'm enterly sure if it's the actual request that's beeing
served, or an internal redirect (or some other funky Apache internal thing,
like ErrorDocument or index generation)
It does seem like a feature/problem of Apache. I tried various config
options (and modifications to Apache::Dispatch), but no matter what I did,
request for /img/ allways get passed to PerHandler instead of default
handler
Request for anything inside /img/ work as expected.
No, wait a minute...
If I request /foo/bar/ (another dir) than it doesn't work either.
I still do not know if this a bug in
Apache / mod_perl / Apache::Dispatch / YourHandler, and/or internal redirect.
Or if this is expected behaviour.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Help wanted with locations / configuration
Steve Hay [EMAIL PROTECTED] wrote Thanks for the idea, though. If I manage to overcome my inexplicable aversion to file extensions then it certainly looks like the simplest solution. I understand the argument that it's better for the user to not know the extension of the file they are running but, if it really bothers you then you could do something like Location /myproject AddHandler perl-script .steve /Location and then put a '.steve' extension onto your scripts and that way it's a little more personalized... :) Michael Peters Venzia
Re: Help wanted with locations / configuration
On Tue, 2003-09-09 at 05:00, Steve Hay wrote: As in a PerlTransHandler, yes? Yup. Is there a performance penalty with this? You're using Perl code to inspect the URI, and then handing control back to the Apache core if it is a static file. I wanted to avoid requests for static files wasting time by going to a Perl handler only to be returned to the Apache core to serve the file, hence my LocationMatch override that catches requests for static files. Static File: Devel::Timer Report -- Total time: 0.0006 secs Interval TimePercent -- 00 - 01 0.0003 48.49% INIT - Entering translation handler 01 - 02 0.0002 36.91% Entering translation handler - Checking to see if we are asking for a static file 02 - 03 0.0001 14.60% Checking to see if we are asking for a static file - This is a request for a static file, telling apache where it is Request we want to pass on to our handler: Devel::Timer Report -- Total time: 0.0005 secs Interval TimePercent -- 01 - 02 0.0002 40.90% Entering translation handler - Checking to see if we are asking for a static file 00 - 01 0.0001 31.48% INIT - Entering translation handler 02 - 03 0.0001 27.62% Checking to see if we are asking for a static file - This is not a request for a static file, returning DENIED We decided to do it this way because we are also doing some other things in the translation handler that I didn't pass along in the snippet. Since we were already putting a translation handler in place to do our trickery there, it seemed to make the most sense to us to add the code to handle static requests there. By no means am I suggesting that this is the best way, but we're pretty happy with it. Marc Slagle
Re: Help: Can't coerce GLOB to string...
[Forwarded from [EMAIL PROTECTED] [EMAIL PROTECTED]]
Hello,
In response to :
Kurt George Gjerde wrote:
BTW: I've fixed my can't coerce GLOB to string problem I had last
week.
Was unrelated to mod_perl (sorry). It seems XML::LibXSLT produced some
errors which went straight to STDERR. Under CGI these ends up in the
error_log but under mod_perl it seems STDERR is just a black hole (?).
Would it be possible to map STDERR to log_error()?
Unless I'm missing something, mod_perl doesn't do anything special with
STDERR
(it does tie STDIN and STDOUT for 'perl-script' handlers). Apache opens
stderr
to error_log, and then everything just works. e.g. if you do:
warn Foo;
or
print STDERR OOOPS\n;
this ends up in error_log, no?
I suppose that XML::LibXSLT redefines STDERR then. Try to see what it
does to
create this problem.
The key to this problem is that the function $parser-parse_string()
cannot take a scalar as argument.
This way it works and doesn't produce Can't coerce ... anymore :
my $sheet = $parser-parse_string('EOT');
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:output method=text indent=no/
xsl:strip-space elements=FILTER_RULE NAT_RULE LOG_RULE/
!-- this XSLT sheet transforms a netfilter XML rule document into an
iptables script --
xsl:template match=NETFILTER
...
EOT
Best regards
Jean Philippe GUILLEMIN
http://shweps.free.fr
[EMAIL PROTECTED]
Help wanted with locations / configuration
Hi, I'm having trouble deciding what the best plan is for the arrangement of the components of a new project that I'm starting. The project is going to be written as a series of mod_perl handlers - one for the main home page, and others for various sub-components. Each handler is implemented by a separate module (all sub-classes of a common base class). I don't want to have to configure a separate Location for each sub-component. It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? So far I've come up with two options: OPTION 1. Specify a /myproject Location with dispatcher method as the mod_perl handler; then specify a LocationMatch for the images, javascript and stylesheets that overrides the /myproject Location: Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch The dispatcher method there looks at the URI requested and either returns DECLINED (or 404?) if it doesn't recognise it, or else loads the appropriate MyProject sub-class and then runs the real content generation routine in that (i.e. a routine like I would have specified as the handler for that URI if I had configured a separate Location for each component). This seems to have a minor problem in practice -- if I request a directory, rather than a file, in one of the static locations (e.g. /myproject/images or /myproject/images/) then the dispatcher method gets called! The LocationMatch override only seems to work if I request a file (e.g. /myproject/images/piccy1.jpg). Thus, I need to put some extra code into the dispatcher to repeat the pattern match for the static locations, and change the handler to the default-handler and return DECLINED if it has received such a URI. OPTION 2. Specify a /myproject Location with a PerlFixupHandler that behaves very much like the dispatcher above, except that it actually sets the handler to PerlHandler and assigns the appropriate callback method (i.e. the content generation routine in the component sub-class) when it spots a recognised component URI; otherwise it just returns DECLINED, leaving the request to be handled by the default-handler: Location /myproject PerlFixupHandler MyProject-fixup /Location (Am I correct in thinking that I don't need to specify SetHandler: perl-script for a PerlFixupHandler? That's only for the main PerlHandler response handler, isn't it?) Does either of these options have any benefit over the other? Are there other better ways to do it? Thanks in advance, - Steve
Re: Help wanted with locations / configuration
On Mon, 2003-09-08 at 11:51, Steve Hay wrote:
It also needs to have access to various static resources (images,
stylesheets, JavaScript libraries etc.).
Thus, I want to have something like this:
/myproject [mp1]
/myproject/component1 [mp1]
/myproject/component2 [mp1]
...
/myproject/images [static]
/myproject/javascript [static]
/myproject/stylesheets [static]
You might want to look at having a translation handler.
We're doing something similar to this, where images and javascripts live
under the same directory structure as the handler is managing. Instead
of trying to configure this via that httpd.conf file, we chose to have a
translation handler look at the incoming uri and determine whether the
request is for a static file or for the code.
Inside of our transhandler we're doing this:
sub handler
{
my $r=shift;
my $uri=$r-uri;
my $Tmplpath=/our/static/files/rootdir/;
if (($uri !~ /jpg$/) ($uri !~ /css$/) ($uri !~ /js$/))
{
$r-notes('host' = $Host);
$r-notes('olduri' = $uri);
$r-uri(/);
return DECLINED;
}
else
{
my $File=$Tmplpath . $uri;
$r-filename($File);
return OK;
}
}
If a request is made for anything ending in .jpg, .js or .css, we tell
apache where to find the file by appending the uri (/images/the.jpg for
example) to a path. The handler then returns OK, which tells apache not
to try to figure out where the file lives on its own, and returns the
file to the browser.
Any other request is passed to the handler, along with a field in
notes() that shows what we were asking for in the first place. Our
request handler uses this to dispatch the request to the correct object
needed to fulfill the request. (Our handler is configured at /, so we
override the uri passed from the browser to /).
Any other types you want can be added to this, I just threw the ones
that seemed relevant to you. I hope this helps.
Marc Slagle
Whapps LLC
Re: Help wanted with locations / configuration
Hi!
On Mon, Sep 08, 2003 at 04:51:55PM +0100, Steve Hay wrote:
The project is going to be written as a series of mod_perl handlers -
one for the main home page, and others for various sub-components.
Each handler is implemented by a separate module (all sub-classes of a
common base class). I don't want to have to configure a separate
Location for each sub-component.
You might want to take a look at Apache::Dispatch, which does exactly this.
Location /myproject
SetHandler perl-script
PerlHandler MyProject-dispatcher
/Location
LocationMatch ^/myproject/(images|javascript|stylesheets)
SetHandler default-handler
/LocationMatch
I'm using something like this with Apache::Dispatch
PerlModule Apache::Dispatch
DispatchUpperCase On # this is /not/ in Apache::Dispatch,
# only in my patched version
DispatchPrefix Oe1
DispatchExtras Error
Location /myproject
SetHandler perl-script
PerlHandler Apache::Dispatch
/Location
Location /myproject/css
SetHandler default
/Location
Location /myproject/img
SetHandler default
/Location
This is working as expected, i.e. request for /css/foo.css or /img/bar.png
are not handled by Apache::Dispatch
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Help wanted with locations / configuration
Steve Hay [EMAIL PROTECTED] wrote It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch Correct me if I'm wrong, but can't you just say Location /myproject Location /myproject AddHandler perl-script .cgi PerlHandler MyProject-dispatcher /Location using AddHandler instead of SetHandler. This will not override the default handler for things like images/stylesheets/static html. This way you don't need the LocationMatch ^/myproject/(images|javascript|stylesheets) ... tags. Michael Peters Venzia
Re: Help wanted with locations / configuration
On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: Alias /static/images /myproject/images Then you can simply refer to them in URLs as /static/images/foo.jpg. Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Location /wild/and/crazy/path/for/handlers SetHandler perl-script PerlHandler MyProject-dispatcher /Location Then you can call /wild/and/crazy/path/for/handlers/component1 and it will work as long as your dispatcher is smart enough to ignore the beginning path. (Apache::Dispatch is.) - Perrin
request for help with reproducing problem
Recently I have found myself spending most of the time trying to reproduce reported bugs (and non-bugs), instead of resolving the already known bugs. Often times it takes a long time and multiple emails to get all the required information from the user reporting the problem to be able to reproduce the problem or to prove it to be a problem in the user code, and many times I can't reproduce problems on linux and my guess-work is not always successful. It'd be very helpful if folks gave us help to reproduce problems, so we can concentrate on fixing them. You don't have to understand mod_perl internals or to know C to reproduce problems. Just read the report, see if you can reproduce it, ask the person about the missing details (mostly listed here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems) and see if you can help the reporter to get a better bug report. The preferred way to help developers reproduce problems is to write a new test (or modify an existing test) for the mod_perl test suite, which when you run fails. or at least write a simple very short script/handler that can be converted into a test. But you really want to learn how to write tests with Apache::Test if you do any serious mod_perl development, so there is no excuse not to learn Apache::Test, not talking about the fact that there are hundreds of existing tests as examples, the tutorial http://perl.apache.org/docs/general/testing/testing.html and the slowly growing manpages. If you have any questions don't hesitate to ask here or on the test-dev list. Also please notice that some bug reports are posted to the dev list http://perl.apache.org/maillist/dev.html so monitoring both lists is a good idea. Thanks for your help. __ 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: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
$r-content_type is generally set by mod_mime, during the mime-type phase,
according to it's rules. for most setups, it should be set to something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
Re: help on setting up a PerlFixupHandler
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase you need
to do two things - tell apache that mod_perl is in charge, and tell mod_perl
which Perl handler it should use. you've done the latter. for the former,
use $r-handler('perl-script'), which is analogous to SetHandler perl-script
that you would ordinarily see for a mod_perl setup.
HTH
--Geoff
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? -chris
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 19:53, Christopher Grau wrote: Are you sure the content-type is text/html? Since you have your own Location handler, Apache is probably using the value from the DefaultType directive which, I think, defaults to text/plain when Apache is installed. That's it, $r-content_type ne 'text/html'; succeeds because $r-content_type is undef, so we return DECLINED and the default content handler is run AFAICT. DefaultType is text/plain in httpd.conf, why that method returns undef? To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? -- fxn
Re: request for help with reproducing problem
But you really want to learn how to write tests with Apache::Test if you do any serious mod_perl development, so there is no excuse not to learn Apache::Test, not talking about the fact that there are hundreds of existing tests as examples, the tutorial http://perl.apache.org/docs/general/testing/testing.html and the slowly growing manpages. not to mention http://www.perl.com/pub/a/2003/05/22/testing.html from which I quote: Secretly, I'm hoping that Apache-Test becomes so popular that end-users start wrapping their bug reports up in little, self-contained, Apache-Test-based tarballs so anyone can reproduce the problem. --Geoff
help on setting up a PerlFixupHandler
I am trying to write a Hello World!-like set up involving a
PerlFixupHandler but cannot get it to work. What I want to
accomplish is:
1. Configure Dispatcher.pm as a PerlFixupHandler for
http://localhost/admin.
2. Let Dispatcher.pm set ContentHandler.pm as the content
handler for that request.
3. Have ContentHandler.pm called in the corresponding phase.
but in the Apache log I see:
File does not exist: /home/fxn/prj/bw/buscawap/www/htdocs/admin
so looks like Apache is running the default handler looking under the
document root, which is /home/fxn/prj/bw/buscawap/www/htdocs.
This is mod_perl.conf:
# Just change @INC
PerlRequire /home/fxn/prj/bw/buscawap/etc/startup.pl
PerlModule Dispatcher
Location /admin
PerlFixupHandler Dispatcher
/Location
Dispatcher.pm:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
ContentHandler.pm:
package ContentHandler;
use Apache::Constants qw(OK);
sub handler {
my $r = shift;
$r-send_http_header('text/html');
$r-print('htmlheadtitleFoo/title/headbodyFoo/body/html');
return OK;
}
1;
What am I missing?
-- fxn
Re: help on setting up a PerlFixupHandler
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the
content type to text/html based on the file extension. mod_mime_magic will
do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type to examine
(or consistently relate, as .cgi can produce multiple CTs), no default type,
and no file to examine, then there is no way the mime modules can set a
content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing specific
like $r-content_type is set during the mime-type phase because things
like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the each phase of
the request cycle in depth. you can read part of it from
http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about every part
of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's open :) - at
the end of each extension module is the place where hooks are typically
registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
RE: help on setting up a PerlFixupHandler
Well, thank you very much for the references.
I guess I'll have to skip next few pints and finally get that book I've
heard so much about ;-)
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 3:15 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: help on setting up a PerlFixupHandler
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to
the browser,
so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the
content type to text/html based on the file extension.
mod_mime_magic will
do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type
to examine
(or consistently relate, as .cgi can produce multiple CTs), no
default type,
and no file to examine, then there is no way the mime modules can set a
content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a
documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing
specific
like $r-content_type is set during the mime-type phase because things
like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the
each phase of
the request cycle in depth. you can read part of it from
http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like
mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they
read/or set.
Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about
every part
of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's
open :) - at
the end of each extension module is the place where hooks are typically
registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 07:41:20PM +0200, Xavier Noria wrote:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-handler('perl-script');
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
without luck however, keeps on looking under the document root
for /admin. Should that change be enough?
Are you sure the content-type is text/html? Since you have your own
Location handler, Apache is probably using the value from the
DefaultType directive which, I think, defaults to text/plain when Apache
is installed.
-chris
RE: help on setting up a PerlFixupHandler
Hi Geoffrey Xavier,
I don't argue on the fact the Content-type is an entity header available in
both situations. However I'm talking about how to get/set in mod_perl the
Content-type in those 2 situations, which according to the mod_perl 1.0 API
docs and as I understand it, are different animals:
1.7.8 $r-content_type( [$newval] )
Get or set the content type being sent to the client. Content types are
strings like text/plain,
text/html or image/gif. This corresponds to the Content-Type header in
the HTTP
protocol. Example of usage is:
$previous_type = $r-content_type;
$r-content_type(text/plain);
...
1.5.16 $r-header_in( $header_name, [$value] )
Return the value of a client header. Can be used like this:
$ct = $r-header_in(Content-type);
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
Regards,
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 5:36 AM
To: Xavier Noria
Cc: [EMAIL PROTECTED]
Subject: Re: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server
sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an
outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in
that handler.
$r-content_type is generally set by mod_mime, during the
mime-type phase,
according to it's rules. for most setups, it should be set to
something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 18:29, Geoffrey Young wrote:
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase
you need to do two things - tell apache that mod_perl is in charge,
and tell mod_perl which Perl handler it should use. you've done the
latter. for the former, use $r-handler('perl-script'), which is
analogous to SetHandler perl-script that you would ordinarily see for
a mod_perl setup.
Thank you!
I tried to add that line to the Dispatcher:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-handler('perl-script');
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
without luck however, keeps on looking under the document root
for /admin. Should that change be enough?
-- fxn
Re: help on setting up a PerlFixupHandler
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
-- fxn
RE: help on setting up a PerlFixupHandler
Hi, It seems to me that $r-content-type is for what your server sends to the client, which is probably undef in the Fixup stage, where you test it. You probaly meant to test for the $ct = $r-header_in(Content-type) if you wanted to see whats requested from the client. Anyway, as Christopher pointed out you can get the what's before load off your shoulders ;-) HTH, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Xavier Noria [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 9:40 PM To: [EMAIL PROTECTED] Subject: Re: help on setting up a PerlFixupHandler On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote:
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after Makefile
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
problems with things finding libareq.so, sort out later leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should fix the symptoms by restoring the hack for a quick fix.
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE
'dynamic' to the Win32-specific section. That seems to get me back to
square one - the Makefile contains:
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
and the build fails as it originally did with:
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
Only the fix previously posted by Stas (adding 'SKIP' = [qw(dynamic
dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so
far, but Joe had a problem that...
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 22:53, Tofu Optimist wrote: Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, and plowed ahead. (Maybe I should have stopped here at the first FYI, this was probably also because of the locale issue. Best to make it a global change so you won't have to set it every time you want to run (or install) perl stuff. - Perrin
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote:
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
Somehow, it has contrived to disappear! It always used to exist there,
which is why it didn't occur to me to check :-( I must have lost it
somewhere along the line when shoe-horning earlier MakeMaker's into place.
Having now restored that file, the patch above does indeed fix it for me.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: Somehow, it has contrived to disappear! It always used to exist there, which is why it didn't occur to me to check :-( I must have lost it somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? Having now restored that file, the patch above does indeed fix it for me. Yay! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I need a SHOWER a BURGER and some ROBOTS, STAT! -- http://www.angryflower.com/allrigh.gif
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote: On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: Somehow, it has contrived to disappear! It always used to exist there, which is why it didn't occur to me to check :-( I must have lost it somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? Yes, I think I did delete it when installing MM 6.06_01 because its own Makefile was broken so I couldn't run nmake install. I see that Perl's lib/ExtUtils directory contains a typemap and ExtUtils-MakeMaker's lib/ExtUtils directory doesn't. So that would explain it. Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern [EMAIL PROTECTED] writes: On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. Not really. There are some changes for PerlIO * vs FILE * but other than that I am unaware of anything significant in years. (But then so long as it works I don't look)... Okay here are changes that have touched typemap in the mainline: Change 17989 on 2002/10/10 by [EMAIL PROTECTED] 'Subject: PATCH: lib/ExtUtils/ty' Change 15534 on 2002/03/26 by [EMAIL PROTECTED] 'Subject: Re: [PATCH] STRLEN typ' Change 11621 on 2001/08/09 by [EMAIL PROTECTED] 'Subject: [PATCH] remove PL_na f' Change 9737 on 2001/04/18 by [EMAIL PROTECTED] 'Subject: [PATCH] XS::Typemap - ' Change 9553 on 2001/04/05 by [EMAIL PROTECTED] 'Integrate changes #9544,9547,95' Change 9437 on 2001/03/29 by [EMAIL PROTECTED] 'Subject: [PATCH [EMAIL PROTECTED] type' Change 9380 on 2001/03/27 by [EMAIL PROTECTED] 'Subject: [PATCH] Typemap testin' Change 8934 on 2001/02/25 by [EMAIL PROTECTED] 'Integrate perlio: [ 8927] Cha' Change 8359 on 2001/01/08 by [EMAIL PROTECTED] 'Integrate perlio: [ 8356] FIL' Change 8308 on 2001/01/04 by [EMAIL PROTECTED] 'Subject: [patch] typemap =~ s/c' Change 6918 on 2000/08/30 by [EMAIL PROTECTED] 'NVs not necessarily doubles, as' Change 6915 on 2000/08/30 by [EMAIL PROTECTED] 'Subject: [PATCH] fix misc cast ' Change 6122 on 2000/05/28 by [EMAIL PROTECTED] 'downgrade fatal error on Cfoo' Change 4255 on 1999/09/30 by [EMAIL PROTECTED] 'remove prehistoric XFree() gunk' Change 4142 on 1999/09/13 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 4106 on 1999/09/08 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 3622 on 1999/07/06 by [EMAIL PROTECTED] 'applied patch after demunging h' Change 3524 on 1999/06/09 by [EMAIL PROTECTED] 'more complete support for impli' Change 2326 on 1998/11/27 by [EMAIL PROTECTED] 'integrate changes#2304,2305,230' Change 1578 on 1998/07/20 by [EMAIL PROTECTED] 'complete s/foo/PL_foo/ changes ' Change 1575 on 1998/07/20 by [EMAIL PROTECTED] 'integrate ansi branch to get s/' Change 822 on 1998/03/16 by [EMAIL PROTECTED] 'Bump patchlevel.h to 63. ' Change 496 on 1998/02/11 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 457 on 1998/02/03 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 439 on 1998/01/27 by [EMAIL PROTECTED] 'Integrate ansi branch into main' Change 296 on 1997/11/25 by [EMAIL PROTECTED] 'Integrate from ansi branch to m' Change 77 on 1997/09/29 by [EMAIL PROTECTED] 'Start merge with maint-5.004 br' Change 18 on 1997/05/25 by [EMAIL PROTECTED] 'First stab at 5.003 - 5.004 in' Change 1 on 1997/03/28 by [EMAIL PROTECTED] 'Perl 5.003 check-in '
Re: Skipped Tests (was: handler help)
We're getting out of my area of experience here, I don't use mod_perl2, but I hear there are recent changes to CGI.pm. Did you install the latest CGI.pm? You should. 73, Ged. For the record, the last CGI.pm which I could get to work under Win2K/IE 6 is 2.97. V 2.99 corrupts the string returned by $q - url() by %-etc encoding /-etc characters. -- Ron Savage, [EMAIL PROTECTED] on 04/08/2003. Room EF 312 Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia Phone: +61-3-9251 7067, Fax: +61-3-9251 7604 http://www.deakin.edu.au/~rons
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 01:27:01PM -0700, Michael G Schwern wrote: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. Actually, try 6.13. That snapshot had a bug in it. -- Abandon failing tactics.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote: On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. I just tried MM 6.13: that made no difference. Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed loads of its own tests, but made no difference to the libapreq build process. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. I've also tried MM 6.05: that works OK. Attached are the various Makefiles (the top-level one, plus those from the c, Cookie and Request sub-directories), and a transcript of the nmake step, from a build using MM 6.05 (which worked) and another build using MM 6.12 (which failed). I'll move on to trying out those alpha versions and get back to you on which was the first one that failed. Steve makefiles.tar.gz Description: GNU Zip compressed data
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Michael G Schwern wrote: If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. I've also tried MM 6.05: that works OK. Attached are the various Makefiles (the top-level one, plus those from the c, Cookie and Request sub-directories), and a transcript of the nmake step, from a build using MM 6.05 (which worked) and another build using MM 6.12 (which failed). I'll move on to trying out those alpha versions and get back to you on which was the first one that failed. This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. So the best I can offer you at this stage is that something between 6.05 and 6.06_02 broke it. (Probably not what you wanted to hear, I guess, looking at the number of changes in 6.06_01.) Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. OK, I've got MM 6.06_01 building now (it was generating broken Makefiles -- needed to change DIRFILESEP from \ to ^\, and fill in the missing *PERLSAFE macros), and the bad news is that it doesn't build libapreq-1.2 either! I still get the unresolved external symbol boot_libapreq error. So it's one of the many changes between 6.05 and 6.06_01 that broke it. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote: This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. OK, I've got MM 6.06_01 building now (it was generating broken Makefiles -- needed to change DIRFILESEP from \ to ^\, and fill in the missing *PERLSAFE macros), and the bad news is that it doesn't build libapreq-1.2 either! I still get the unresolved external symbol boot_libapreq error. So it's one of the many changes between 6.05 and 6.06_01 that broke it. Well, that narrows it down quite a bit. Which version of mod_perl and Apache is this against and *exactly* what do I have to do to exercise this bug? I haven't built mod_perl in a long time. -- I'll tell you what beats voodoo every time, a big ass knife. -- Overkill Battlebot driver
handler help
Hi.
I need some help with handlers.
I'm a linux newbie. I freshly installed RH 9.
I built perl 5.8.0 from source.
As non-root, I downloaded source for
Apache 1.3.28 and mod_perl 1.28
and built them, using the instructions here
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation
I've also been using Stas' book, Practical Mod Perl,
and the mod_perl developer's cookbook.
The only change I made to the
A_Summary_of_a_Basic_mod_perl_Installation
was using SU to root for the make install for
mod_perl.
The resulting Apache runs fine.
The resuling mod_perl runs cgi-scripts fine.
At times I'm running two servers on the same box, one
listening
to port 80 and one listening to port 8080.
I turned off the ssl piece of both servers, as they
were colliding
on port (I think) 443. I'm not sure if this 2 server
issue
or the turning ssl is relevant to my problem.
Now I'm trying to write my first mod_perl handler:
PerlModule Apache::HandlerTest
Location /handlertest
SetHandler perl-script
PerlHandler Apache::HandlerTest
/Location
package Apache::HandlerTest;
# File is called Apache/HandlerTest.pm
# Path:
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
sub handler {
my $r = shift; # Apache session object
$r-content_type('text/html');
$r-send_http_header;
$r-print( Hello, world. );
}
It dies with an
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your
request
Here's the end of the log
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] Can't locate object method content_type
via package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 6.!
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
As the problem seesm related to finding things, I
tried making
the handler simpler by using no functions
sub handler {
print HTTP/1.0 200 OK\n;
print Content-Type: text/html\n\n;
print htmlbodyHello/body/html;
return 200;
}
This didn't work either --
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] Can't locate object method PRINT via
package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 13.!
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
I guess the print is really a call to $r-print()
(Practical Mod_perl p 238).
This newcoming to mod-perl seeks any help on next
steps.
RKG
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Skipped Tests (was: handler help)
skipped: no reason given
modules/file..ok
modules/httpdconf.ok
modules/include...ok
modules/log...ok
modules/moduleskipped
all skipped: no reason given
modules/perlrun...ok
modules/psections.skipped
all skipped: no reason given
modules/request...skipped
all skipped: no reason given
modules/src...ok
modules/ssi...ok
modules/stage.skipped
all skipped: no reason given
modules/statusok
modules/symbolskipped
all skipped: no reason given
modules/uri...ok
modules/util..ok
internal/api..ok
internal/auth.ok
internal/croakok
internal/dirmagic.ok
internal/errorok
internal/headers..ok
internal/hooksok
internal/http-get.ok
internal/http-postok
internal/proxyok
internal/redirect.ok
internal/rwrite...ok
internal/stacked..ok
internal/tableok
internal/taintok
All tests successful, 6 tests skipped.
Files=34, Tests=400, 24 wallclock secs (19.31 cusr +
1.50 csys = 20.81 CPU)
kill `cat t/logs/httpd.pid`
rm -f t/logs/httpd.pid
rm -f t/logs/error_log
[EMAIL PROTECTED]:~/source/mod_perl-1.28
[EMAIL PROTECTED]:~/source/mod_perl-1.28
[EMAIL PROTECTED]:~/source/mod_perl-1.28
Why did it skip 6 tests?
For example, module and request.
I think these skipped tests could be
what is causing my handlers to fail,
even though the server and my perl cgi works.
I have one dev box for development and one outside
box at an ISP. I am getting these errors on the dev
box. To see if the problem was my dev handler or my
dev conf files (vs. my dev mod_perl installation), I
tried the same handler on the outsider box and
got the same error.
Seeking suggestions help --
RKG
===
PREVIOUS POST
===
Hi.
I need some help with handlers.
I'm a linux newbie. I freshly installed RH 9.
I built perl 5.8.0 from source.
As non-root, I downloaded source for
Apache 1.3.28 and mod_perl 1.28
and built them, using the instructions here
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation
I've also been using Stas' book, Practical Mod Perl,
and the mod_perl developer's cookbook.
The only change I made to the
A_Summary_of_a_Basic_mod_perl_Installation
was using SU to root for the make install for
mod_perl.
The resulting Apache runs fine.
The resuling mod_perl runs cgi-scripts fine.
At times I'm running two servers on the same box, one
listening
to port 80 and one listening to port 8080.
I turned off the ssl piece of both servers, as they
were colliding
on port (I think) 443. I'm not sure if this 2 server
issue
or the turning ssl is relevant to my problem.
Now I'm trying to write my first mod_perl handler:
PerlModule Apache::HandlerTest
Location /handlertest
SetHandler perl-script
PerlHandler Apache::HandlerTest
/Location
package Apache::HandlerTest;
# File is called Apache/HandlerTest.pm
# Path:
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
sub handler {
my $r = shift; # Apache session object
$r-content_type('text/html');
$r-send_http_header;
$r-print( Hello, world. );
}
It dies with an
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your
request
Here's the end of the log
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] Can't locate object method content_type
via package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 6.!
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
As the problem seesm related to finding things, I
tried making
the handler simpler by using no functions
sub handler {
print HTTP/1.0 200 OK\n;
print Content-Type: text/html\n\n;
print htmlbodyHello/body/html;
return 200;
}
This didn't work either --
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] Can't locate object method PRINT via
package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 13.!
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
I guess the print is really a call to $r-print()
(Practical Mod_perl p 238).
This newcomer to mod-perl seeks any help on next
steps.
RKG
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: sorry to break the thread in two. :( Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged.
Re: Skipped Tests (was: handler help)
Exactly like it said in http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation % cd /usr/src % lwp-download http://www.apache.org/dist/httpd/apache_1.3.xx.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-1.xx.tar.gz % tar xzvf apache_1.3.xx.tar.gz % tar xzvf mod_perl-1.xx.tar.gz % cd mod_perl-1.xx % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make make test make install % cd ../apache_1.3.xx % make install --- Ged Haywood [EMAIL PROTECTED] wrote: Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: sorry to break the thread in two. :( Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: --- Ged Haywood [EMAIL PROTECTED] wrote: How did you do the perl Makefile.PL step? % cd /usr/src % tar xzvf apache_1.3.xx.tar.gz % tar xzvf mod_perl-1.xx.tar.gz % cd mod_perl-1.xx % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 So your non-root user has write permission in /usr/src? H... % make make test make install This can't work, you need to be root to make install. 73, Ged. PS: Did you build your own Perl? Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:).
Re: Skipped Tests (was: handler help)
Ged -- Sorry I wasn't fully explicit, it is still early in the morning: So your non-root user has write permission in /usr/src? H... Rather than /usr/src, I put in /home/aprk % make make test make install This can't work, you need to be root to make install. Yes, you are correct. make make test as non-root, then install as root. (Odd, isn't it, the docs at http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation don't make this explicit?) PS: Did you build your own Perl? Yes, 5.8.0 Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:). Excellent point. No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. I think my next step should be to start over fresh. Again. As a newbie, may I ask 4 basic questions: [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? [2] How do I uninstall everything from [1], so I can start fresh? [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. (Want my dev box to match the outside box as much as possible). This newsgroup keeps mentioning build from sources, will I be going astray trying the rpm route? [4] Is a full uninstall enough, or should I reinstall RH itself? Many thanks for your generosity explaining these mysteries to a newcomer. -- A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: handler help
On Fri, 2003-08-01 at 07:02, Tofu Optimist wrote: I'm a linux newbie. I freshly installed RH 9. I built perl 5.8.0 from source. Go and change your locale from UTF8 to en_US or C. See this for why: http://archive.develooper.com/[EMAIL PROTECTED]/msg97360.html As non-root, I downloaded source for Apache 1.3.28 and mod_perl 1.28 and built them, using the instructions here http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation Okay... [Thu Jul 31 18:34:08 2003] [error] [client 192.168.1.2] Can't locate object method content_type via package Apache::RequestRec at /usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm line 6.! That's mod_perl 2. (There is Apache::RequestRec in mod_perl 1.) You must have an older one on your box and you are trying to run this handler with it. Figure out where you installed mod_perl 1 and use that instead. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 10:31, Tofu Optimist wrote: [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? Well, you can run updatedb and then use locate to look for things like apachectl and Apache.pm. [2] How do I uninstall everything from [1], so I can start fresh? There is no simply way to uninstall software that you installed from source. There are things you can do though. First uninstall any apache or mod_perl rpms. Then you can clear out all the Apach::* modules from your perl lib, and delete all the web server stuff (which is typically installed under a single directory). [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. Okay, then stop reading docs for mod_perl 1. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. Don't do that. mod_perl 2 is basically in alpha right now and changes every day. If you plan to run it, you must keep on top of development. The rpms for mod_perl 2 are ancient at this point. [4] Is a full uninstall enough, or should I reinstall RH itself? The latter is more complete, but if you don't see any more httpd.conf files or Apache:: modules, you have probably cleaned things close enough. - Perrin
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Rather than /usr/src, I put in /home/aprk That's fine. But in future, tell us what you did, not some fiction... :) Yes, you are correct. make make test as non-root, then install as root. (Odd, isn't it, the docs at http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation don't make this explicit?) Yes, I always think that, but many of the Open Source packages neglect to mention this point every time it might be mentioned. I think authors expect it to be either very obvious or else perhaps unnecessary - some operating systems don't have a Unix-like permisisons system. Did you build your own Perl? Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. Have you cleaned up any old Apaches and mod_perls? No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're happy that it's all as you wnt it, you might want to use chkconfig to set it up to start at boot again. I think my next step should be to start over fresh. Again. :) [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? [2] How do I uninstall everything from [1], so I can start fresh? Well RH should let you uninstall packages with rpm, but I don't use rpm and I tend to avoid RedHat so I don't know exactly how you'd do it. My preference would be to look in /usr/local/ and /var/lib to see if there are any apache things such as /usr/local/apache, and if so go in there as root and rm -rf the entire apache directory. That will perhaps throw away config files etc. you've been working on, you might want to make backups. When you've done that you might want to use slocate to build a database of filenames on your filesystem, then use it to search for any httpd or apachectl files that escaped. If so there'll probably be truckloads of files in there with them. Nukem. The source trees in your home directory don't matter. Nuke them too. You won't need to do anything about Perl on your system if you really did compile it from source yourself. [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. (Want my dev box to match the outside box as much as possible). This newsgroup keeps mentioning build from sources, will I be going astray trying the rpm route? I hate RPMs. For Apache2/modperl2 you would be better off going to the CVS sources unless you can get hold of a very recent RPM, things are changing really fast in the mod_perl version 2 codebase. True, it could be important for your dev box to match your prod box, but when you figure out what's going on it will probably matter less - until you start doing really fancy stuff, when it will start to matter again. [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. mysteries to a newcomer. FWIW you sound like you're picking it up quickly. 73, Ged.
Re: Skipped Tests (was: handler help)
Thanks Ged. [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. Well, I opted to reinstall everything, starting with a fresh RH9. Then I removed all the relevant RH9 RPMS: [EMAIL PROTECTED] root]# rpm -e mod_ssl [EMAIL PROTECTED] root]# rpm -e mod_python [EMAIL PROTECTED] root]# rpm -e pho [EMAIL PROTECTED] root]# rpm -e php-ldap [EMAIL PROTECTED] root]# rpm -e php-imap [EMAIL PROTECTED] root]# rpm -e php [EMAIL PROTECTED] root]# rpm -e redhat-config-httpd [EMAIL PROTECTED] root]# rpm -e webalizer [EMAIL PROTECTED] root]# rpm -e mod_perl [EMAIL PROTECTED] root]# rpm -e httpd (I had to take out mod_ssl, mod_python, etc so as to free up dependencies.) MY QUESTION: Now I want to remove perl, too: [EMAIL PROTECTED] root]# rpm -e perl error: Failed dependencies: perl is needed by (installed) logwatch-4.3.1-2 perl is needed by (installed) w3m-0.3.2.2-5 perl = 0:5.002 is needed by (installed) perl-Filter-1.29-3 perl = 0:5.00503 is needed by (installed) perl-DateManip-5.40-30 perl = 0:5.000 is needed by (installed) perl-DateManip-5.40-30 perl = 0:5.00503 is needed by (installed) perl-HTML-Tagset-3.03-28 perl = 1:5 is needed by (installed) perl-HTML-Tagset-3.03-28 perl = 5.6.0 is needed by (installed) perl-HTML-Parser-3.26-17 perl = 0:5.004 is needed by (installed) perl-HTML-Parser-3.26-17 perl = 0:5.00503 is needed by (installed) perl-Parse-Yapp-1.05-30 perl = 0:5.004 is needed by (installed) perl-Parse-Yapp-1.05-30 perl = 0:5.00503 is needed by (installed) perl-URI-1.21-7 perl = 0:5.00503 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.002 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.004 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.005 is needed by (installed) perl-libwww-perl-5.65-6 perl = 2:5.8.0 is needed by (installed) perl-XML-Parser-2.31-15 perl = 0:5.004 is needed by (installed) perl-XML-Parser-2.31-15 perl = 5.6.0 is needed by (installed) perl-libxml-perl-0.07-28 perl = 0:5.005 is needed by (installed) perl-libxml-perl-0.07-28 perl = 5.6.0 is needed by (installed) perl-XML-Dumper-0.4-25 perl = 5.6.0 is needed by (installed) perl-XML-Encoding-1.01-23 perl = 0:5.005 is needed by (installed) perl-XML-Encoding-1.01-23 perl = 0:5.00503 is needed by (installed) perl-libxml-enno-1.02-29 perl = 5.6.0 is needed by (installed) perl-XML-Grove-0.46alpha-25 perl = 0:5.005 is needed by (installed) perl-XML-Grove-0.46alpha-25 perl = 0:5.004 is needed by (installed) perl-XML-Twig-3.09-3 perl = 5.6.1 is needed by (installed) foomatic-2.0.2-15 perl is needed by (installed) redhat-config-printer-0.6.47-1 perl = 1:5 is needed by (installed) emacs-21.2-33 perl is needed by (installed) libgnomeprint22-2.2.1.1-3 perl is needed by (installed) docbook-dtds-1.0-17 perl is needed by (installed) libgnomeprint-1.116.0-6 perl is needed by (installed) desktop-printing-0.1.10-6 perl = 1:5 is needed by (installed) xscreensaver-4.07-2 perl is needed by (installed) autoconf-2.57-3 perl = 0:5.000 is needed by (installed) autoconf-2.57-3 perl = 0:5.005_03 is needed by (installed) autoconf-2.57-3 perl is needed by (installed) automake14-1.4p6-5.1 perl is needed by (installed) automake15-1.5-6 perl = 0:5.005 is needed by (installed) automake15-1.5-6 Now, in this forum I heard the importance of building perl with the same compiler that you use for httpd and mod_perl. Am I going to have problems following the MP 2.0 install instructions http://perl.apache.org/docs/2.0/user/install/install.html if I don't nuke the current perl first? Thanks. And this time I'll restrict my reading to the 2.0 install docs, rather than dipping back into the 1.0 docs in the middle of 2.0 install. (Doh!) Thanks for advice on this -- A Did you build your own Perl? Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. Have you cleaned up any old Apaches and mod_perls? No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 16:24, Tofu Optimist wrote: Am I going to have problems following the MP 2.0 install instructions http://perl.apache.org/docs/2.0/user/install/install.html if I don't nuke the current perl first? No, you should be fine. However, I have also simply installed a new perl on top of the one shipped by RH with no problems. (I did this because I wanted to use 5.6.1 rather than 5.8.0.) You will be blowing the RPM system by doing that, so it's not an advisable way to handle a large cluster of machines, but it works fine if you just need to get a quick dev environment bootstrapped. - Perrin
Re: Skipped Tests (was: handler help)
Ack!! My perl build failed. Here's what I did nuke the RPMS [EMAIL PROTECTED] root]# rpm -e mod_ssl [EMAIL PROTECTED] root]# rpm -e mod_python [EMAIL PROTECTED] root]# rpm -e pho [EMAIL PROTECTED] root]# rpm -e php-ldap [EMAIL PROTECTED] root]# rpm -e php-imap [EMAIL PROTECTED] root]# rpm -e php [EMAIL PROTECTED] root]# rpm -e redhat-config-httpd [EMAIL PROTECTED] root]# rpm -e webalizer [EMAIL PROTECTED] root]# rpm -e httpd [EMAIL PROTECTED] root]# rpm -e mod_perl download perl, apache, mod_perl ls -rw-rw-r--1 aprk aprk 6260081 Jul 7 11:09 httpd-2.0.47.tar.gz -rw-rw-r--1 aprk aprk 918029 Apr 27 22:53 mod_perl-2.0-current.tar.gz -rw---1 aprk aprk 4145152 Aug 1 16:48 perl-5.8.0.tar.gz unzip and untar them, then cd perl-5.8.0 ./Configure -des make make test Here's the failure Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Locale/Codes/t/all.t 20 2 10.00% 9-10 ../lib/Locale/Codes/t/languages.t 59 1 1.69% 22 42 tests and 406 subtests skipped. Failed 2/712 test scripts, 99.72% okay. 3/68552 subtests failed, 100.00% okay. Oh helpful gurus, any advice? With gratitude -- A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 17:46, Tofu Optimist wrote: Ack!! My perl build failed. [...] Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Locale/Codes/t/all.t 20 2 10.00% 9-10 ../lib/Locale/Codes/t/languages.t 59 1 1.69% 22 42 tests and 406 subtests skipped. Failed 2/712 test scripts, 99.72% okay. 3/68552 subtests failed, 100.00% okay. You didn't follow my earlier advice about changing the locale, did you? I wasn't kidding about that. You can't build perl 5.8.0 successfully on a RH 9 system unless you change the locale. Note that 5.8.1 does not have this problem and is about to be released. - Perrin
Re: Skipped Tests (was: handler help)
I'm not TRYING to be difficult; I am clueless. :) Exactly HOW do I change the locale? And after I do that, I do my make make install again, yes? Many thanks! :) A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, now that I've had a day or so to play with it (using both worker and prefork), I have yet to see any issues. It looks good. However, any further testing I do will probably be limited to prefork, since the overhead of ithreads manages to eat all the memory on my workstation. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KuSoA4aoazQ9p2cRAiDAAKDxbLR17B4R/2w8tD56aKTcKlQ8EgCgo8B0 ICKCbkeKlf6Xe/WE7bwlpm8= =C6/k -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote: I just tried MM 6.13: that made no difference. Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed loads of its own tests, but made no difference to the libapreq build process. Oh yeah, I didn't update the snapshot. Thanks for the reminder. -- You can't control the universe with a jar of red pepper. http://www.goats.com/archive/981004.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote: On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote: This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. OK, I've got MM 6.06_01 building now (it was generating broken Makefiles -- needed to change DIRFILESEP from \ to ^\, and fill in the missing *PERLSAFE macros), and the bad news is that it doesn't build libapreq-1.2 either! I still get the unresolved external symbol boot_libapreq error. So it's one of the many changes between 6.05 and 6.06_01 that broke it. Well, that narrows it down quite a bit. Which version of mod_perl and Apache is this against and *exactly* what do I have to do to exercise this bug? I haven't built mod_perl in a long time. I'm using Apache 1.3.27, mod_perl 1.28, libapreq-1.2, but I'm on Windows with MS VC++ 6.0, so this might not be very useful to you since you haven't got such a setup yourself... Anyway, here goes; it's probably pretty similar on whatever OS you're on (perhaps with an extra ./configure ... line before the Apache make?) - Unpack Apache, mod_perl, libapreq into C:\Temp - cd to C:\Temp\apache_1.3.27\src - Run nmake /f makefile.win installr. That builds Apache and installs it into C:\apache by default. - cd to C:\Temp\mod_perl-1.28 - Run perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules. - Run nmake, nmake test, nmake install as usual. - cd to C:\Temp\libapreq-1.2 - Run perl Makefile.PL - Run nmake -- that fails with the unresolved external symbol boot_libapreq error. That's it. BTW, I've been looking at the Makefiles that I sent previously, and have found something interesting. The Makefile in the c sub-directory from the 6.05 build contains this: = # --- MakeMaker dynamic section: ## $(INST_PM) has been moved to the all: target. ## It remains here for awhile to allow for old usage: make dynamic #dynamic :: Makefile dynamic :: Makefile @$(NOOP) = while the corresponding section from the 6.12 build contains this: = # --- MakeMaker dynamic section: ## $(INST_PM) has been moved to the all: target. ## It remains here for awhile to allow for old usage: make dynamic dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT) $(NOECHO) $(NOOP) = If that's relevant, then the latter looks more likely to be correct, doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and the only problem here is that libapreq was previously relying on that bug? Steve
Re: Skipped Tests (was: handler help)
I am still here, trying to build mod_perl 2. Many thanks to everyone who offered help. To recap: I freshly installed RedHat 9 on a box, then used RPM to remove modules involving httpd. (See notes below). Then I built perl 5.8.0 from source, first doing a export LANG=C to address the UTF bug. The perl build worked. I did everything as non-root until the make install, which I did as root. I then built Apache 2.0.47 from source. Seemed to go OK (there was no make test step...) I did everything as non-root until the make install, which I did as root. Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, and plowed ahead. (Maybe I should have stopped here at the first sign of trouble) As non-root, did cd mod_perl-1.99_09/ perl Makefile.PL MP_AP_PREFIX=$HOME/httpd/prefork MP_INST_APACHE2=1 make which went fine. make tests did not work -- below is the bottom of the output. Argh! Suggestions? - A PS Below the make test output below, I included a note file where I've been pasting commands I've run... in some places, it contains notes, rather than exact linux commands. == = BOTTOM OF FAILED make test == snip /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 /home/aprk/httpd/prefork/bin/httpd -d /home/aprk/src/mod_perl-1.99_09/t -f /home/aprk/src/mod_perl-1.99_09/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.47 (prefork MPM) waiting for server to start: ..[Fri Aug 01 22:34:36 2003] [info] 19 Apache:: modules loaded [Fri Aug 01 22:34:36 2003] [info] 3 APR:: modules loaded [Fri Aug 01 22:34:36 2003] [info] base server + 8 vhosts ready to run tests .. waiting for server to start: ok (waited 2 secs) server SAM:8529 started server SAM:8530 listening (TestProtocol::echo_filter) server SAM:8531 listening (TestProtocol::echo) server SAM:8532 listening (TestPreConnection::note) server SAM:8533 listening (TestFilter::in_str_msg) server SAM:8534 listening (TestFilter__both_str_con_add) server SAM:8535 listening (TestFilter::in_bbs_msg) server SAM:8536 listening (TestDirective::perlmodule) server SAM:8537 listening (TestDirective::perlrequire) server SAM:8538 listening (TestDirective::perlloadmodule4) server SAM:8539 listening (TestDirective::perlloadmodule5) server SAM:8540 listening (TestDirective::perlloadmodule3) server SAM:8541 listening (TestDirective::perlloadmodule6) apache/add_config..ok apache/cgihandler..ok apache/conftreeok apache/constants...ok apache/postok apache/readok apache/scanhdrsok apache/scanhdrs2...ok apache/send_cgi_header.ok apache/subprocess..ok apache/write...ok api/access.ok api/aplog..ok api/conn_rec...ok api/lookup_uri.ok api/lookup_uri2ok api/module.ok api/r_subclass.ok api/request_recok api/response...ok api/rutil..ok api/sendfile...ok api/server_rec.ok api/server_utilok api/uriok apr/base64.ok apr/constants..ok apr/date...ok apr/netlib.ok apr/os.ok apr/pool...ok apr/socket.ok apr/string.ok apr/table..ok apr/threadmutexskipped all skipped: Perl was not built with 'ithreads' enabled apr/util...ok apr/uuid...ok compat/apache..ok compat/apache_file.ok compat/apache_tableok compat/apache_uri..ok compat/apache_util.ok compat/conn_authen.ok compat/request.ok compat/request_bodyok compat/send_fd.ok directive/env..ok directive/perl.ok directive/perldo...ok directive/perlloadmodule...ok directive/perlloadmodule2..ok directive/perlloadmodule3..ok directive/perlloadmodule4..ok directive/perlloadmodule5..ok directive/perlloadmodule6..ok directive/perlmodule...ok directive/perlrequire..ok directive/pod..ok directive/setupenv.ok error/api..ok error/runtime..ok error/syntax...ok filter/both_str_con_addok filter/both_str_req_addok filter
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 11:35:47AM +0100, Steve Hay wrote:
=
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: make dynamic
#dynamic :: Makefile
dynamic :: Makefile
@$(NOOP)
=
while the corresponding section from the 6.12 build contains this:
=
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: make dynamic
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
=
If that's relevant, then the latter looks more likely to be correct,
doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
the only problem here is that libapreq was previously relying on that bug?
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after Makefile
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
problems with things finding libareq.so, sort out later leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should fix the symptoms by restoring the hack for a quick fix.
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
It would be nice if someone could dig through libapreq's version history
and figure out when and why this hack was put in.
--
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Exactly HOW do I change the locale? http://twiki.org/cgi-bin/view/Codev/UsingPerl58OnRedHat8 about half a dozen messages down. See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 make make install again, yes? Better start with % cd /home/directory/src (or whatever your home directory is) and then % rm -rf apache_1.3.28 % rm -rf mod_perl-1.28 % tar xzvf apache_1.3.28.tgz % tar xzvf mod_perl-1.28 % perl Makefile.PL and I would suggest that in future instead of % make make install that you do these steps as separate commands % make % make test % su Password: # make install # exit % which will give you the opportunity to abandon ship at any point before the install. Finally if you do % script before you start the 'perl Makefile.PL' step then everything you see on the screen will be logged to a file so you can peruse it later if you feel the need. It will help you to become familiar with build the process. It looks a lot more complicated than it is. Really. % man script for more details. I'd use 'less -S' to look at the scriptfile. In fact I always alias 'less -S' to 'li' in my login scripts... :) 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: To recap: I freshly installed RedHat 9 on a box, then used RPM to remove modules involving httpd. (See notes below). Then I built perl 5.8.0 from source, first doing a export LANG=C why not LANG=en_US ? Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, Oooohhh. Don't do that... We're getting out of my area of experience here, I don't use mod_perl2, but I hear there are recent changes to CGI.pm. Did you install the latest CGI.pm? You should. 73, Ged.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Stephen Clouse wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? That was a different though related issue. since mod_perl's test suite is huge (loads about 100 test modules + about 50 normal modules) it takes a long time to copy the mutable data when creating a new perl clone. That should be fixed when perl implements COW (copy-on-write), so it'll work similar to the OS-level sharing. However this won't happen in 5.8.1 :( __ 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: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. BAD NEWS: There seems to be a problem with ExtUtils-MakeMaker 6.12 included in perl-5.8.1-RC3. I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl as well, and found that it doesn't build. I get the following error: ... link -out:..\blib\arch\auto\libapreq\libapreq.dll ... libapreq.def : error LNK2001: unresolved external symbol boot_libapreq If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in perl-5.8.0) then it it's all OK. The question is: why is it trying to build libapreq.dll? It should only build Request.dll and Cookie.dll, which would probably explain why boot_libapreq is undefined. I'll continue looking into it myself, and can supply more info to anyone that wants it, but I thought I'd better raise the alarm quickly first. I have a similar problem on linux, Request.so dynamically links libapreq.so, which subsequently can't be found. I'm looking at it. __ 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: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 31, 2003 at 11:41:42AM +0200, Stas Bekman wrote: Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. *** mod_perl version 1.9910 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS= /opt/apache/bin/apxs MP_COMPAT_1X = MP_DEBUG = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_MAINTAINER = 1 MP_TRACE = 1 MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /opt/apache/bin/httpd -V Server version: Apache/2.0.47 Server built: Jul 30 2003 17:58:08 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/opt/apache -D SUEXEC_BIN=/opt/apache/bin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /opt/perl/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.20-19.8, archname=i686-linux-thread-multi uname='linux stephenc.theiqgroup.com 2.4.20-19.8 #1 tue jul 15 15:25:37 edt 2003 i686 i686 i386 gnulinux ' config_args='-des -Dprefix=/opt/perl -Dinstallprefix=/opt/perl -Dvendorprefix=/opt/perl -Dsiteprefix=/opt/perl -Dmyhostname=localhost [EMAIL PROTECTED] -Dcf_by=IQG-SPC -Dcc=gcc -Doptimize=-O3 -march=i686 -mcpu=i686 -ggdb3 -Duseshrplib -Duseperlio -Dusethreads -Duseithreads -Dusemymalloc' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -march=i686 -mcpu=i686 -ggdb3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing' ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/opt/perl/lib/5.8.1/i686-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: RC3 Built under linux Compiled at Jul 30 2003 17:12:12 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /opt/perl/lib/5.8.1/i686-linux-thread-multi /opt/perl/lib/5.8.1 /opt/perl/lib/site_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/site_perl/5.8.1 /opt/perl/lib/site_perl /opt/perl/lib/vendor_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/vendor_perl/5.8.1 /opt/perl/lib/vendor_perl . Unfortunately a couple of the modules we're using don't want to cooperate with ithreads (XML::GDOME is a notable one). I'm working on patches for these; in the meantime, I'll at least give it a thorough run-through with prefork. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KZcHA4aoazQ9p2cRAmaXAKCIE5sROjyScppt8qu47Pm7LJw6kgCfajBU 1E4cCfuKlCnKzdwCuQVzUzw= =H4RV -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a
by product and never was intented to be installed. Request.so was statically
linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so
is linked, it links libapreq.so dynamically, and of course it can't resolve it
later when loading.
This patch fixes things for me in libapreq and works with MM 6.03 and 6.12.
Steve, please confirm that it works for you and I'll commit it.
However Michael may want to do something else about it, since the two versions
don't do the same thing. And other people may have similar problems.
Index: Cookie/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Cookie/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Cookie/Makefile.PL 3 Apr 2001 19:24:08 - 1.5
+++ Cookie/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
-'LIBS' = -L$root -lapreq,
+'OBJECT' = Cookie.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
Index: Request/Makefile.PL
===
RCS file: /home/cvs/httpd-apreq/Request/Makefile.PL,v
retrieving revision 1.5
diff -u -r1.5 Makefile.PL
--- Request/Makefile.PL 3 Apr 2001 19:24:09 - 1.5
+++ Request/Makefile.PL 31 Jul 2003 11:31:06 -
@@ -27,7 +27,7 @@
@mm_args,
'INC' = -I../c . $src-inc,
'TYPEMAPS' = $src-typemaps,
- 'LIBS' = -L$root -lapreq,
+ 'OBJECT' = Request.o $root/libapreq.a,
'dynamic_lib' = {
'OTHERLDFLAGS' = $src-otherldflags,
},
__
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: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. It seems likely that if my build ever got as far as trying to build Request.dll then it would fail without your patch, and your patch would fix that bit, but at the moment I'm not getting that far. Let me see if I can make it skip building the shared object with 6.12, which will resolve the problem for you as well. __ 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: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Here is what happens: MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was just a by product and never was intented to be installed. Request.so was statically linking libapreq.a into it. Now with 6.12 it creates both libapreq.so and libapreq.so, so when Request.so is linked, it links libapreq.so dynamically, and of course it can't resolve it later when loading. This patch fixes things for me in libapreq and works with MM 6.03 and 6.12. Steve, please confirm that it works for you and I'll commit it. No, it doesn't fix it :-( My problem sounds a little different to yours. You talk above about ... when Request.so is linked..., but my build process doesn't get that far. Under MM 6.03 it used to build libapreq.lib, then Request.dll then Cookie.dll. Now, under MM 6.12, it builds libapreq.lib, then falls over (boot_libapreq unresolved) when trying to build libapreq.dll. I think the cause is the same. MM 6.12 builds the shared object of libapreq (dll in your case and .so in mine), and it didn't use to do that. OK, try this patch: Index: c/Makefile.PL === RCS file: /home/cvs/httpd-apreq/c/Makefile.PL,v retrieving revision 1.7 diff -u -r1.7 Makefile.PL --- c/Makefile.PL 3 Apr 2001 19:24:12 - 1.7 +++ c/Makefile.PL 31 Jul 2003 13:20:35 - @@ -18,7 +18,7 @@ WriteMakefile( #grr, problems with things finding libapreq.so, sort out later. 'LINKTYPE' = 'static', -# 'SKIP' = [qw(dynamic_lib dynamic_bs)], + 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)], 'NAME' = 'libapreq', 'INC'= $src-inc, 'TYPEMAPS' = $src-typemaps, __ 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: need your help to test mod_perl with perl-5.8.1-RC3
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Here is what happens:
MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a
was just a by product and never was intented to be installed.
Request.so was statically linking libapreq.a into it.
Now with 6.12 it creates both libapreq.so and libapreq.so, so
when Request.so is linked, it links libapreq.so dynamically, and
of course it can't resolve it later when loading.
This patch fixes things for me in libapreq and works with MM 6.03
and 6.12. Steve, please confirm that it works for you and I'll
commit it.
No, it doesn't fix it :-(
My problem sounds a little different to yours. You talk above
about ... when Request.so is linked..., but my build process
doesn't get that far.
Under MM 6.03 it used to build libapreq.lib, then Request.dll then
Cookie.dll.
Now, under MM 6.12, it builds libapreq.lib, then falls over
(boot_libapreq unresolved) when trying to build libapreq.dll.
I think the cause is the same. MM 6.12 builds the shared object of
libapreq (dll in your case and .so in mine), and it didn't use to
do that.
OK, try this patch:
No, still doesn't fix it :-(
Doesn't seem to make any difference, actually. It still tries to
build libapreq.dll, and still fails in the same way. I've attached
the c/Makefile that was generated by the patched c/Makefile.PL (which
should have skipped the dynamic_* bits, but seems not to have done).
But it never received the SKIP argument, from your Makefile:
# MakeMaker Parameters:
# INC = q[ -IC:/apache/include
-IC:/apache/include/../os/win32
-IC:/Temp/mod_perl-1.28/src/modules/perl ]
# NAME = q[libapreq]
# OBJECT = q[apache_request.o apache_cookie.o
apache_multipart_buffer.o]
# TYPEMAPS = [q[C:/Temp/mod_perl-1.28/src/modules/perl/typemap]]
# VERSION = q[1.2]
ah, of course c/Makefile.PL has a special case for WIN32. Try this:
G.
OK, that's better, but it now falls over saying don't know how to make
'dynamic'!
This patch finally fixes it for me:
--- Makefile.PL.orig2001-04-03 20:24:12.0 +0100
+++ Makefile.PL2003-07-31 15:17:03.0 +0100
@@ -18,7 +18,7 @@
WriteMakefile(
#grr, problems with things finding libapreq.so, sort out later.
'LINKTYPE' = 'static',
-# 'SKIP' = [qw(dynamic_lib dynamic_bs)],
+ 'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'NAME' = 'libapreq',
'INC' = $src-inc,
'TYPEMAPS' = $src-typemaps,
@@ -67,6 +67,8 @@
WriteMakefile('NAME' = 'libapreq',
'TYPEMAPS' = [ $ENV{MP_INC}/typemap ],
'VERSION' = $myVERSION,
+'LINKTYPE' = 'static',
+'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'OBJECT' = @objs,
'INC' = qq{ -I$ENV{AP_INC}
-I$ENV{AP_INC}/../os/win32 -I$ENV{MP_INC} },
);
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. -- You're the sickest teenager I've ever set my wallet on.
need your help to test mod_perl with perl-5.8.1-RC3
Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Any version of mod_perl 1.x works with perl-5.8.1-RC3. However for mod_perl 2.0 you must use the current cvs version. mod_perl 1.99_09 and earlier releases won't work with perl-5.8.1-RC3. You can get it from here: http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution If you can test your favorite CPAN modules with this perl release you will do yourself and others a big favor if you discover some bugs and get them fixed before 5.8.1 sees the light. Thanks. Original Message From: Jarkko Hietaniemi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RC3 is out Lord Hong had a mind like a knife, although possibly a knife with a curved blade. -- Terry Pratchett, Interesting Times http://www.iki.fi/jhi/perl-5.8.1-RC2.tar.bz http://www.iki.fi/jhi/perl-5.8.1-RC2.tar.gz (or rsync -avz ftp.linux.activestate.com::perl-5.8.x perl-5.8.x) and in a while the public http://www.cpan.org/authors/id/J/JH/JHI/perl-5.8.1-RC3.tar.gz The randomised hashes are on. Therefore please unleash your code base on this, or maybe it's vice versa. Since we are talking randomised here, run the tests a few times... Also, I'm still wary of the new module PKI signature hooks in CPAN.pm, please test that carefully too (like for example how does it look and feel when installed to a box with no Perl, or to a box with no gpg). I'm very eager to get the 5.8.1 final out as soon as possible, not that this comes as a big surprise to anyone. -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen -- __ 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: need your help to test mod_perl with perl-5.8.1-RC3
Jarkko's original post had the links wrong: Here are the right links: http://www.iki.fi/jhi/perl-5.8.1-RC3.tar.bz http://www.iki.fi/jhi/perl-5.8.1-RC3.tar.gz or rsync -avz ftp.linux.activestate.com::perl-5.8.x perl-5.8.x You might also want to read the perldelta online: http://www.iki.fi/jhi/perldelta-RC3.html __ 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: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? Anyway, now I'm off to load some production code into it and see how it fares. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KF+bA4aoazQ9p2cRAqxdAJ9T/BOqg4jNo25vay1PzIRe+hM8jgCgwbI9 dmGE6oAn+TRiL+ZYRfsKzhY= =HsN4 -END PGP SIGNATURE-
re: AuthenNTLM - help
Shannon, i put it working on Solaris, mod_perl, NTLM and mod_jk2 (to comunicate with Tomcat), but unfortunatily, it just works when i access from windows 9x and Linux. When i access by NT/2000/XP, it just doesn't work at all (no validation). So, i decide, for a while, make it work on Linux! I am using Conectiva 8, and it is working fine. Thanks. Shannon Eric Peevey escreveu: Francisco de Assis Tristão wrote: Shannon, i got it configured with apache-1.3.27/mod_ssl/2.8.12 OpenSSL/0.9.6g mod_perl/1.25, all by hand, but it only works fine when i use just http - when i access the pages with https, apache doesn't ask for the user... Have you any idea about what is wrong? The version of apache with mod_ssl i took from sunfreeware, mod_perl and ApacheAuthenNTLM i compiled by myself. Sorry, I don't know why this might be happening... Are you running through a proxy server? I have seen a lot of problems when ntlm authentication through a proxy server... speeves cws I am forwarding this to the modperl list... Please include the list in your replies. thanks, speeves cws
RE: Need help, Global Hash corruption under mod_perl in perl5.8.0!?!
I think you should consider using a system that is actually supported. Embperl, Apache::ASP, Text::Template, and Mason all have similar syntax to ePerl. There are lots of other things on CPAN that might be even closer in syntax, but are not as widely used and well supported. I just can't understand where the Apache::ePerl bug can be -- it so simple and so clear module.. and it worked on older perl! You should go through the change log for Perl 5.8 then, since something that changed between 5.6 and 5.8 must be causing problems for you. where is all community? it's so silent in the conference. what the language perl programmers migrated to? JSP, PHP? :( Are you asking why more people aren't responding to your question? Probably because almost no one uses ePerl any more. Thank you Perrin for you responses! Embperl, Apache::ASP, Text::Template, and Mason (!) all are great, but .. they all great for middle size web sites, not WML WAP, in cases where (some) people prefer php to Perl. I think I should just patch A::Registry with function that converts eperl script to perl script and let eperl live some more time :-) Are you asking why more people aren't responding to your question? Probably because almost no one uses ePerl any more. no, I just looked at number of newbies and posts.. Anyway It helped and I found the bug ;-) -vlad
Re: AuthenNTLM - Help
Francisco de Assis Tristão wrote: Shannon, i got it configured with apache-1.3.27/mod_ssl/2.8.12 OpenSSL/0.9.6g mod_perl/1.25, all by hand, but it only works fine when i use just http - when i access the pages with https, apache doesn't ask for the user... Have you any idea about what is wrong? The version of apache with mod_ssl i took from sunfreeware, mod_perl and ApacheAuthenNTLM i compiled by myself. Sorry, I don't know why this might be happening... Are you running through a proxy server? I have seen a lot of problems when ntlm authentication through a proxy server... speeves cws
RE: Need help, Global Hash corruption under mod_perl in perl 5.8.0!?!
We had recompiled ePerl for 5.8.0 and mod_perl (1.27 and later 1.28)
statically linked with Apache with default options (does it include
threads?)
I'm using only Apache::ePerl which allows me use Perl in the the way
like
PHP, since I don't need Mason or EmbPerl html features for small WAP
resources.
It just does simple things parse eval perl code saving it in global
$Cache hash. It use C code only for parsing eperl scripts
sourse. Switching off $Cache (adding if (1 || ..)) -- always compiling,
eliminate the
Cache bug. Something just mix key value pairs in global hash shared by
httpd process,
after several requests. I just can't understand where the Apache::ePerl
bug can be --
it so simple and so clear module.. and it worked on older perl!
I will keep debuging,
-vlad
where is all community? it's so silent in the conference. what the
language
perl programmers migrated to? JSP, PHP? :(
===
package Apache::ePerlWAP;
# requirements and runtime behaviour
require 5.00325;
use strict;
use vars qw($VERSION);
use vars qw($nDone $nOk $nFail $Cache $Config);
# imports
use Carp;
use Apache ();
use Apache::Debug;
use Apache::Constants qw(:common OPT_EXECCGI);
use FileHandle ();
use File::Basename qw(dirname);
use Parse::ePerl;
use lib '/usr/home/projects/lib';
use IMMO::Translit qw(:all); # to translit or utf8
# private version number
$VERSION = do { my @v=(2.2.14=~/\d+/g); sprintf %d..%02dx$#v,@v };
# globals
$nDone = 0;
$nOk= 0;
$nFail = 0;
$Cache = {};
...
#
# the mod_perl handler
#
sub handler {
my ($r) = @_;
my ($filename, $data, $error, $fh);
my (%env, $rc, $mtime, $owner, $size, $header, $key, $value, $path,
$xpath, $dir, $file, @S);
# statistic
$nDone++;
...
# check cache for existing P-code
# ! added 1 ||
if (not ($Cache-{$filename}
and $Cache-{$filename}-{CODE}
and $Cache-{$filename}-{SIZE} == $size
and $Cache-{$filename}-{MTIME} == $mtime
and $Cache-{$filename}-{OWNER} eq $owner)) {
# read script
local ($/) = undef;
$fh = new FileHandle $filename;
$data = $fh;
$fh-close;
# run the preprocessor over the script
if (not Parse::ePerl::Preprocess({
Script = $data,
Cwd= dirname($filename),
Result = \$data
})) {
send_errorpage($r, 'Error on preprocessing script', '');
$nFail++;
return OK;
}
# translate the script from bristled
# ePerl format to plain Perl format
if (not Parse::ePerl::Translate({
Script = $data,
BeginDelimiter = $Config-{'BeginDelimiter'},
EndDelimiter= $Config-{'EndDelimiter'},
CaseDelimiters = $Config-{'CaseDelimiters'},
ConvertEntities = $Config-{'ConvertEntities'},
Result = \$data
})) {
send_errorpage($r, 'Error on translating script from
bristled to plain format', '');
$nFail++;
return OK;
}
# precompile the source into P-code
$error = '';
if (not Parse::ePerl::Precompile({
Script = $data,
Name = $filename,
Cwd= dirname($filename),
Result = \$data,
Error = \$error
})) {
send_errorpage($r, 'Error on precompiling script from plain
format to P-code', $error);
$nFail++;
return OK;
}
# set the new results
$Cache-{$filename} = {};
$Cache-{$filename}-{CODE} = $data;
$Cache-{$filename}-{SIZE} = $size;
$Cache-{$filename}-{MTIME} = $mtime;
$Cache-{$filename}-{OWNER} = $owner;
}
# retrieve precompiled script from cache
$data = $Cache-{$filename}-{CODE};
# evaluate script
if (not Parse::ePerl::Evaluate({
Script = $data,
Name= $filename,
Cwd = dirname($filename),
ENV = \%env,
Result = \$data,
Error = \$error
})) {
send_errorpage($r, 'Error on evaluating script from P-code',
$error);
$nFail++;
return OK;
}
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 19, 2003 12:05 AM
To:
Cc: [EMAIL PROTECTED]
Subject: Re: Need help, Global Hash corruption under mod_perl
in perl 5.8.0!?!
On Fri, 2003-07-18 at 09:03, wrote:
I used Apache::ePerl ( http://www.ossp.org/pkg/tool/eperl/
http://www.ossp.org/pkg/tool/eperl/ ) for a long time (up to perl
5.6.1)
until our admin install perl 5.8.0 and recompiled apache
and mod_perl
with it.
After that global hash $Cache where all precompiled eperl
scripts kept
in becomes corrupted
(even under httpd -X) after several calls
Sounds like a bug in Apache::ePerl.
I'm afraid you'll find that ePerl isn't really being
RE: Need help, Global Hash corruption under mod_perl in perl 5.8.0!?!
I have done code deparsing of eperl scripts saved in Cache all started with package Parse::ePerl; use strict 'refs'; print(qq[?xml version=1.0?\n]); so they all have the same package name. Can it cause a bug? Ap::Registry keeps different package name for every script.. -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2003 12:05 AM To: Cc: [EMAIL PROTECTED] Subject: Re: Need help, Global Hash corruption under mod_perl in perl 5.8.0!?! On Fri, 2003-07-18 at 09:03, wrote: I used Apache::ePerl ( http://www.ossp.org/pkg/tool/eperl/ http://www.ossp.org/pkg/tool/eperl/ ) for a long time (up to perl 5.6.1) until our admin install perl 5.8.0 and recompiled apache and mod_perl with it. After that global hash $Cache where all precompiled eperl scripts kept in becomes corrupted (even under httpd -X) after several calls Sounds like a bug in Apache::ePerl. I'm afraid you'll find that ePerl isn't really being supported by anyone at this point. The last release was something like 5 years ago. I'd suggest that you consider moving your code to one of the other templating systems available. Meanwhile, you can try to debug Apache::ePerl with the usual methods. Your admin did recompile ePerl with the new version of perl as well, didn't he? And you are running mod_perl 1.x without threads? - Perrin
RE: Need help, Global Hash corruption under mod_perl in perl5.8.0!?!
On Mon, 2003-07-21 at 02:51, wrote: I have done code deparsing of eperl scripts saved in Cache all started with package Parse::ePerl; use strict 'refs'; print(qq[?xml version=1.0?\n]); so they all have the same package name. Can it cause a bug? Ap::Registry keeps different package name for every script.. It means that all globals and subs are shared between all of your scripts. It could cause a bug if you use the same names for globals or subs in multiple scripts. - Perrin
RE: Need help, Global Hash corruption under mod_perl in perl5.8.0!?!
On Mon, 2003-07-21 at 02:41, wrote: I'm using only Apache::ePerl which allows me use Perl in the the way like PHP, since I don't need Mason or EmbPerl html features for small WAP resources. I think you should consider using a system that is actually supported. Embperl, Apache::ASP, Text::Template, and Mason all have similar syntax to ePerl. There are lots of other things on CPAN that might be even closer in syntax, but are not as widely used and well supported. I just can't understand where the Apache::ePerl bug can be -- it so simple and so clear module.. and it worked on older perl! You should go through the change log for Perl 5.8 then, since something that changed between 5.6 and 5.8 must be causing problems for you. where is all community? it's so silent in the conference. what the language perl programmers migrated to? JSP, PHP? :( Are you asking why more people aren't responding to your question? Probably because almost no one uses ePerl any more. - Perrin
Need help, Global Hash corruption under mod_perl in perl 5.8.0 !?!
Hi, I used Apache::ePerl ( http://www.ossp.org/pkg/tool/eperl/ http://www.ossp.org/pkg/tool/eperl/ ) for a long time (up to perl 5.6.1) until our admin install perl 5.8.0 and recompiled apache and mod_perl with it. After that global hash $Cache where all precompiled eperl scripts kept in becomes corrupted (even under httpd -X) after several calls: 1 req: http://www.server.com/w/love_text/main.pwml http://www.server.com/w/love_text/main.pwml 2 req: http://www.server.com/w/code/main.pwml http://www.server.com/w/code/main.pwml 3 req: http://www.server.com/w/gift/main.pwml http://www.server.com/w/gift/main.pwml all scripts are different. After third call all become unpredictable: calling http://www.server.com/w/gift/main.pwml http://www.server.com/w/gift/main.pwml invokes code/main.pwml and other called script randomly! switching off the Cache (recompiling script ) helps the problem all become corect, but what can corruct has so strange? the same files works ok under mod_perl with perl 5.6.1... -vlad
Re: Need help, Global Hash corruption under mod_perl in perl 5.8.0!?!
On Fri, 2003-07-18 at 09:03, wrote: I used Apache::ePerl ( http://www.ossp.org/pkg/tool/eperl/ http://www.ossp.org/pkg/tool/eperl/ ) for a long time (up to perl 5.6.1) until our admin install perl 5.8.0 and recompiled apache and mod_perl with it. After that global hash $Cache where all precompiled eperl scripts kept in becomes corrupted (even under httpd -X) after several calls Sounds like a bug in Apache::ePerl. I'm afraid you'll find that ePerl isn't really being supported by anyone at this point. The last release was something like 5 years ago. I'd suggest that you consider moving your code to one of the other templating systems available. Meanwhile, you can try to debug Apache::ePerl with the usual methods. Your admin did recompile ePerl with the new version of perl as well, didn't he? And you are running mod_perl 1.x without threads? - Perrin
Help me understand mod_perl and Environment settings
Hello!
I just startet learning mod_perl and apache. I use the current version of
mod_perl 1 and apache 1.3. Perl itself has version 6.5.1.
My aim ist to set some environment variables visible to all apache/perl
children (as far as I unsterstand there is one perl instance for each apache
child), but my testapplication does sometimes see my environment settings and
sometimes not. It changes if I press the refresh button of the browser.
According to mod_perl Developerls Cookbook I createt a script called
envteststartup.pl:
1 #!/usr/bin/env perl
2
3 BEGIN{
4 $ENV{ORACLE_HOME}=/opt/oracle/product/9.2.0;
5 $ENV{ORACLE_SID}=i001;
6 $ENV{ORACLE_TERM}=xterm;
7 $ENV{NLS_LANG}=AMERICAN_AMERICA.WE8ISO8859P1;
8
$ENV{ORA_NLS33}=/opt/oracle/product/9.2.0/ocommon/nls/admin/data;
9 $ENV{NLS_TIMESTAMP_FORMAT}=-MM-DD HH24:MI:SS.FF;
10 $ENV{NLS_TIMESTAMP_TZ_FORMAT}=-MM-DD HH24:MI:SS.FF TZR;
11 $ENV{NLS_DATE_FORMAT}=-MM-DD;
12 $ENV{NLS_NUMERIC_CHARACTERS}=,.;
13 $ENV{TNS_ADMIN}=/opt/oracle/product/9.2.0/network/admin;
14
15 $ENV{INFORMIXDIR}=/opt/informix;
16 $ENV{INFORMIXSERVER}=onltuxtcp;
17 $ENV{DBDATE}=Y4MD-;
18 $ENV{DBCENTURY}=C;
19
20 $ENV{BETLOGDIR}=/usr/local/apache/logs;
21 $ENV{BETYUCDB}=yucatan_test1;
22 $ENV{BETYUCDBTYP}=informix;
23 $ENV{BETLOGIN}=login;
24
25 $ENV{SESSIONDIR}=/usr/local/apache/sessions;
26 $ENV{SESSIONLOCKDIR}=/usr/local/apache/sessions/lock;
27 }
28
29 use lib qw(/usr/local/apache/modperlappl);
30 use lib qw(/usr/local/apache);
31
32 use strict;
33 use warnings;
34 use Apache::DBI;
35 use DBI;
36 use Apache::Session;
37 use Apache::Session::File;
38 use Apache::Request;
39 use Apache::URI;
40 use Apache::Log;
41
42 use envtest::handler;
43
44 1;
My http.conf has the following mod_perl entries:
338 PerlRequire conf/envteststartup.pl
339
340 Alias /envtest/ /usr/local/apache/modperlappl/envtest/
341 Location /envtest/
342 SetHandler perl-script
343 PerlHandler envtest::handler
344 /Location
My testapplication is as simple as can be:
1 package envtest::handler;
2
3 sub handler {
4 my $r=Apache::Request-instance(shift());
5
6 $r-send_http_header('text/plain');
7
8 print Environment:\n;
9
10 while ( my ( $key, $value ) = each %ENV ) {
11 print $key: $value\n;
12 }
13
14 }
15
16 1;
I assume not all perl instances get my environment settings but where is the
error causing me headache?
Regards,
Bernhard Donaubauer
Re: Help me understand mod_perl and Environment settings
Hello Bernhard Donaubauer,
Thursday, July 17, 2003, 5:34:57 PM, you wrote:
BD Hello!
BD I just startet learning mod_perl and apache. I use the current version of
BD mod_perl 1 and apache 1.3. Perl itself has version 6.5.1.
BD My aim ist to set some environment variables visible to all apache/perl
BD children (as far as I unsterstand there is one perl instance for each apache
BD child), but my testapplication does sometimes see my environment settings and
BD sometimes not. It changes if I press the refresh button of the browser.
http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t
BD According to mod_perl Developerls Cookbook I createt a script called
BD envteststartup.pl:
BD 1 #!/usr/bin/env perl
BD 2
BD 3 BEGIN{
BD 4 $ENV{ORACLE_HOME}=/opt/oracle/product/9.2.0;
BD 5 $ENV{ORACLE_SID}=i001;
BD 6 $ENV{ORACLE_TERM}=xterm;
BD 7 $ENV{NLS_LANG}=AMERICAN_AMERICA.WE8ISO8859P1;
http://perl.apache.org/docs/1.0/guide/porting.html#BEGIN_blocks
BD 8
BD $ENV{ORA_NLS33}=/opt/oracle/product/9.2.0/ocommon/nls/admin/data;
BD 9 $ENV{NLS_TIMESTAMP_FORMAT}=-MM-DD HH24:MI:SS.FF;
BD 10 $ENV{NLS_TIMESTAMP_TZ_FORMAT}=-MM-DD HH24:MI:SS.FF TZR;
BD 11 $ENV{NLS_DATE_FORMAT}=-MM-DD;
BD 12 $ENV{NLS_NUMERIC_CHARACTERS}=,.;
BD 13 $ENV{TNS_ADMIN}=/opt/oracle/product/9.2.0/network/admin;
BD 14
BD 15 $ENV{INFORMIXDIR}=/opt/informix;
BD 16 $ENV{INFORMIXSERVER}=onltuxtcp;
BD 17 $ENV{DBDATE}=Y4MD-;
BD 18 $ENV{DBCENTURY}=C;
BD 19
BD 20 $ENV{BETLOGDIR}=/usr/local/apache/logs;
BD 21 $ENV{BETYUCDB}=yucatan_test1;
BD 22 $ENV{BETYUCDBTYP}=informix;
BD 23 $ENV{BETLOGIN}=login;
BD 24
BD 25 $ENV{SESSIONDIR}=/usr/local/apache/sessions;
BD 26 $ENV{SESSIONLOCKDIR}=/usr/local/apache/sessions/lock;
BD 27 }
BD 28
BD 29 use lib qw(/usr/local/apache/modperlappl);
BD 30 use lib qw(/usr/local/apache);
BD 31
BD 32 use strict;
BD 33 use warnings;
BD 34 use Apache::DBI;
BD 35 use DBI;
BD 36 use Apache::Session;
BD 37 use Apache::Session::File;
BD 38 use Apache::Request;
BD 39 use Apache::URI;
BD 40 use Apache::Log;
BD 41
BD 42 use envtest::handler;
BD 43
BD 44 1;
BD My http.conf has the following mod_perl entries:
BD 338 PerlRequire conf/envteststartup.pl
BD 339
BD 340 Alias /envtest/ /usr/local/apache/modperlappl/envtest/
BD 341 Location /envtest/
BD 342 SetHandler perl-script
BD 343 PerlHandler envtest::handler
BD 344 /Location
BD My testapplication is as simple as can be:
BD 1 package envtest::handler;
BD 2
BD 3 sub handler {
BD 4 my $r=Apache::Request-instance(shift());
BD 5
BD 6 $r-send_http_header('text/plain');
BD 7
BD 8 print Environment:\n;
BD 9
BD 10 while ( my ( $key, $value ) = each %ENV ) {
BD 11 print $key: $value\n;
BD 12 }
BD 13
BD 14 }
BD 15
BD 16 1;
BD I assume not all perl instances get my environment settings but where is the
BD error causing me headache?
BD Regards,
BD Bernhard Donaubauer
Also see
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetVar_and_PerlAddVar
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetupEnv
Hope this will help.
--
WBR, Mike P. Mikhailov
mailto: [EMAIL PROTECTED]
ICQ:280990142
Re: Help me understand mod_perl and Environment settings
Hi there, On Thu, 17 Jul 2003, Bernhard Donaubauer wrote: I just startet learning mod_perl and apache. I use the current version of mod_perl 1 and apache 1.3. Perl itself has version 6.5.1. Can you be a little more careful with your version numbers in future? but my testapplication does sometimes see my environment settings and sometimes not. It changes if I press the refresh button of the browser. Please see the mod_perl Guide at http://perl.apache.org There are references to the symptoms you see at http://perl.apache.org/docs/1.0/guide/debug.html#Sometimes_My_Script_Works__Sometimes_It_Does_Not 73, Ged.
Re: Apache config problem .. please help
Anyway, all this started from an attempt to access env. vars from legacy scripts running under registry. What is the easiest way to get env. var access without the accompanying performance penalty that mod_perl documentation talks about? If you need to have your scripts run unmodified, have PerlSetupEnv Off in all sections that you don't need to access the CGI env vars, and have it On only in those Locations that run legacy scripts. http://perl.apache.org/search/swish.cgi?query=PerlSetupEnvsbm=SecEsubmit=search __ 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: AuthenNTLM - Help
Francisco de Assis Tristão wrote: Frank, please, i am trying to configure AuthenNTLM on a solaris 2.8 (SPARC) machine. But i did not find any sample about how to configure httpd.conf. May you help me? I had compiled apache 2 version 2.0.46 with ssl suport (i am configuring it with mod_jk and Tomcat too). Do i need to have mod_perl installed? You certainly need to have mod_perl installed. This and other questions are answered at http://perl.apache.org/. However I'm not sure whether this module has been ported to mod_perl 2.0. Therefore you probably need to either port it, or use mod_perl 1.0, in case it wasn't ported yet. __ 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: AuthenNTLM - Help
Stas Bekman wrote: Francisco de Assis Tristão wrote: Frank, please, i am trying to configure AuthenNTLM on a solaris 2.8 (SPARC) machine. But i did not find any sample about how to configure httpd.conf. May you help me? I had compiled apache 2 version 2.0.46 with ssl suport (i am configuring it with mod_jk and Tomcat too). Do i need to have mod_perl installed? You certainly need to have mod_perl installed. This and other questions are answered at http://perl.apache.org/. However I'm not sure whether this module has been ported to mod_perl 2.0. Therefore you probably need to either port it, or use mod_perl 1.0, in case it wasn't ported yet. __ 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 I am in the process of porting it now. Will hopefully have a working version in the next couple of days. Francisco, check out the documentation using perldoc: perldoc Apache::AuthenNTLM There is an example for the httpd.conf configuration in there. I'll keep you posted on the port, and will announce when and where I have a working version. The author is only excepting patches for the mod, so will probably take a little time for him to get my changes implemented into the indexed version. (Will also keep you posted on that... :) ) speeves cws
AuthenNTLM - Help
Frank, please, i am trying to configure AuthenNTLM on a solaris 2.8 (SPARC) machine. But i did not find any sample about how to configure httpd.conf. May you help me? I had compiled apache 2 version 2.0.46 with ssl suport (i am configuring it with mod_jk and Tomcat too). Do i need to have mod_perl installed? Thanks. -- Francisco de Assis Tristão Analista de Suporte - Usina da Pedra Fone: 16-3987-9044
Re: 'PerlSetVar' error, please help
--- Dead Line [EMAIL PROTECTED] wrote: Hello Everyone, Im on FreeBSD 4.8R Fresh installation, I have apache-fp, installed and running, I installed p5-Apache-ASP-2.51 from /ports collection, installation was ../www/.htaccess: Invalid command 'PerlSetVar', perhaps mis-spelled or defined by a module not included in the server configuration I don't know what's Apache-ASP - never used it. However, the above error message means u've not enabled mod_perl. If your httpd binary is statically built, then httpd -l should show you an entry for mod_perl. Otherwise, make sure you have an AddModule for mod_perl.so in your httpd configuration. Sreeji Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
'PerlSetVar' error, please help
Hello Everyone, Im on FreeBSD 4.8R Fresh installation, I have apache-fp, installed and running, I installed p5-Apache-ASP-2.51 from /ports collection, installation was fine. I copied whats in ./site/eg to the www directry, as its informed in the website, also I did the AllowOverride All option But the Site is not working any more the Msg which come to the web site it says Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request And the Log Error file it says ../www/.htaccess: Invalid command 'PerlSetVar', perhaps mis-spelled or defined by a module not included in the server configuration What I should do please Advise? Beside when i make/make install all of these things and it seems to be fine, it should be enabled by defult int? no ASP or Perl logos to be apear on the website, only front page . Please when replay CC my email. Thank you much. marwan. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
--help
--help
Re: --help
On Wed, 9 Jul 2003, Alexander Prihodko wrote: --help Usage: [EMAIL PROTECTED] [-s topic] PROBLEM [DETAILS] Describe a PROBLEM, giving DETAILS, so that the members of the list can try to assist you. Example: Date: Wed, 01 Jan 1970 00:00:00 + From: D Ritchie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: won't build on new lab system Your ^*$*$ software won't compile on this PDP-11. I keep getting the error cowardly refusing to create an empty archive. What is *that* supposed to mean? Here's the full error dump: snipped And here's the software hardware I'm running: snipped Options: -p --post: [EMAIL PROTECTED] -S --subscribe : [EMAIL PROTECTED] -u --unsubscribe : [EMAIL PROTECTED] -h --help: [EMAIL PROTECTED] Please, try again :) -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/ reusability, n. A marketing priority overriding that of usability. See also OBJECT ORIENTEETING. -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995
Apache config problem .. please help
I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. Any clues?
Re: Apache config problem .. please help
I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. killall httpd then try it again :) Dennis
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Dennis Stout wrote: I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. killall httpd then try it again :) In other words there's an Apache still running when you're trying to start a second one which wants to listen on the same socket that the first Apache is already listening on. That isn't permitted. But you shouldn't be getting segmentation faults in that case so something else is probably wrong too. Did you build from source? Did you follow the instructions in the Guide? Linux? 1.3.27/1.27? DSO? Maybe you can post the information requested in the docs? 73, Ged.
