Re: Apache::compat was Apache::DBI with mod_perl 2.0
Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Sorry if I'm just not getting it... -Zac using Apache/2.0.40-dev (prefork MPM) [Thu Jun 27 03:43:52 2002] [info] 20 Apache:: modules loaded [Thu Jun 27 03:43:52 2002] [info] 5 APR:: modules loaded [Thu Jun 27 03:43:52 2002] [info] base server + 5 vhosts ready to run tests [Thu Jun 27 03:43:54 2002] [info] 19 Apache:: modules loaded [Thu Jun 27 03:43:54 2002] [info] 5 APR:: modules loaded [Thu Jun 27 03:43:54 2002] [info] base server + 5 vhosts ready to run tests waiting for server to start: ok (waited 10 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (TestDirective::perlmodule) server localhost.localdomain:8531 listening (TestDirective::perlrequire) server localhost.localdomain:8532 listening (TestProtocol::echo) server localhost.localdomain:8533 listening (TestProtocol::echo_filter) server localhost.localdomain:8534 listening (TestFilter::input_msg) apache/cgihandlerok apache/compatok apache/compat2...ok apache/conftree..ok apache/constants.ok apache/post..ok apache/read..ok apache/scanhdrs..ok apache/subprocessok apache/write.ok api/access...ok api/aplogok api/conn_rec.ok api/lookup_uri...ok api/lookup_uri2..ok api/module...ok api/r_subclass...ok api/request_rec..ok api/response.ok api/rutilok api/send_fd..ok 2/3# Failed test 3 in api/send_fd.t at line 23 api/send_fd..FAILED test 3 Failed 1/3 tests, 66.67% okay api/sendfile.ok 2/3# Failed test 3 in api/sendfile.t at line 23 api/sendfile.FAILED test 3 Failed 1/3 tests, 66.67% okay api/server_rec...ok api/server_util..ok api/uri..ok apr/base64...ok apr/constantsok apr/date.ok apr/netlib...ok apr/os...ok apr/perlio...skipped all skipped: no reason given apr/pool.ok apr/string...ok apr/tableok apr/util.ok apr/uuid.ok directive/envok directive/perlmodule.ok directive/perlrequireok directive/setupenv...ok filter/api...ok filter/buckets...ok filter/input_bodyok filter/input_msg.ok filter/lcok filter/reverse...ok hooks/access.NOK 2# Failed test 2 in hooks/access.t at line 15 hooks/access.FAILED test 2 Failed 1/4 tests, 75.00% okay hooks/authen.ok 1/4# Failed test 2 in /opt2/src/mod_perl-1.99_04/Apache-Test/lib/Apache/Test.pm at line 46 fail #2 hooks/authen.NOK 2# Failed test 3 in /opt2/src/mod_perl-1.99_04/Apache-Test/lib/Apache/Test.pm at line 46 fail #3 hooks/authen.FAILED tests 2-3 Failed 2/4 tests, 50.00% okay hooks/authz..NOK 2# Failed test 2 in hooks/authz.t at line 15 # Failed test 3 in hooks/authz.t at line 17 hooks/authz..FAILED tests 2-3 Failed 2/4 tests, 50.00% okay hooks/fixup..ok hooks/headerparser...ok hooks/init...ok hooks/trans..# Failed test 1 in hooks/trans.t at line 12 hooks/trans..FAILED test 1 Failed 1/3 tests, 66.67% okay modperl/dir_config...ok modperl/endavok modperl/env..ok modperl/exit.ok modperl/getc.ok modperl/method...ok modperl/methodname...ok modperl/methodobjok modperl/pnotes...ok modperl/printok modperl/printf...ok modperl/readline.ok modperl/sameinterp...ok modperl/subenv...ok modules/cgi..ok modules/cgiuploadok modules/include..ok protocol/echook protocol/echo_filter.ok Failed TestStat Wstat Total Fail Failed List of Failed --- api/send_fd.t 31 33.33% 3 api/sendfile.t31 33.33% 3 hooks/access.t41 25.00% 2 hooks/authen.t42 50.00% 2-3 hooks/authz.t 42 50.00% 2-3 hooks/trans.t 31 33.33% 1 1 test skipped. *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 2:33 AM Subject: Re: Apache::compat was Apache::DBI with mod_perl 2.0 errors: using Apache/2.0.36 (prefork MPM) because you must use 2.0.39
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Ok, I understand. Maybe some kind of message/logic in the make to tell you that you have to have specifically x, y, z. Because I honestly DID hear you say x, y, z but my brain assumed x+, y+, z+ Just a thought. Thanks, -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: mod_perl [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 6:08 AM Subject: Re: Apache::compat was Apache::DBI with mod_perl 2.0 Zac Morris wrote: Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Yes, to compile 1.99_04 Sorry if I'm just not getting it... It's easy: * httpd is changing all the time * Perl is changing too * mod_perl uses both APIs and therefore depends on the above two in order to give you a version where mod_perl uses the right APIs from httpd and Perl, we say the versions that you've to use. Now if you go for the cvs versions, chances are that we didn't have a chance to update mod_perl to the latest cvs changes in httpd, perl or both. And this is the case that you hit. get 5.8.0-RC2 and 2.0.39 and then 1.99_04 will compile and pass all tests 100%. __ 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: Apache::DBI with mod_perl 2.0
Ok, still no luck. Every dependancy has more dependancies all of which go
back and back to mod_perl 1 stuff already being in place
My question is, can I download the Apache 1.3 source (don't make it), then
run the mod_perl 1 build to get all the pm files in place, then rebuild my
mod_perl 2 (against my installed Apache 2 source).
Also, we mentioned the whole Bundle::Apache, will there be one of those
for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to
allow running in Compat?
Thanks,
-Zac
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 12:26 PM
Subject: Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't
have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm 4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm 25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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: Apache::DBI with mod_perl 2.0
Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? Thanks, -Zac
Re: Apache::DBI with mod_perl 2.0
Ahhh, ok more clarity. :) Forgive me if I'm just not doing my detective work in poking around for documentation, but is there a doc that contains all the kludges or assumed modules I need to already have in place? I'm assuming that the bulk of these things are handled via a CPAN Apache::bundle install, and because mod_perl2 is still beta we don't have that in place yet? Thanks for all this info, learning more and more every day. :) -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 11:02 AM Subject: Re: Apache::DBI with mod_perl 2.0 Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
My point is still the same, and you both concede that the problem is ultimately your lack of management ability. The point I was trying to illustrate was that it's really not OK for you to just say, Yup, that's my limitation, so be it. In every way conceivable, that's wrong in that it goes against necessary Due Diligence in fulfilling your mission/vision, not to mention the negligence to your stock holders/investors... You wouldn't hire a PM who said, I don't know how to manage critical path, so I'm just going to need lots and lots of bodies and money to get this project done. What you're both saying equates to the same thing. I accept your points that there are going to be barriers to just picking any body to fill a position, but during the interview process you should establish skills, abilities, compatibility, and affordability. Whether that person ultimately sits in the cube next to you or in a home office on the other side of the planet shouldn't be one of the factors in deciding whom you'll hire IF they have the skills, abilities, compatibility, and you can afford them to get the job done. Any other consideration is just putting an arbitrary quota on the type of people you'll have in your organization. When we look back 20 years ago many things were considered ok to hire based upon (sex, race, sexual orientation, etc), and it won't be too long before location will be considered just as pejorative, and those organizations that see that trend NOW and train their managers and teams to work virtually are the organizations that are going to be successful tomorrow. This is all ESPECIALLY critical to small companies in the current market. Why would any one choose a small company (who might not be around tomorrow) as a provider *OR* client/employer, when they can have a giant who's at least got the best chance to be around? I'll tell you why, because those small companies that can show they can do something better, more efficient, more *NIMBLE* and *ADAPTABLE* those are going to be the companies that people are willing to take risks on. Now this might all seem a bit off topic to some for this list but I think it's very relevant. I say that because in supporting something like mod_perl, or even just PERL in general, we are all the type of people that say: Yes, we realize this is not the hottest buzz word technology, and Yes, we realize that *arbitrary* standards like MCSE and J2EE say that Perl doesn't have a place, but I think we all know that's just crap. We program in Perl because it is the absolute best suited solution to a huge variety of problems. But, as these people have wonderfully illustrated we live in a world of perceptions, expectations, and assumption that often have little or nothing to do with doing what's best. The only way that these non-buzz technologies are going to stay around, stay staffed, and stay viable is if we as developers have a market, and I think the days were we get hired by company A and work until retirement are long gone. This means we ALL need to learn to be adaptable, pragmatic, and focused on standard ways of getting jobs done, and challenge every old world philosophy that holds that back. -Zac - Original Message - From: Gunther Birznieks [EMAIL PROTECTED] To: Tom Mornini [EMAIL PROTECTED]; Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 21, 2002 11:36 PM Subject: Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted I agree with Tom but for different reasons. I would almost never accept a telecommuter I didn't know and that may even be if he or she came recommended. Everyone has different personalities and cultures and it takes time to really get to know how to effectively communicate with someone because everyone has different vocabulary even coming from the same country. And vice versa. Every person is an individual and it's really tough to find out the individual way someone needs to be managed over long distances. Face to face communication is the quickest most efficient way to learn how best to communicate (and hence manage) with most people and vice versa. eg You need to learn to read between the lines of how someone writes. One person's friendly sarcasm may be another person's insult. Without figuring these things out in person first, frictions can result at worst and usually at best, there will be inefficiency in communication (o, THAT'S what you meant...). We have accepted some of our employees telecommuting from the other side of the world but our best success has come from people who have been in our office physically for 3 months at minimum and then go back to where they came from to work. But people who we don't know their work habits... that is much more difficult to manage. For someone who wants to telecommute from the other side of the world, bringing them here for 3 months and housing them and then topping it up with long distance bills
Re: [JOB] Crack OOP Perl whitebox tester wanted
Old fashioned is right, and disregarding "telecommuters" is also extreemly short sighted and ultimaty limits your ability to providethe mostquality solution... I work for Cisco Systems in our RTP (NC) office. I work with two different groups, one based in San Jose and the other based in Ontario, as a "virtual team member" (what we call our telecommuter positions). I only bring all this up because I'm in exactly the role you've outlined here, and to be honest I don't think I would BE as successful as I am if I were located directly with either of these teams. The need to have everyone "all together" is usually indicative of a larger problem in team dynamics, and communications. It usually represents a team in which "charasmatic" leadership is more important than technical know how or ability to get a job done. Now don't get me wrong, for a person to BE a successful "virtual team member" they have to have great communication skills, and be open to working with others in multiple formats to enable the best level of teamwork and participation. With all this said, and based on my own personal experience in this role, I can tell you that what you're asking for here is a person to walk a VERY shape edge between the need to bring the best and brightest from people, without making it seem "personal". Actually having this role as an "outsider" to the day to day politics and interpersonal sabatoge of most bay area offices (yeah I lived there five years during the "boom") , gives a layer of abstraction that makes the job easier to perform. When someone is questioning things like style, or code effeciencyit comes across MUCH easier (more acadimic)when that person is a "talking head", an IM box,or a voice on the telephone. It becomes less "personalized" and easier to "pick and choose" the best componants into a greater whole. It also isolates the individual who may end up doing a lot of refactoring to present the final solution. Just something to consider. Open youself to the best people in the world and don't accept just the best you can find in your area, and you'll find that you solutions aren't also as limited... -Zac Morris - Original Message - From: Tom Mornini To: [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 11:30 PM Subject: [JOB] Crack OOP Perl whitebox tester wanted We're 1 year into development of a system that is OO Perl, mod_perl,DBI and DBD::Oracle on Linux.We've spent a lot of energy doing it right and writing tests as we go.This has given us huge benefits in the life of the project, but our currentwhitebox tester has decided to move to Washington, D.C. so we needsomebody to fill his large shoes.If you're a good Perl programmer who has a strong sense of "the way itshould be" and can be simultaneously mean, nasty, angry, distrustful andunforgiving to Perl code and the opposite to people then we'd like totalk to you.This person doesn't do new development, per se, but he is responsiblefor making things better via testing, fixing, documentation and refactoring.This is a full time job at an office in the South Park area of San Francisco,California, USA. Telecommuters are NOT what we have in mind. Call usold fashioned that way. :-)Pay and benefits are good, though it's no longer 1998. :-) Best benefitis working with a small group of people that are highly motivated bydoing it right.-- -- Tom Mornini-- eWingz Systems, Inc. ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini
Re: [ANNOUNCE] Apache::DBI 0.89
I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. Thanks! -Zac Morris http://www.zacwolf.com - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: Ask Bjoern Hansen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 21, 2002 12:03 PM Subject: Re: [ANNOUNCE] Apache::DBI 0.89 Perrin Harkins wrote: Ask Bjoern Hansen wrote: In the last almost 3 years only two bugs has been found. Edmund no longer has time to make releases and such, so I fixed the last bug and made a new release which is available on CPAN. Thanks for taking over maintenance on this. Any thoughts about how to add support for threading in perl 5.8/mod_perl 2 to this? It might be premature, since the DBI/DBD modules are not necessarilly thread safe. the preforked mpm will use the same old Apache::DBI the threaded mpms will need a new version/mode of Apache::DBI using threads::shared, currently available only for 5.8.0-tobe, unless things will get backported to 5.6.2. Currently it seems that the threaded mpms will be safe to use only with 5.8.0, unless again things will get backported. Otherwise chances are that 5.8.0 will be a requirement. Originally Doug was planning on Apache::DBIPool described in his 2.0 overview: http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Apache__ DBIPool but since we now have threads::shared it's not needed anymore. __ 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
