RE: Excellent article on Apache/mod_perl at eToys
At 09:14 AM 10/23/2001, Robert Koberg wrote: For comparions, a nice aspect of j2ee applications IMHO is the application server tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). What is stopping you from using both, if you want? It's generally quite tough to convince management that maintaining two sets of knowledge -- Java and Perl is cost effective. I suppose it depends on the size of the organization but consolidation of standards in an organization is an age-old thing (eg move all servers to NT, move everyone to Java, etc...) Whether this actually saves costs is a bit of an arguement probably not best for this mailing list. However, I would have to say that I feel like coding middleware in Java is easier and more standardized, and well documented. But I feel like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. YMMV. And I don't know that many organizations which will allow such a heterogeneous environment unless a vendor installs it as a turnkey solution and is willing to deal with all the support. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Excellent article on Apache/mod_perl at eToys
However, I would have to say that I feel like coding middleware in Java is easier and more standardized, and well documented. OK, so what are we missing? I feel like we're getting pretty close to standardisation of middleware development with environments like POE (which rocks, but is under-documented and still quite hard to grok), but maybe there's more we can do - and having people like yourself who cross the divide can only help if you give us more information :-) One thing I know is missing in the XML world is an equivalent to JAXP. Hopefully we'll put that right fairly soonish. I guess there's equivalent issues in the whole Perl middleware environment, but we don't really know what they are. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Newbie having problems
Hi
I am new to mod-perl and am trying to migrate some
pretty large image scripts I have written to mod-perl.
I am attempting first to ge them to run correctly
under.
Apache::PerlRum
The scripts run, but sometimes through server
errors.
I am getting the following errors.
[Tue Oct 23 06:57:27 2001] [error] PerlRun: `Not a CODE reference at
/home/usr1/digital/membersurl/perl/content_manager/handler.pl line 57.'
[Tue Oct 23 06:57:27 2001] [error] Can't locate object method "uri" via
package "Apache::PerlRun" at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 212.
Here is the code at line 57 in the script I have written handler.pl
assign_values(get_file("vars/variables.info"));
It calls these two subs to load
variables into the script.
#sub
get_file {my $file_name = shift;my @array;open (IFH, "$file_name")
|| error("Cannot open $file_name for get.","$!");@array =
IFH;close IFH;return @array;}sub
assign_values {my @array = @_;foreach (@array) {my $name =
"";my $value = "";chomp;($name, $value) =
split(/=/);$value =~ tr/+/ /;$value =~
s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;$value =~
s/!--(.|\n)*--//g;$VAR{$name} = $value;}return
1;}
I can't find out why I am getting these errors. I can
usually do an imediate refresh of the browser and the script will run
ok.
I am trying to get the scripts to run under
apache::perl.
Would it be easier to migrate straight over to
apache::registry?
Thanks
John michael
Re: Excellent article on Apache/mod_perl at eToys
is easier and more standardized, and well documented. But I feel like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to cheat. They won't put the business logic in the back-end if it takes twice as long. To me, the major issue in Perl vs Java is dynamic vs static typing. Building large scale systems in Perl is much like building them in Smalltalk or Lisp. It takes a certain mindset. The lack of compiled interfaces means you need much more discipline (e.g. unit testing). The payoff is big with Perl, because you can refactor more easily and quickly than in Java. The libraries aren't much an issue. A good example is SOAP. SOAP is middleware. It is standardized, documented, and the rest of it. You like it for connecting Perl to Java, but why can't it be the other way around? If it can be the other way around, why aren't Perl and Java equally adapted to building middleware applications? Rob
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote: Secondly, I've worked on a good-sized commerce site with mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end of the site involves several standalone perl programs running as daemons. What's even worse is; most of them have to sit in poll/wait loops waiting on message from external systems (such as pop3 servers, ccvs etc.) Why exactly is that a dirty secret? I've been thinking about writing one or two standalone poe daemons to handle interfacing with other systems, and it doesn't seem like such a bad idea. Code to talk to or listen to web clients can be in mod_perl, and code to talk to other systems can be outside. I've even thought about taking some of the database objects out of mod_perl, but am less sure about doing that. Is anyone else using independent perl processes in a web app, or have strong reasons not to?
When to use 'use' for accessing modules?
I have a modperl site that accesses a number of modules.
In my startup.pl I have:
#!/usr/bin/perl -w
use strict;
use lib('/path/to/my/installation'); # 'site' directory is here
use Apache::DBI;
use Apache::StatINC;
use site::customers;
use site::orders;
use site::products;
use site::base;
1;
None of the modules exports *any* symbols at all - all are called in
the form:
$product=site::products-new(23);
$product-get('price');
First question:
If site::products calls functions from site::customers, do I need
a 'use site::customers' in site::products, when I have already
done a 'use' in my startup.pl?
Second question:
site::products contains the line:
@ISA=('site::base');
so that methods from site::base can be overridden in site::products.
Do I need a 'use site::base' in site::products for this to work
correctly?
Third (unrelated) question.
Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
in httpd.conf?
---
Experience has shown that I *don't* need the 'use' statements anywhere
other than startup.pl - but I am not sure why, and would find some pointers
to a discussion of this very useful. I would also be interested to know that
if the 'use' statements *are* unnecessary, does including them add any extra
overhead of processing/memory??
Many thanks,
Chris Allen.
Re: When to use 'use' for accessing modules?
Chris Allen wrote:
If site::products calls functions from site::customers, do I need
a 'use site::customers' in site::products, when I have already
done a 'use' in my startup.pl?
No, but I always do. It's good documentation, to remind you that if you
ever ran this code outside of mod_perl it would be necessary to have
that 'use' in place.
site::products contains the line:
@ISA=('site::base');
so that methods from site::base can be overridden in site::products.
Do I need a 'use site::base' in site::products for this to work
correctly?
Only if site::base has not been loaded already, but I always do it
anyway, for the same reason as above.
Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
in httpd.conf?
Yes.
Experience has shown that I *don't* need the 'use' statements anywhere
other than startup.pl - but I am not sure why, and would find some pointers
to a discussion of this very useful.
You don't need them because the modules they would load are already loaded.
I would also be interested to know that
if the 'use' statements *are* unnecessary, does including them add any extra
overhead of processing/memory??
There is a very fast check that happens once when the module containing
the 'use' is called. It checks to see if the used module is already
loaded (i.e. if it is in %INC). It also calls the used module's export
function, unless you pass an empty list:
use Foo ();
You should avoid importing symbols all over the place, as explained in
the Guide, but otherwise there is no significant overhead from having
use statements all over the place.
- Perrin
Re: Excellent article on Apache/mod_perl at eToys
Matt Sergeant wrote: OK, so what are we missing? Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. - Perrin
Re: Excellent article on Apache/mod_perl at eToys
Perrin Harkins sent the following bits through the ether: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... Byte this (designer underware)
Re: Excellent article on Apache/mod_perl at eToys
At 08:46 PM 10/23/2001, Rob Nagler wrote: is easier and more standardized, and well documented. But I feel like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to cheat. They won't put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. To me, the major issue in Perl vs Java is dynamic vs static typing. Building large scale systems in Perl is much like building them in Smalltalk or Lisp. It takes a certain mindset. The lack of compiled interfaces means you need much more discipline (e.g. unit testing). The payoff is big with Perl, because you can refactor more easily and quickly than in Java. I don't think refactoring in Perl is necessarily faster. Actually, it can be quite hard to refactor in Perl as well but for the opposite reason. If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party In practice, I still think using a good framework, it's about as long to develop in Perl as it is in Java for a medium sized system. My only beef I have with Java and I still have it is that the debugging support is simply atrocious for web apps. Perl has many more debugging utilities and allows much greater introspection. When I develop in Java, the only reason it takes me about 20% longer is that I am restarting the server much more often than I do in Perl. The libraries aren't much an issue. A good example is SOAP. SOAP is middleware. It is standardized, documented, and the rest of it. You like it for connecting Perl to Java, but why can't it be the other way around? If it can be the other way around, why aren't Perl and Java equally adapted to building middleware applications? Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. Arguably, an overuse of threads has problems in itself, but in general, I think it is easier. It is also easier to find programmers who know how to code middleware that do Java and harder to find people who have coded middleware that are Perl programmers... so maybe the language would support it, but there is also a personnel issue. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
At 09:45 PM 10/23/2001, Perrin Harkins wrote: Matt Sergeant wrote: OK, so what are we missing? Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about Enterprise applications is that there are many components to what enterprise means J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true standard so people feel comfortable that it is supported in a large community. Remember that my email said, I feel better about coding middleware in Java than in Perl. Just as I feel better about coding front-end in Perl. This is a feeling and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about soft issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. Later, Gunther
[OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
Is anyone else using independent perl processes in a web app, or have strong reasons not to? Our web application (Metadot) provides a number of functions that are fulfilled by a daemon written in perl. Among these are: collecting content from syndicated news channels, sending email messages to users about newly added content, retrieving email messages to add to site content, monitoring and cleaning database tables, etc. We run this daemon as a cron job every twenty minutes, and within it we have sections for tasks that are performed at hourly, daily and weekly intervals. The script is a bit messy but could still serve as a skeleton for similar ones for other applications. It's called metadotd.pl and is part of our open source distribution available from Metadot.net. Regards, Claudio
Re: Excellent article on Apache/mod_perl at eToys
At 10:36 PM 10/23/2001, Leon Brocard wrote: Perrin Harkins sent the following bits through the ether: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... One thing that would be interesting to me is an engine that can provide real time pricing feeds. It seems to me that jabber (chat engine) is actually a lot more powerful than being about chatting. Some applications are lonely and want instant messaging too. :) Queuing is important but for different reasons and usually different applications eg if your circuits are global. eg a London broker makes a transaction destined for Singapore, but has to go via Hong Kong and the London/HongKong circuit is only up every 5 minutes... Although this is not dissimilar to the resilience of a message delivered via SMTP relays.
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
-- [EMAIL PROTECTED] on 10/23/01 10:23:18 -0500 Is anyone else using independent perl processes in a web app, or have strong reasons not to? I use them for quite a few things. fork/exec works nicely in perl (on unix at least), allows me to write daemons for most things. Why do you ask? sl
Re: @INC
Plows, Sean (London) wrote: How can I set this as my cgi's can't locate my libs? Regards, Sean Plows Sean - try use lib '/path/to/my/libs'; That should append your library path to @INC. Word on the street is that you NEVER EVER want to mess with @INC directly. Jon Robison !Uniphied Thought, LLC
RE: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 20:14, Robert Koberg wrote: For comparions, a nice aspect of j2ee applications IMHO is the application server tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). What is stopping you from using both, if you want? Actually, I already do -- but not at the same time. The criteria I personally use is basically this: if the task doesn't involve more than one or two disparate system to be talked to, and a two tier model (apache and a rdbms for example) fits the problem well, then I'll chose Perl (mod_perl, Mason and *sometimes* ORBit's Perl bindings). If the app is to talk to a number of disparate systems and a variety of client types (stand alone app, web, wireless etc.) then generally I'll use the a J2EE app server etc. Of course there are will be exceptions. ORBit is a corba orb, BTW. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: It sounds like the limitation there is that you're interfacing with systems that can't notify you when something new happens. That's not Perl's fault. If you wrote your daemons in Java alpahabet soup, they'd still have to poll the pop3 server. Well, I'd more likely be using a standard javamail API within the context of a EJB server. There is a fairly rich set of call backs there which mean I generally don't have to poll/sleep etc. Also true of the java message service. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
Leon Brocard writes: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... I like the idea of P2EE. If the goal is to provide the same features as Java, why not just implement the Java messaging, transactions, etc. APIs in Perl? That is, endeavour to have the same classes and methods as Java, to the greatest extent possible. That'll also make it possible for Java programmers to become Perl programmers, bwahaha. Someone described Java beans to me as being more or less classes that follow conventions on things like accessor names and methods to respond to events. Those conventions permit introspection and interoperability between two classes that have no a priori knowledge of each other. I like that idea, too. It'd be fun to see what kinds of UI (both GUI and web) things become easier with this kind of functionality. Of course, we couldn't call it a Java bean. They'd have to be Camel droppings. :-) Nat
[OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 11:27 PM 10/23/2001 +0800, Gunther Birznieks wrote: At 09:45 PM 10/23/2001, Perrin Harkins wrote: Matt Sergeant wrote: OK, so what are we missing? ... Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. ... I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. Hi, This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. Last time this came up, I was referred to three different mailing lists (also, see http://lists.perl.org/). However, none of the lists were interested in the P2EE problem (including the PerlSDK list). If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. Stephen
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_p
Is anyone else using independent perl processes in a web app, or have strong reasons not to? I use them for quite a few things. fork/exec works nicely in perl (on unix at least), allows me to write daemons for most things. Sure, our network is supported internally by a DNS daemon written entirely in perl which supports all standard TCP/UDP queries, frontended inside by an extensive web app interface and backended by a sql server to store the data. It does all the normal daemon stuff, forking and keeping track of it's kids, etc... What appears to be the primary NS's at our site actually query the inside DNS for their updates. Modifications to the NSDB via the web interface are pushed out to the primaries in real time within a few seconds. This has been running for several years, never even a hiccup. There are a multitude of other daemon and daemon like processes that support automatic updates for a variety of speciality web sites that reside on our servers. many of these processes are spread across multiple machines, each doing their little piece to complete the puzzle -- all written in perl for the stand-alones or mod_perl for the web apps. Michael [EMAIL PROTECTED]
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 10:09, Gunther Birznieks wrote: At 08:46 PM 10/23/2001, Rob Nagler wrote: I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to cheat. They won't put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. I agree. Basically there's front end business logic which defined the work flow of the client's end (web server/web browser etc). And then business logic in the middle tier. I've been using Apache/Jakarta Struts for the front end business stuff, a row of session beans (java speak for purely process related, not data related objects) behind the client to model work flow and then another row of entity beans (java speak for data object persistence) to get at a rdbms. This arrangement has worked well for me. This approach makes cheating code look immediately out-of-place, and just downright embarrassing :) Is there a Perl equivalent to Struts? Mason seems to come close if you keep yourself disciplined somewhat. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 23 Oct 2001, Nathan Torkington wrote: Of course, we couldn't call it a Java bean. They'd have to be Camel droppings. :-) Perl Jewels (Joules?) -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat
Re: Excellent article on Apache/mod_perl at eToys
At 10:11 AM 10/23/01 -0600, Nathan Torkington wrote: Leon Brocard writes: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... I like the idea of P2EE. If the goal is to provide the same features as Java, why not just implement the Java messaging, transactions, etc. APIs in Perl? That is, endeavour to have the same classes and methods as Java, to the greatest extent possible. That'll also make it possible for Java programmers to become Perl programmers, bwahaha. The servlet API has been mostly(?) translated into perl by Brian Moseley. The homepage is http://libservlet.sourceforge.net/ and it's available on CPAN. The docs look a little parse at the moment, but kudos to Brian for the work done so far! Now if only I could figure out a good test application to try it with... Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote: On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: It sounds like the limitation there is that you're interfacing with systems that can't notify you when something new happens. That's not Perl's fault. If you wrote your daemons in Java alpahabet soup, they'd still have to poll the pop3 server. Well, I'd more likely be using a standard javamail API within the context of a EJB server. There is a fairly rich set of call backs there which mean I generally don't have to poll/sleep etc. Also true of the java message service. I suppose the Java stuff does make it more obvious how to do that kind of thing. There are dozens of ways to have some perl code execute every time a message arrives at a mail server without polling (Mail::Filter, procmail, Perl pop3 server, maybe PerlMX, etc.), but there isn't any One True Perl Mail API. Pointing newbies in the right direction is the strength of standardized APIs, and it does seem to have helped Java gain acceptance. There are commercial JMS implementations that simply poll database tables, but most people don't seem to mind as long as that's all hidden behind the standard JMS API. So, maybe a version in Perl would be a useful thing. - Perrin
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
On Tuesday 23 October 2001 18:21, Stephen Adkins wrote: This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. FWIW, (given the fact that we're talking about talking about it, I guess it's the moment for more-or-less useless ideas) I'd prefer it not to be called p2ee. It sounds more like a copy thing, and copies aren't good. What about EnterPerl or something like that ? In any case, please create the specific list before we start discussing the name here ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Prediction is very difficult, especially of the future. -- Niels Bohr
Re: Excellent article on Apache/mod_perl at eToys
Nathan Torkington [EMAIL PROTECTED] writes: Leon Brocard writes: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... I like the idea of P2EE. If the goal is to provide the same features as Java, why not just implement the Java messaging, transactions, etc. APIs in Perl? That is, endeavour to have the same classes and methods as Java, to the greatest extent possible. That'll also make it possible for Java programmers to become Perl programmers, bwahaha. That's P5EE Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com All the Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Nathan, At 11:06 AM 10/23/2001 -0600, Nathan Torkington wrote: Stephen Adkins writes: If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? cvsweb. You can see what we've got at cvs.perl.org. I'll ask Ask to add the list and repository. Cheers; Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. - Perrin
RE: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
PEP! (Perl Enterprise Project)! I like it! Paul E Wilt Principal Software Engineer XanEdu, Inc. (division of Proquest Information and Learning) http://www.xanedu.com mailto:[EMAIL PROTECTED] 300 North Zeeb Rd Phone: (734) 302-6545 (800) 218-5971 x6545 Ann Arbor, MI 48106Fax: (734) 975-6440 -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 2:28 PM To: Stephen Adkins Cc: mod_perl List Subject: Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. - Perrin
Using non-response handler only
Just out of curiosity: are there any efficiency issues regarding using mod_perl for the exclusive use of a phase other than the response? In other words, if I want a script to do something other than return a static page from a file, are there advantages/disadvantages to using mod_perl over C? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Excellent article on Apache/mod_perl at eToys
Gunther wrote: If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. I don't think there's an objective view about this. I also think the it compiles, so it works attitude is dangerous. You don't know it works until your unit and acceptance tests pass. I've been in too many shops where the nightly build was the extent of the quality assurance program. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party To me, strongly vs weakly typed is less descriptive than statically vs dynamically typed. For example, Java is missing undef. It has NULL for pointers, but not undef for ints, chars, booleans, etc. Large systems often have unexpected initialization order problems which are not handled well by Java due to this missing feature. Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. It's important to define the problem space for this discussion. I think Perl is really good for information systems, be they enterprise or not. I probably wouldn't program a real-time system in Perl. I might program it in Java. Here's a strong statement: Threads have no place in information systems. The NYSE is run on Tandem boxes. Tandem's OS does not have threads. The NYSE can process over a billion stock transactions a day. The EJB spec says you can't fire off threads in a bean. I think there's a reason for the way these systems have been architected. Threads are a false economy for systems which have to scale. As some people have joked, Java is Sun's way of moving E10K servers. SMP doesn't scale. As soon as you outgrow your box, you are hosed. A shared memory cache doesn't work well over the wire. In my experience, the only way to build large scale systems is with stateless, single-threaded servers. Rob
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with ok with me messages or how about 'foo'? messages. Stephen
Re: Newbie having problems
Hi there, On Tue, 23 Oct 2001, John Michael wrote: I am new to mod-perl and am trying to migrate some pretty large image scripts I have written to mod-perl. Have you come upon the Guide? http://perl.apache.org/guide It's a fairly weighty document by now but most of what you want will be in there. Would it be easier to migrate straight over to apache::registry? It might be less trouble to start writing handlers. Apache::Registry can be intolerant. I take it you have use strict; in your scripts? 73, Ged.
Re: Using non-response handler only
Hi there, On Tue, 23 Oct 2001, Issac Goldstand wrote: Just out of curiosity: are there any efficiency issues regarding using mod_perl for the exclusive use of a phase other than the response? In other words, if I want a script to do something other than return a static page from a file, are there advantages/disadvantages to using mod_perl over C? Perl is good if you want to whip up an appetising dish in a jiffy. If you can do it in C, by all means do. It will likely be faster and use a LOT less resources on the machine. Ducks and runs for cover :) 73, Ged.
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 3:38 PM -0400 10/23/01, Stephen Adkins wrote: Several of you have made the same good point. And now the naming flame war has already begun... ;-) This is a discussion. Something has been proposed and it needs a name. I'd hardly call this a flame war. A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: Newbie having problems
I have seen and read through the guide, but will read through it again as
you have suggested.
I do have use stricts in my scripts.
I also get a lot of these things when I run it with the -w option.
;' called at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm
line 113
Apache::PerlRun::compile('Apache::PerlRun=HASH(0x8a44a5c)',
'SCALAR(0x885825c)') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 289
Apache::PerlRun::handler('Apache=SCALAR(0x8385200)', 137931400,
'Apache::PerlRun', 'Apache=SCALAR(0x8385200)') called at lib/file_ops.pl
line 82
require 0 called at lib/file_ops.pl line 82
Subroutine check_availability redefined at lib/file_ops.pl line 106.
require lib/file_ops.pl called at
/home/usr1/digital/membersurl/perl/content_manager/handler.pl line 28
require 0 called at
/home/usr1/digital/membersurl/perl/content_manager/handler.pl line 20
eval 'package
Apache::ROOTmembersurl_2ecom::perl::content_manager::handler_2epl;use Apache
qw(exit);
#line 1 /home/usr1/digital/membersurl/perl/content_manager/handler.pl
My error log will fill up fairly quick. I am also using:
Apache::exit()
with
use Apache qw(exit)
and this seems to be causing errors as well.
Thanks
JM
- Original Message -
From: Ged Haywood [EMAIL PROTECTED]
To: John Michael [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, October 23, 2001 3:07 PM
Subject: Re: Newbie having problems
Hi there,
On Tue, 23 Oct 2001, John Michael wrote:
I am new to mod-perl and am trying to migrate some pretty large
image scripts I have written to mod-perl.
Have you come upon the Guide?
http://perl.apache.org/guide
It's a fairly weighty document by now but most of what you want will
be in there.
Would it be easier to migrate straight over to apache::registry?
It might be less trouble to start writing handlers. Apache::Registry
can be intolerant. I take it you have use strict; in your scripts?
73,
Ged.
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Robert Landrum [EMAIL PROTECTED] wrote: ... A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. howsabout: p5ice ? Perl 5 Integrated Classes for the Enterprise or mebbe: Interface Client for Enterprises possibly: Insane Community of Entrepeneurs or even: Icky Commercialized Edition i can already see all the cool Ice-ey perl logos with icicles hanging from their frosted fonts :-) -dave
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
I'm surprised that no one has, jokingly, suggested PEE. Sorry, couldn't resist. :) -- === If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows. -- Sun Microsystems CEO, Scott McNealy __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
p5ee list active
The list's goal is to create the Perl 5 Enterprise Extensions. Send mail to [EMAIL PROTECTED] to join. When we've decided on a path and start to code, I'll have a CVS repository created. Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 03:38 AM 10/24/2001, Stephen Adkins wrote: At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with ok with me messages or how about 'foo'? messages. Stephen I think this name and mailing list is excellent and much better than P2EE. The mere fact that there is an endorsed perl.org mailing list for people who wish to ask about enterprise issues (even without a specific standard) is a huge step further in terms of making people aware that Perl CAN BE used for the enterprise. That is, there is a definite perception difference between [EMAIL PROTECTED] and [EMAIL PROTECTED] [EMAIL PROTECTED] has a perception of being endorsed as a place for a standard rather than just a single couple of people's ideas on sourceforge.com (of which there are thousands) and is likely to get more attention.
namespace-troubles
I run into deep namespacetroubles I understand onyl vaguely and I cant workaround:
I have a script running under mod_perl that is called via two domains.
www1.domain.at/
www2.domain.at/sub/
both of the above addresses lead to the very same script (its the same
file on the disk, not a copy). When I call the first adress all is
working fine, but as soon as I call the second adress I get a
server-error. Restarting apache and I try the second first: running
fine, but as soon as I call the first: server-error.
The log reveals:
Undefined subroutine Apache::ROOTwww1_2domain_2eat::main called at
/data/public/stage2/fetch.pl line 9.
or
Undefined subroutine
Apache::ROOTwww2_2edomain_2eat::editeinstieg::main called at
/data/public/stage2/fetch.pl line 9.
my script is structured like that:
fetch.pl:
require fetch.lib.pl
main();
-
---fetch.lib.pl:
sub main{
do everthing here
}
1;
As far I can see, the second call does not load the lib anymore, cause
it was already loaded on the first call. Unfortunately it was loaded
to a different namespace, so the script doesnt find it.
What can I do ? I need this different domains, cause the script-action
depends on the calling domain.
The reason why I splitted in script/lib is a document at apache.org
that recommends this to avoid a nested-sub-problem under mod_perl.
I wonder if providing the lib-file as module (use instead of require)
would be a solution, but I guess not. Can the above problem occure
with modules too ? If two scripts call the same module, is it only
loaded on the first call and the second script fails ??
thnx,
peter
--
mag. peter pilsl
phone: +43 676 3574035
fax : +43 676 3546512
email: [EMAIL PROTECTED]
sms : [EMAIL PROTECTED]
pgp-key available
RE: newbie having problems
I had a routine in the beginning of the program to
initialze my variable hash and query param like so:
## initialize
globals ##foreach (keys
%VAR){$VAR{$_} = "";}
I did this so that these variables would not
propogate to other instances of the script.
This was causing the error.
I removed it and added a this small
sub:
sub clean_up {undef
%VAR;Apache::exit();}
Is this the correct way to do this or even
necessary?
The Apache::exit() function is still causing an
error, but the script runs andworks but is evidently not exiting
gracefully.
I am running under apache::perl envir.
Also, I am running the script in an eval{ } block
in order to trap errors in the $@ variable.
IS this ok practice in mod-perl?
Thanks
JM
Somewhat relevant
Folks, if this looks like an off topic, my apologies in advance... I have written an accessing scheme that checks for the existence of couple of cookies and if not present, the user is rerouted to a login page. So far simple stuff. The problem is that my boss is saying that it should work with a CGI script or a PHP script (legacy codes that are too many to port to mod_perl today). The basic mechanism behind my script is returning an error constant 403 in case the cookies are missing. Now, PHP, according to my boss, is very similar to a CGI script, so how does one throw an error (of any kind) that would cause Apache to generate its famous error page from a CGI program? Thanks in advance... -r
Re: When to use 'use' for accessing modules?
Perrin Harkins wrote:
Chris Allen wrote:
[...]
Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
in httpd.conf?
Yes.
Are you sure? I experimented a few months ago, and found that
$ENV{foo}='bar'; would only last in each child until the first request
of the child completed.
Steve
--
Steve Piner
Web Applications Developer
Marketview Limited
http://www.marketview.co.nz
cvs commit: modperl-site index.html
ged 01/10/23 13:09:56 Modified:.index.html index.html Added link to email-etiquette.html -- Log: Revision ChangesPath 1.92 +2 -1 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- index.html2001/10/16 16:08:34 1.91 +++ index.html2001/10/23 20:09:55 1.92 @@ -461,7 +461,8 @@ pa name=users-list/a The bmod_perl users mailing list/b is available for mod_perl users and developers to share ideas, solve problems and discuss - things related to mod_perl and the CODEApache::*/CODE modules. + things related to mod_perl and the CODEApache::*/CODE modules. Please read + the mailing list a href=email-etiquette.htmlGuidelines/a before posting. br /p 1.92 +2 -1 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- index.html2001/10/16 16:08:34 1.91 +++ index.html2001/10/23 20:09:55 1.92 @@ -461,7 +461,8 @@ pa name=users-list/a The bmod_perl users mailing list/b is available for mod_perl users and developers to share ideas, solve problems and discuss - things related to mod_perl and the CODEApache::*/CODE modules. + things related to mod_perl and the CODEApache::*/CODE modules. Please read + the mailing list a href=email-etiquette.htmlGuidelines/a before posting. br /p No revision No revision No revision 1.1 modperl-site/email-etiquette.html Index: email-etiquette.html === HTML HEAD TITLEThe mod_perl Mailing List Guidelines/TITLE LINK REV=made HREF=mailto:[EMAIL PROTECTED]; /HEAD BODY !-- INDEX BEGIN -- UL LIA HREF=#The_mod_perl_Mailing_List_GuidelThe mod_perl Mailing List Guidelines/A LIA HREF=#What_is_mod_perl_What is mod_perl?/A LIA HREF=#What_you_need_to_know_to_be_ableWhat you need to know to be able to use mod_perl/A LIA HREF=#How_To_Get_Help_With_mod_perl_ItHow To Get Help With mod_perl Itself/A UL LIA HREF=#Documentation_which_comes_with_tDocumentation which comes with the distribution/A LIA HREF=#Other_documentationOther documentation/A /UL LIA HREF=#How_to_get_on_and_off_the_modHow to get on (and off!) the mod_perl mailing list/A UL LIA HREF=#To_Get_On_The_ListTo Get On The List/A LIA HREF=#To_Get_Off_The_ListTo Get Off The List/A /UL LIA HREF=#To_post_to_the_ListTo post to the List/A UL LIA HREF=#Private_MailPrivate Mail/A LIA HREF=#Other_TipsOther Tips/A UL LIA HREF=#Read_The_DocumentationRead The Documentation/A LIA HREF=#Give_Full_InformationGive Full Information/A LIA HREF=#Error_MessagesError Messages/A LIA HREF=#The_Subject_LineThe Subject Line/A LIA HREF=#Preserve_The_ThreadsPreserve The Threads/A LIA HREF=#Post_in_PLAIN_TEXTPost in PLAIN TEXT/A LIA HREF=#Time_and_BandwidthTime and Bandwidth/A LIA HREF=#TagsTags/A LIA HREF=#If_You_Don_t_Get_a_ReplyIf You Don't Get a Reply/A LIA HREF=#If_You_Don_t_Understand_a_ReplyIf You Don't Understand a Reply/A LIA HREF=#General_Perl_and_Apache_questionGeneral Perl and Apache questions/A /UL /UL LIA HREF=#Replying_to_postsReplying to posts/A UL LIA HREF=#The_Subject_lineThe quot;Subject:quot; line/A LIA HREF=#Extracts_From_Other_PostsExtracts From Other Posts/A LIA HREF=#Unnecessary_DuplicationUnnecessary Duplication/A LIA HREF=#Private_repliesPrivate replies/A LIA HREF=#FlamesFlames/A /UL LIA HREF=#The_mod_perl_GuideThe mod_perl Guide/A UL LIA HREF=#Finding_the_GuideFinding the Guide/A LIA HREF=#Corrections_And_ContributionsCorrections And Contributions/A /UL /UL !-- INDEX
