[mp2] Sections, Method handlers
Any indication of when/if these features will make it to mp2? I've been trying to get my RPC::XML code (specifically the Apache::RPC::Server and Apache::RPC::Status modules) to work under Apache2 and mod_perl2 (thanks to Red Hat for pushing up my timetable on this by installing those). Randy -- --- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
Re: Thoughts on Mason?
On 2002.10.24 15:13 Shannon Appelcline wrote: I see there's a new book coming out from O'Reilly on "mason", which seems to be perl integrated into web pages and claims to support mod_perl. http://www.masonbook.com/ Any thoughts on mason from this esteemed community? See http://use.perl.org/article.pl?sid=02/10/23/160240&mode=nested&tid=29 Links, comments, etc. Randy -- ----------- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
Re: Archive::Tar
Most of the replies have focused on how to do this with external calls to tar or cpio, without actually addressing the original writer's problem, how to do it with Archive::Tar. The first respondent noted that Archive::Tar doesn't do wildcarding. Or, as it is called in the Perl docs, globbing. What you need to do is create the file list yourself, and pass it to the call. There are a variety of ways you can do this: you can use the File::Find module to build up a list of files, or since you seem to be concerned with just the one directory you can use Perl's built-in globbing functionality with <*> (or with glob(), if you prefer). Look to the perlop manpage (under I/O Operators) for the <*> syntax, or perlfunc for glob(). Randy -- ----------- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
Re: AutoLoader bypass?
On 2002.08.19 14:47 Elizabeth Mattijsen wrote:
> At 02:37 PM 8/19/02 -0700, Randy J. Ray wrote:
> >> use AutoLoader 'preload'; # preload anything you can find in %INC
> >> use AutoLoader preload => { module => '' }; # all from specific module
> >> use AutoLoader preload => { module => [qw(suba subb)] }; # only specific
> >>Would that make sense?
> >Problem with that approach is that it doesn't offer any control over whether
> >you are pre-loading or not. If you are going to pre-load a certain sub-set
> of
> >routines all the time, just put them above the __END__ token and don't
> burden
> >AutoLoader with new functionality at all.
>
> Well, my C would be _outside_ any of the loaded modules in
> the mod_perl startup.pl script after all the modules necessary for proper
> execution of _your_ mod_perl environment, are loaded.
I see... you mean to have a line like this:
use AutoLoader preload => { module => [qw(suba subb)] };
be responsible for both including "module" (into the caller's namespace) *and*
pre-loading the specified routines? That's different that what I had
interpreted from your first idea. I though that the preload specification
would be when the target module issues its call to "use AutoLoader".
From this vantage point, it does make more sense, yes. Especially since
module authors would no be responsible for retro-fitting to their packages. I
would be interested to see if this can be done cleanly, without making
AutoLoader.pm any harder to read than it currently is :-).
(OK, that might be asking a bit much...)
Randy
--
---
Randy J. Ray | Men occasionally stumble over the truth, but most of them
[EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened.
+1 650 930-9097 | -- Sir Winston Churchill
Re: AutoLoader bypass?
On 2002.08.19 14:19 Elizabeth Mattijsen wrote:
> use AutoLoader 'preload'; # preload anything you can find in %INC
>
> use AutoLoader preload => { module => '' }; # all from specific module
>
> use AutoLoader preload => { module => [qw(suba subb)] }; # only specific
>
>
> Would that make sense?
Problem with that approach is that it doesn't offer any control over whether
you are pre-loading or not. If you are going to pre-load a certain sub-set of
routines all the time, just put them above the __END__ token and don't burden
AutoLoader with new functionality at all.
What I was suggesting was a way that I, as the writer of (picking one of my
own modules as an example) RPC::XML::Server can incorporate something in the
compile-time logic so that Apache::RPC::Server contains:
use RPC::XML::Server 'compile';
And RPC::XML::Server can have:
sub import {
AutoLoader::preload(__PACKAGE__, @list_o_routines)
if (lc $_[1] eq 'compile');
}
(Admittedly a simplistic example, but I hope it gets the point across)
This way, I only pre-load routines in the cases where I need it done. Your
suggestion is good for modules that are only ever used under mod_perl, but
modules may be designed to work in other environments. Oh, you could manage
to get the same affect as my idea using a BEGIN block and conditional calls
of "use AutoLoader", but the above seems to me to be much cleaner.
Randy
--
---
Randy J. Ray | Men occasionally stumble over the truth, but most of them
[EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened.
+1 650 930-9097 | -- Sir Winston Churchill
Re: AutoLoader bypass?
On 2002.08.19 13:53 Elizabeth Mattijsen wrote: > Because routines are loaded when they are requested, they may be loaded in > child processes, causing duplication in memory because they are not shared. > They would be shared if they would be loaded in the initialization phase > before the child processes are forked. But in that phase you wouldn't call > all of those routines that you might need in the child processes. I don't know of a module or "standardized" way of doing this, but the CGI module offers this to the user in the form of a "compile" directive in the imports list. It tells the module proper to pre-compile the specified list of routines, and (as I understand it) the functionality stemmed from the kind of situation you describe, where application developers wanted to ensure that load-on-demand functions be pre-loaded before forking. The problem I would anticipate would be in having a portable way of locating the code to load without having it executed. You could pull some functionality out of AutoLoader, but then you have code duplication. Or, an idea that just hit me, you could provide a call in the AutoLoader module that does the job for you. It would have access to all the logic already in the module, and module-writers could use it conditionally a la: AutoLoader::preload(__PACKAGE__, @routines) if $running_under_modperl; Where the @routines list is optional, and defaults to every *.al file found for __PACKAGE__. Randy -- ----------- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
About PerlLogHandler phase
Having gone over the Eagle book and the sample chapter of the cookbook (great luck that, having one of the sample chapters coincidentally be the one that covers the logging phase, since I haven't gotten my copy yet), I am still unclear on a few things regarding the logging phase: * If I install a handler for PerlLogHandler, does the normal logging still take place? Is it a function of whether my handler returns OK, DECLINED, etc.? * Are there ways to register other log types, in addition to the access, error, etc.? Such that people could specify those (and a format) the same way they specify the others? More to the point, so that there might be a ready file-descriptor I could print to, rather than having to deal with the open/lock/write/unlock/close cycle. To explain, I am looking at ways to expand the logging capability in my Apache::RPC::Server class. I'd like at the very least to be able to alter the URI part such that it reflects the procedure name that was called (this I understand how to do). Ideally, I'd like to either write completely different lines out to the access log, or (preferable) write to a separate log entirely, so that tracking usage statistics is made that much easier. If I go the separate log route, I don't want the server to be weighted down by the repetitive open/close cycle on the files. Randy -- ----------- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 408 543-9482 | -- Sir Winston Churchill
Detecting and linking to Apache::Status
For the next release of my RPC::XML package, I plan to roll out a status tracker akin to Apache::Status in mod_perl, only to monitor/examine the RPC servers being managed by the mod_perl-ennabled Apache server. I would like to have the main page of this Apache::RPC::Status system offer a link to /perl-status, or whatever the correct URI is, if Apache::Status is available. Is there a way to detect whether Apache::Status is assigned to a location as a handler, and if so, what the URI for this handler is? On a related note, how much information is available to me at run-time about other locations? Is it possible to tell things like authorization settings, etc., about a URI from within a running mod_perl? Randy -- --- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 408 543-9482 | -- Sir Winston Churchill
Setting the "Server" header in a response
I'd like to append the ident string for my XML-RPC server class to the outgoing Server: header, within my mod_perl handler. It seems that setting this with $r->header_out (or getting the tied hash from $r->headers_out and setting the key) doesn't appear in the resulting headers. Is there a different API call I should be using? Randy -- ----------- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Announcing the first release of the RPC::XML package
(Note: I am developing and maintaining this module using my personal resources and address of [EMAIL PROTECTED] I am only posting this message using my redhat.com account due to the fact that this is the address from which I am subscribed to this list.) My apologies in advance to anyone who receives this message more than once. Please check the headers if you reply to this message. I have uploaded the first full release of my XML-RPC package for Perl: > The uploaded file > > RPC-XML-0.25.tar.gz > > has entered CPAN as > > file: $CPAN/authors/id/R/RJ/RJRAY/RPC-XML-0.25.tar.gz > size: 51468 bytes >md5: 5e7339487026b48b922aa35920e52e04 > > No action is required on your part > Request entered by: RJRAY (Randy J Ray) > Request entered on: Wed, 13 Jun 2001 06:30:35 GMT > Request completed: Wed, 13 Jun 2001 06:30:47 GMT > > Virtually Yours, > Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k This package contains an implementation of the XML-RPC standard as defined at the XML-RPC homepage (http://www.xmlrpc.com/spec). The module includes a client class, a basic server class (that uses your choice of HTTP::Daemon or Net::Server as a transport layer) and a subclass of the basic server that hooks in as a mod_perl content handler. The mod_perl handler is not just a simple wrapper around the base object, but a fully-integrated location-handler that manages configuration information and allows for different locations to have their own server objects, or to share existing ones. This package is being initially released at version 0.25 (there were intermediate versions that were announced only to smaller groups for evaluation). The development plan is to work out interface and functionality issues up until a version 0.50, which will represent the first beta release and a freeze on features and functionality. All modules have documentation with them. The documentation may be rough or even outright thin in places, but it should be a reasonable starting point. Any additional questions may be sent to me directly ([EMAIL PROTECTED]). Thank you. Randy -- ----------- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Practical examples of mod_perl Method handlers?
Are there any CPAN modules for Apache that are examples of writing a method handler? The docs in the manpage, the book, and the mod_perl guide are pretty much all the same (brief) text. A good example would help a great deal. Thanks. Randy -- --- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Initialization code that recognized setting
A pointer to sample code on CPAN would be quite welcome here... I would like to have a PerlHandler that may be assigned to several different locations to initialize slightly differently based on the location. In my case, this is an XML-RPC server, and I want the location to be the means of controlling what procedures are published to clients. Thus, when I have something like: SetHandler perl-script PerlHandler Apache::RPC::Server ... (insert access control, etc.) SetHandler perl-script PerlHandler Apache::RPC::Server Now, I know that I can use PerlSetVar within these blocks (and will be, as well), but what I am looking for, is whether there is a point in the initialization phase where the Perl module Apache::RPC::Server can run an init block for each of the or blocks it appears in, with sufficient context information for that block? Essentially, there are some location-specific tasks that only need to occur once. If I put in a test within the handler(), I can get the same effect. But that means running the test on every request, which is redundant after the first invocation. Randy -- --- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Shared memory between child processes
I understand the forking model of Apache, and what that means in terms of data initialized in the start-up phase being ready-to-go in each child process. But what I need to do is manage it so that a particular value is shared between all children, such that changes made by one are recognized by the others. In a simple case, imagine wanting to count how many times total the given handler is invoked. Bumping a global counter will still be local to the given child process, and if part of the handler's interface is to report this counter value, then the reported number is going to be dependent upon which child answers the request. I'm needing to implement a handler that uses a true Singleton pattern for the class instance. One per server, not just one per process (or thread). Randy -- ------- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Designing a handler with minimal lifecycle interaction
I'm working on a module that will provide a handler to do a series of tasks. The tasks are all contingent on the request body, and thus all the requests will be going to the same location, say, /DISPATCH. I know that I can set this up as a simple PerlHandler and manage it at the response stage in the transaction. However, I'm wondering if there is any benefit to be had by intervening at an earlier stage, since there is (by design and definition) no other interaction with Apache. No content negotiation, etc. My goal is to streamline the process at the server end as much as possible, so that I can then focus on the module itself. Randy -- ------- Randy J. Ray | Programming is a Dark Art [...] The programmer is fighting [EMAIL PROTECTED] | against the two most destructive forces in the universe: 415-777-9810 x246 | entropy and human stupidity. --Dr. Damian Conway
