Re: Persistent Net::Telnet Objects

[Medi Montaseri]

Perhaps you can put a System V message Queue in front of both Telnet
connections, this way producers can place their messages in the queue
asynchronously , and the backend (consumer) can pick them up in a FIFO.
Also, try using Net::SSH::Perl. The Net::Telnet does not give your things
like
STDOUT, vs STDERR, vs Exit code. Net::Telnet puts everything in one
channel.
The Security is yet another issue, specially when the session could
be open
and idle for exessive amount of time. Your session can be hijacked
easily.
"French, Shawn" wrote:
Vitals:
Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a
on
Windows 2000 with PHP 4.21
I am working on a project that requires me to have two telnet objects
per
user session opened, and accessible throughout the user's session.
I have
looked at Apache::Session and many other solutions but my problem is
that to
keep a Net::Telnet object, I need to keep open sockets and filehandles,
so I
cannot serialize the object and store it in a database or file.
Currently I have similar code working flawlessly:
###
# "startup.pl" - called when apache starts (ie. PerlRequire
"d:/Apache/conf/startup.pl")
##
use MySite::Session;
###
# "Session.pm"
##
@EXPORT = qw( %sessionHash );
our %sessionHash;
###
# "init_session.pl" - called IN MOD_PERL when a new session is requested
##
use MySite::Session;
$sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();
###
# "dostuff.pl" - called IN MOD_PERL many time throughout the session
##
use MySite::Session;
my telnetObj = $sessionHash{$session_id . "_telnetObj"};
bless (\$telnetObj, "Net::Telnet");
Although this is working right now, I don't know enough [ anything?
:) ]
about Apache or mod_perl to be sure that this will work in the future.
What
I am really concerned about is that the telnetObj will only be accessible
from scripts run by the same child process as that which created and
saved
it.
Is there a better way to do this?
Thanks,
Shawn French

-- 
-
Medi Montaseri   [EMAIL PROTECTED]
Unix Distributed Systems Engineer    HTTP://www.CyberShell.com
CyberShell Engineering
-
 

RE: Invoke PHP scripts?

[Jim Helm]

How about using php in cgi mode and using `php scriptname` from within
perl to capture the output?  Not the best performance-wise, but it would
do what you want, I think.

Jim

--
James Helm - Solaris System Administrator   [EMAIL PROTECTED]
WNS National Operations - Core Services [EMAIL PROTECTED]
AT&T Wireless Services Inc. (425) 288-4395 (Desk) 
3555 Monte Villa Pkwy, Bothell, WA  98021   (206) 618-0438 (Cell)  

> -Original Message-
> From: Ryan Thompson [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, May 28, 2002 8:48 PM
> To: [EMAIL PROTECTED]
> Subject: Invoke PHP scripts?
> 
> 
> 
> Hi there,
> 
> Apologies if this has been asked 2^32 times, but I couldn't 
> seem to find anything in the archives or on the web which 
> would solve my problem.
> 
> I'm developing a large-ish web site in which I would like to 
> use a combination of mod_perl (90%) and PHP (10%). I have run 
> into a roadblock trying to include the output of a PHP script 
> from a mod_perl script.
> 
> This would do fine:
> 
>   my $r = Apache->request();
>   return $r->lookup_uri($url)->run;
> 
> But (and I am familiar with why this happens) run() dumps the 
> results to STDOUT, so the final HTML does not come through in 
> the correct order.
> 
> I tried to use Apache::SSI in this manner:
> 
>   my $r = Apache->request();
>   my $ssi = Apache::SSI->new($contents, $r);
>   return $ssi->get_output();
> 
> (Where $contents is the raw PHP source), but, possibly 
> because of some Content-type mixup, the output is returned as 
> expected (i.e., not dumped to stdout), but the PHP source is 
> not interpreted.
> 
> So, in short, I need another way to invoke a PHP script from 
> my mod_perl application... exactly what  would do.
> 
> Help..? :-)
> 
> - Ryan
> 
> -- 
>   Ryan Thompson <[EMAIL PROTECTED]>
> 
>   SaskNow Technologies - http://www.sasknow.com
>   901 1st Avenue North - Saskatoon, SK - S7K 1Y4
> 
> Tel: 306-664-3600   Fax: 306-664-3630   Saskatoon
>   Toll-Free: 877-727-5669 (877-SASKNOW) North America
> 

Re: Persistant references [was] Persistent Net::Telnet Objects

[Garth Winter Webb]

You could just pass around a string rather than a subref:

my $handler = 'sub { my $arg = @_; do_something(); }';

vs

my $handler = sub { my $arg = @_; do_something(); };

When you want to call it later on you do it like:

eval($handler)->('foo');

vs

$handler->('foo');

Garth

On Wed, 2002-05-29 at 22:17, Ryan Parr wrote:
> I never do give enough info on the first e-mail. Thank you for bearing with
> me...
> 
> What I mean is, if a request comes in for a certain form I would like to be
> able to do something like this:
> 
> my $form = &load_form($r);
> $c{$session_id}->{handler} = $form->{handler}; # <-- this being a code
> ref...
> $r->send_http_header;
> print $form;
> 
> Then when the user completes the form and resubmits:
> 
> my $handler = $c{$session_id}->{handler};
> $r->send_http_header;
> print $handler->($r);
> 
> This is definately simplified, but the idea is there. I would like to be
> able to store anything that can be referenced and have it be available to
> all processes. I would like to be able to dynamically create anonymous
> subroutine handlers based on input and have them be active until the form is
> submitted, at which time they are used to process the form then discarded.
> 
> Is this something that can be accomplished? The global hash using Perl
> aliasing
> (http://thingy.kcilink.com/modperlguide/perl/Using_the_Perl_Aliasing_Feature
> _.html) works beautifully, until of course the form is submitted to another
> httpd process, and I'm hoping to not have to limit myself to just one child.
> 
> Obviously this can't be serialized, but there has to be *some* way to do
> this...
> 
> -- Ryan
> 
> 
> - Original Message -
> From: "Ryan Parr" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 29, 2002 9:16 PM
> Subject: Persistant references [was] Persistent Net::Telnet Objects
> 
> 
> > Along these same lines I'm seeking a way to store a code reference into a
> > global hash that is shared among all processes. For example:
> >
> > my $session_id = get_session_from_cookie($r);
> > my $handler = $c{$session_id}->{handler};
> >
> > $r->send_http_header;
> > print $handler->($r);
> > return OK;
> >
> > Has anyone performed this kind of magical tidbit before? Is there some
> main
> > process repository that I can access?
> >
> > -- Ryan
> >
> >
> > - Original Message -
> > From: "Rob Mueller (fastmail)" <[EMAIL PROTECTED]>
> > To: "French, Shawn" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Wednesday, May 29, 2002 5:35 PM
> > Subject: Re: Persistent Net::Telnet Objects
> >
> >
> > > Our project needed persistent socket connections open as well. There is
> > > supposed to be a standard mechanism to pass file descriptors between
> unix
> > > processes, though it's bugginess level depends on your OS. There is a
> perl
> > > module for this called Socket::PassAccessRights. So what you can do is
> > > create a daemon process that just hangs round holding socket connections
> > > open, like a socket cache basically, and passing them back and forth
> > between
> > > Apache processes based on some session ID or user ID or the like.
> > >
> > > Your daemon ends up looking something like this (with lots more error
> > > checking of course)
> > >
> > > my %sockmap;
> > > while (1) {
> > >   my $clientsock = $listen->accept();
> > >   chomp(my $sessionid = <$clientsock>);
> > >   my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
> > >   Socket::PassAccessRights::sendfd(fileno($clientsock),
> > fileno($cachesock));
> > >   $clientsock->close();
> > > }
> > >
> > > And in your mod_perl code you do something like:
> > >
> > >   my $serversock = IO::Socket::INET->new(Server => 'localhost', Port =>
> > > SOCKETPOOLPORT);
> > >   print $serversock $sessionid, "\n";
> > >   my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
> > >   open(my $realsocket, "<&=$Fd");
> > >   fcntl($realsocket, F_SETFD, 0);
> > >   my $ofh = select($realsocket); $| = 1; select ($ofh);
> > >
> > > If you do some experimenting, you'll get something that works, you'll
> also
> > > find lots of cases that don't.
> > >
> > > Rob
> > >
> > > - Original Message -
> > > From: "French, Shawn" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, May 30, 2002 3:53 AM
> > > Subject: Persistent Net::Telnet Objects
> > >
> > >
> > > > Vitals:
> > > > Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4
> OpenSSL/0.9.6a
> > on
> > > > Windows 2000 with PHP 4.21
> > > >
> > > > I am working on a project that requires me to have two telnet objects
> > per
> > > > user session opened, and accessible throughout the user's session. I
> > have
> > > > looked at Apache::Session and many other solutions but my problem is
> > that
> > > to
> > > > keep a Net::Telnet object, I need to keep open sockets and
> filehandles,
> > so
> > > I
> > > > cannot serialize the object and store it in a database or file.
> > > >
> > > > Currently I have similar co

Re: Persistant references [was] Persistent Net::Telnet Objects

[Ryan Parr]

I never do give enough info on the first e-mail. Thank you for bearing with
me...

What I mean is, if a request comes in for a certain form I would like to be
able to do something like this:

my $form = &load_form($r);
$c{$session_id}->{handler} = $form->{handler}; # <-- this being a code
ref...
$r->send_http_header;
print $form;

Then when the user completes the form and resubmits:

my $handler = $c{$session_id}->{handler};
$r->send_http_header;
print $handler->($r);

This is definately simplified, but the idea is there. I would like to be
able to store anything that can be referenced and have it be available to
all processes. I would like to be able to dynamically create anonymous
subroutine handlers based on input and have them be active until the form is
submitted, at which time they are used to process the form then discarded.

Is this something that can be accomplished? The global hash using Perl
aliasing
(http://thingy.kcilink.com/modperlguide/perl/Using_the_Perl_Aliasing_Feature
_.html) works beautifully, until of course the form is submitted to another
httpd process, and I'm hoping to not have to limit myself to just one child.

Obviously this can't be serialized, but there has to be *some* way to do
this...

-- Ryan


- Original Message -
From: "Ryan Parr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 9:16 PM
Subject: Persistant references [was] Persistent Net::Telnet Objects


> Along these same lines I'm seeking a way to store a code reference into a
> global hash that is shared among all processes. For example:
>
> my $session_id = get_session_from_cookie($r);
> my $handler = $c{$session_id}->{handler};
>
> $r->send_http_header;
> print $handler->($r);
> return OK;
>
> Has anyone performed this kind of magical tidbit before? Is there some
main
> process repository that I can access?
>
> -- Ryan
>
>
> - Original Message -
> From: "Rob Mueller (fastmail)" <[EMAIL PROTECTED]>
> To: "French, Shawn" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, May 29, 2002 5:35 PM
> Subject: Re: Persistent Net::Telnet Objects
>
>
> > Our project needed persistent socket connections open as well. There is
> > supposed to be a standard mechanism to pass file descriptors between
unix
> > processes, though it's bugginess level depends on your OS. There is a
perl
> > module for this called Socket::PassAccessRights. So what you can do is
> > create a daemon process that just hangs round holding socket connections
> > open, like a socket cache basically, and passing them back and forth
> between
> > Apache processes based on some session ID or user ID or the like.
> >
> > Your daemon ends up looking something like this (with lots more error
> > checking of course)
> >
> > my %sockmap;
> > while (1) {
> >   my $clientsock = $listen->accept();
> >   chomp(my $sessionid = <$clientsock>);
> >   my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
> >   Socket::PassAccessRights::sendfd(fileno($clientsock),
> fileno($cachesock));
> >   $clientsock->close();
> > }
> >
> > And in your mod_perl code you do something like:
> >
> >   my $serversock = IO::Socket::INET->new(Server => 'localhost', Port =>
> > SOCKETPOOLPORT);
> >   print $serversock $sessionid, "\n";
> >   my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
> >   open(my $realsocket, "<&=$Fd");
> >   fcntl($realsocket, F_SETFD, 0);
> >   my $ofh = select($realsocket); $| = 1; select ($ofh);
> >
> > If you do some experimenting, you'll get something that works, you'll
also
> > find lots of cases that don't.
> >
> > Rob
> >
> > - Original Message -
> > From: "French, Shawn" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, May 30, 2002 3:53 AM
> > Subject: Persistent Net::Telnet Objects
> >
> >
> > > Vitals:
> > > Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4
OpenSSL/0.9.6a
> on
> > > Windows 2000 with PHP 4.21
> > >
> > > I am working on a project that requires me to have two telnet objects
> per
> > > user session opened, and accessible throughout the user's session. I
> have
> > > looked at Apache::Session and many other solutions but my problem is
> that
> > to
> > > keep a Net::Telnet object, I need to keep open sockets and
filehandles,
> so
> > I
> > > cannot serialize the object and store it in a database or file.
> > >
> > > Currently I have similar code working flawlessly:
> > > ###
> > > # "startup.pl" - called when apache starts (ie. PerlRequire
> > > "d:/Apache/conf/startup.pl")
> > > ##
> > > use MySite::Session;
> > >
> > > ###
> > > # "Session.pm"
> > > ##
> > > @EXPORT = qw( %sessionHash );
> > > our %sessionHash;
> > >
> > > ###
> > > # "init_session.pl" - called IN MOD_PERL when a new session is
requested
> > > ##
> > > use MySite::Session;
> > > $sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();
> > >
> > > ###
> > > # "dostuff.pl" - called IN MOD_PERL many time throughout the session
> > > ##
> > > use MySite::Session;
> > > my

Persistant references [was] Persistent Net::Telnet Objects

[Ryan Parr]

Along these same lines I'm seeking a way to store a code reference into a
global hash that is shared among all processes. For example:

my $session_id = get_session_from_cookie($r);
my $handler = $c{$session_id}->{handler};

$r->send_http_header;
print $handler->($r);
return OK;

Has anyone performed this kind of magical tidbit before? Is there some main
process repository that I can access?

-- Ryan


- Original Message -
From: "Rob Mueller (fastmail)" <[EMAIL PROTECTED]>
To: "French, Shawn" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 5:35 PM
Subject: Re: Persistent Net::Telnet Objects


> Our project needed persistent socket connections open as well. There is
> supposed to be a standard mechanism to pass file descriptors between unix
> processes, though it's bugginess level depends on your OS. There is a perl
> module for this called Socket::PassAccessRights. So what you can do is
> create a daemon process that just hangs round holding socket connections
> open, like a socket cache basically, and passing them back and forth
between
> Apache processes based on some session ID or user ID or the like.
>
> Your daemon ends up looking something like this (with lots more error
> checking of course)
>
> my %sockmap;
> while (1) {
>   my $clientsock = $listen->accept();
>   chomp(my $sessionid = <$clientsock>);
>   my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
>   Socket::PassAccessRights::sendfd(fileno($clientsock),
fileno($cachesock));
>   $clientsock->close();
> }
>
> And in your mod_perl code you do something like:
>
>   my $serversock = IO::Socket::INET->new(Server => 'localhost', Port =>
> SOCKETPOOLPORT);
>   print $serversock $sessionid, "\n";
>   my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
>   open(my $realsocket, "<&=$Fd");
>   fcntl($realsocket, F_SETFD, 0);
>   my $ofh = select($realsocket); $| = 1; select ($ofh);
>
> If you do some experimenting, you'll get something that works, you'll also
> find lots of cases that don't.
>
> Rob
>
> - Original Message -
> From: "French, Shawn" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 30, 2002 3:53 AM
> Subject: Persistent Net::Telnet Objects
>
>
> > Vitals:
> > Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a
on
> > Windows 2000 with PHP 4.21
> >
> > I am working on a project that requires me to have two telnet objects
per
> > user session opened, and accessible throughout the user's session. I
have
> > looked at Apache::Session and many other solutions but my problem is
that
> to
> > keep a Net::Telnet object, I need to keep open sockets and filehandles,
so
> I
> > cannot serialize the object and store it in a database or file.
> >
> > Currently I have similar code working flawlessly:
> > ###
> > # "startup.pl" - called when apache starts (ie. PerlRequire
> > "d:/Apache/conf/startup.pl")
> > ##
> > use MySite::Session;
> >
> > ###
> > # "Session.pm"
> > ##
> > @EXPORT = qw( %sessionHash );
> > our %sessionHash;
> >
> > ###
> > # "init_session.pl" - called IN MOD_PERL when a new session is requested
> > ##
> > use MySite::Session;
> > $sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();
> >
> > ###
> > # "dostuff.pl" - called IN MOD_PERL many time throughout the session
> > ##
> > use MySite::Session;
> > my telnetObj = $sessionHash{$session_id . "_telnetObj"};
> > bless (\$telnetObj, "Net::Telnet");
> >
> > Although this is working right now, I don't know enough [ anything? :) ]
> > about Apache or mod_perl to be sure that this will work in the future.
> What
> > I am really concerned about is that the telnetObj will only be
accessible
> > from scripts run by the same child process as that which created and
saved
> > it.
> >
> > Is there a better way to do this?
> >
> > Thanks,
> > Shawn French
> >
> >
>

Re: Invoke PHP scripts?

[Stas Bekman]

Ryan Thompson wrote:
> Thomas Klausner wrote to [EMAIL PROTECTED]:
> 
> 
>>Hi!
>>
>>On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote:
>>
>>
>>>I'm developing a large-ish web site in which I would like to use a
>>>combination of mod_perl (90%) and PHP (10%). I have run into a
>>>roadblock trying to include the output of a PHP script from a
>>>mod_perl script.

How about using notes()?
http://perl.apache.org/release/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules


__
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: Reloading Modules

[Stas Bekman]

Ted Prah wrote:
> Thanks for the input Stats.  I found your debugging methodology
> to be very informative and especially useful in a mod_perl environment.
> 
> I tried your suggestion of commenting out
>  require $key;
> in Reload.pm, but it did not work for me.  I'd be happy to try
> any other suggestions you might have.

But did you debug whether the module was reloaded from test.pl with the 
modified Reload.pm? If so was the import() called? If not, try to have 
it as a separate call:

require My::Test;
My::Test->import(':subs');

> Your code to work around Exporter worked fine.  However,
> I think I'll stick with using Exporter so that I can make use
> of the export tags.

But it doesn't seem to work? You can easily extend the import() function 
I've suggested to suppport tags.

__
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: Persistent Net::Telnet Objects

[Rob Mueller (fastmail)]

Our project needed persistent socket connections open as well. There is
supposed to be a standard mechanism to pass file descriptors between unix
processes, though it's bugginess level depends on your OS. There is a perl
module for this called Socket::PassAccessRights. So what you can do is
create a daemon process that just hangs round holding socket connections
open, like a socket cache basically, and passing them back and forth between
Apache processes based on some session ID or user ID or the like.

Your daemon ends up looking something like this (with lots more error
checking of course)

my %sockmap;
while (1) {
  my $clientsock = $listen->accept();
  chomp(my $sessionid = <$clientsock>);
  my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
  Socket::PassAccessRights::sendfd(fileno($clientsock), fileno($cachesock));
  $clientsock->close();
}

And in your mod_perl code you do something like:

  my $serversock = IO::Socket::INET->new(Server => 'localhost', Port =>
SOCKETPOOLPORT);
  print $serversock $sessionid, "\n";
  my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
  open(my $realsocket, "<&=$Fd");
  fcntl($realsocket, F_SETFD, 0);
  my $ofh = select($realsocket); $| = 1; select ($ofh);

If you do some experimenting, you'll get something that works, you'll also
find lots of cases that don't.

Rob

- Original Message -
From: "French, Shawn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 3:53 AM
Subject: Persistent Net::Telnet Objects


> Vitals:
> Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a on
> Windows 2000 with PHP 4.21
>
> I am working on a project that requires me to have two telnet objects per
> user session opened, and accessible throughout the user's session. I have
> looked at Apache::Session and many other solutions but my problem is that
to
> keep a Net::Telnet object, I need to keep open sockets and filehandles, so
I
> cannot serialize the object and store it in a database or file.
>
> Currently I have similar code working flawlessly:
> ###
> # "startup.pl" - called when apache starts (ie. PerlRequire
> "d:/Apache/conf/startup.pl")
> ##
> use MySite::Session;
>
> ###
> # "Session.pm"
> ##
> @EXPORT = qw( %sessionHash );
> our %sessionHash;
>
> ###
> # "init_session.pl" - called IN MOD_PERL when a new session is requested
> ##
> use MySite::Session;
> $sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();
>
> ###
> # "dostuff.pl" - called IN MOD_PERL many time throughout the session
> ##
> use MySite::Session;
> my telnetObj = $sessionHash{$session_id . "_telnetObj"};
> bless (\$telnetObj, "Net::Telnet");
>
> Although this is working right now, I don't know enough [ anything? :) ]
> about Apache or mod_perl to be sure that this will work in the future.
What
> I am really concerned about is that the telnetObj will only be accessible
> from scripts run by the same child process as that which created and saved
> it.
>
> Is there a better way to do this?
>
> Thanks,
> Shawn French
>
>

RE: Persistent Net::Telnet Objects

[mod_perl]

Maybe you can tell us more about the project (e.g. why 
telnet ?) so there will come many bad advices ? :-)

Peter Bi
 
> Perrin wrote:
> > I can't see how it could be working now
> 
> That makes two of us!
> 
> > You're probably opening new telnet connections from each apache process.
> 
> I know that I am not since they are continuing to log to the same dump file,
> and my code (as stated in previous message) simply goes to the hash and
> takes the object.
> 
> > That won't work, since you can't control which process will handle 
> > requests from the client.
> 
> OK, is there a way to make sure that there is just one process? This site is
> not for milions of users, only 10 - 20.
> 
> I'm sure that others have had to keep persistent sockets and/or filehandles
> on their server, and I really don't see how my problem is any different...
> 
> Please, can anybody help me?
> Shawn

RE: Persistent Net::Telnet Objects

[French, Shawn]

Perrin wrote:
> I can't see how it could be working now

That makes two of us!

> You're probably opening new telnet connections from each apache process.

I know that I am not since they are continuing to log to the same dump file,
and my code (as stated in previous message) simply goes to the hash and
takes the object.

> That won't work, since you can't control which process will handle 
> requests from the client.

OK, is there a way to make sure that there is just one process? This site is
not for milions of users, only 10 - 20.

I'm sure that others have had to keep persistent sockets and/or filehandles
on their server, and I really don't see how my problem is any different...

Please, can anybody help me?
Shawn

Re: Persistent Net::Telnet Objects

[Perrin Harkins]

French, Shawn wrote:
> Although this is working right now, I don't know enough [ anything? :) ]
> about Apache or mod_perl to be sure that this will work in the future.

I can't see how it could be working now, unless it is actually creating 
a new Telnet object on every request.  Your %sessionHash is not shared 
between processes and you have no control over which process will handle 
any request.  You're probably opening new telnet connections from each 
apache process.

> What
> I am really concerned about is that the telnetObj will only be accessible
> from scripts run by the same child process as that which created and saved
> it.

That won't work, since you can't control which process will handle 
requests from the client.

> Is there a better way to do this?

You could write a web server in Perl, which would run a separate 
persistent process for each client on a different port.  Randal wrote a 
column about that: http://www.stonehenge.com/merlyn/WebTechniques/col23.html

You could also use this technique to make a sort of telnet server, and 
hide that server behind Apache/mod_perl, i.e. clients talk to mod_perl 
which talks to the telnet server.

Of course the simplest approach would be to just let each Apache process 
open telnet sessions as needed.

- Perrin

Re: Invoke PHP scripts?

[Ryan Thompson]

Thomas Klausner wrote to [EMAIL PROTECTED]:

> Hi!
>
> On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote:
>
> > I'm developing a large-ish web site in which I would like to use a
> > combination of mod_perl (90%) and PHP (10%). I have run into a
> > roadblock trying to include the output of a PHP script from a
> > mod_perl script.
>
> As far as I know this is rather impossible with mod_perl 1.x

Hi Thomas,

I was beginning to get that impression myself ;-)

As an unelegant, inefficient, but somewhat useful hack, I ended up
reversing the logic and wrapping my mod_perl script in PHP, with PHP's
virtual() function. It's not altogether efficient, and adds another
layer of complexity, but it works for me, and it's fast/stable enough
to be production code.

> [...]
>
> Apache 2.0 (and mod_perl 2.0) (both in BETA) can do what you want
> unsing Filters.

That'll be great when the technology is ready for production.

- Ryan

-- 
  Ryan Thompson <[EMAIL PROTECTED]>

  SaskNow Technologies - http://www.sasknow.com
  901 1st Avenue North - Saskatoon, SK - S7K 1Y4

Tel: 306-664-3600   Fax: 306-664-3630   Saskatoon
  Toll-Free: 877-727-5669 (877-SASKNOW) North America

Re: Reloading Modules

[Ted Prah]

Thanks for the input Stats.  I found your debugging methodology
to be very informative and especially useful in a mod_perl environment.

I tried your suggestion of commenting out
 require $key;
in Reload.pm, but it did not work for me.  I'd be happy to try
any other suggestions you might have.

Your code to work around Exporter worked fine.  However,
I think I'll stick with using Exporter so that I can make use
of the export tags.

Thanks again!

Ted


Stas Bekman wrote:

> Ted Prah wrote:
> > Hi again,
> >
> > I'm having trouble seeing module changes when I reload
> > a script that uses it.
>
> That's because Reload.pm doesn't re-exports the symbols when reloading
> the module and test.pl doesn't call import() because it sees the module
> in %INC, therefore it still sees the old sub till the moment it gets
> recompiled. Below you will find a complete analysis.
>
> > I'm using Apache::Reload and my test
> > script/module is as follows:
> >
> >
> > test.pl
> > 
> > #!/usr/local/bin/perl
> > use strict;
> > use warnings;
> >
> > use My::Test qw(:subs);
> >
> > print "Content-type: text/plain\r\n\r\n";
> > &test1();
> > 
> >
> >
> > Test.pm
> > 
> > package My::Test;
> > use strict;
> > use warnings;
> >
> > BEGIN {
> > use Exporter ();
> >
> > our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> >
> > @ISA   = qw(Exporter);
> > @EXPORT= qw();
> > @EXPORT_OK = qw();
> >
> > %EXPORT_TAGS = (
> > subs => [qw(test1)],
> >);
> >
> > Exporter::export_ok_tags('subs');
> >
> > }
> >
> > sub test1 { print "In test1 func\n"; }
> >
> > 1;
> > 
>
> adjust the test.pl to do:
>
> test1(); print \&test1, "\n";
> #test2(); print \&test2, "\n";
>
> and My::Test.pm to:
>
> ...
> warn "test1:", \&test1, "\n";
> #warn "test2:", \&test2, "\n";
> sub test1 { print "In test1 func\n"; }
> #sub test2 { print "In test2 func\n"; }
> ...
>
> The first time you run the script you will see:
>
> output:
> In test1 func
> CODE(0x85ad38c)
>
> error_log:
> test1:CODE(0x85ad38c)
>
> you can see that both test1 and My::Test::test1 point to the same sub.
>
> > When I modify sub test1, and I reload - no changes appear
> > in the browser.  The following gets printed to error_log:
> > Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line 22.
>
> output:
> In test1 func
> CODE(0x85ad38c)
>
> error_log:
> test1:CODE(0x84ee110)
>
> as you see the test1 is not the same as My::Test::test1
>
> > When I touch test.pl - the changes appear.  The following gets printed
> > to error_log:
> > Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line 5
>
> output:
> In test11 func
> CODE(0x84ee110)
>
> now it points to the recent My::Test::test1
>
> In that way you can debug any "mysteries" in Perl code.
>
> Now, how to solve this problem. For example comment out
>  require $key;
>
> in Reload.pm
>
> that way, test.pl will see that My::Test is not in %INC, and require it
> + call its import() method.
>
> Tell if this worked and we may adjust Reload.pm to have a special mode
> where it makes Perl forget about modified modules and let the code that
> loaded them in first place do the loading (and therefore the importing).
>
> > Finally, if I add a new subroutine test2 to Test.pm, export it, and
> > update the test.pl script to call test2, the script fails with an
> > Internal
> > Server Error.  The following gets printed to error_log:
> > "test2" is not exported by the My::Test module at
> > /export/home/httpd/cgi-bin/My/test.pl line 5
> > [Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
> >
> > /export/home/httpd/cgi-bin/My/test.pl line 5
> > BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
> > My/test.pl line 5.
> >
> > Then, when I restart the server, the script runs fine.
>
> Hmm, this one is different. Seems like a bug in Exporter.
>
> if you remove Reload.pm from the setup, so it won't confuse you and
> adjust the code to do:
>
> do "My/Test.pm";
> My::Test->import(':subs');
>
> you will see that it fails as well. This code acts like Reload.pm, but
> always reloads the module. So it's not Reload.pm's fault.
>
> Is anybody else  familiar with this Exporter's (mis)behavior?
>
> The solution that I see is to use something like this:
>
> package My::Test;
>
> use strict;
> use warnings;
>
> sub import {
>  my $package = shift;
>
>  no strict 'refs';
>  for (@_) {
>  *{ (caller)[0] . "::$_" } = \&{$_};
>  }
> }
>
> sub test1 { print "In test1 func\n"; }
> sub test2 { print "In test2 func\n"; }
>
> 1;
>
> If somebody else can see the problem with Exporter may be we need to run
> it through p5p.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apac

Persistent Net::Telnet Objects

[French, Shawn]

Vitals:
Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a on
Windows 2000 with PHP 4.21

I am working on a project that requires me to have two telnet objects per
user session opened, and accessible throughout the user's session. I have
looked at Apache::Session and many other solutions but my problem is that to
keep a Net::Telnet object, I need to keep open sockets and filehandles, so I
cannot serialize the object and store it in a database or file.

Currently I have similar code working flawlessly:
###
# "startup.pl" - called when apache starts (ie. PerlRequire
"d:/Apache/conf/startup.pl")
##
use MySite::Session;

###
# "Session.pm"
##
@EXPORT = qw( %sessionHash );
our %sessionHash;

###
# "init_session.pl" - called IN MOD_PERL when a new session is requested
##
use MySite::Session;
$sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();

###
# "dostuff.pl" - called IN MOD_PERL many time throughout the session
##
use MySite::Session;
my telnetObj = $sessionHash{$session_id . "_telnetObj"};
bless (\$telnetObj, "Net::Telnet");

Although this is working right now, I don't know enough [ anything? :) ]
about Apache or mod_perl to be sure that this will work in the future. What
I am really concerned about is that the telnetObj will only be accessible
from scripts run by the same child process as that which created and saved
it.

Is there a better way to do this?

Thanks,
Shawn French

Fwd: ApacheCon session submissions: deadline is this Friday!

[Stas Bekman]

 Original Message 
Subject: ApacheCon session submissions: deadline is this Friday!
Date: Tue, 28 May 2002 13:15:57 -0400
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: The Apache Software Foundation
To: ASF members <[EMAIL PROTECTED]>

Please make sure that all the appropriate project lists get
a copy..
-- 
#ken 
P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"

-- 


__
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

--- Begin Message ---

-BEGIN PGP SIGNED MESSAGE-

Greetings!

Just a reminder: this Friday is the deadline for presentation
proposals for the ApacheCon 2002 US conference in Las Vegas
in November 2002..

To submit a proposal, visit http://ApacheCon.Com/html/cfp.html>.
If you're not sure about a topic, or how well it might be received,
you can ask other ApacheCon attendees by posting a message on the
conference discussion list (see the Web page with the list details at
http://ApacheCon.Com/html/lists.html>).

Similarly, if you plan (or want) to attend the conference and want
to request a particular topic, join the discussion list and say so.
Not only will the planners then know, but you might trigger someone
into proposing your ideal session!
- -- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQCVAwUBPPO5sprNPMCpn3XdAQEsDAP/QCP8kv5WtiKCj+5Maof2qkwrJ8/LBkVi
4gJvuEgZQda2m2HzUfcAr7+mtSEEV3p8aispEes/bDCVLKWyPbnbc5PCTeLhN99c
SXbjtTNzZf7lQeb36M/QLlrHgnP8ovUqln3w2P3AGETnl1gbiPnpA52cXW/L3vRH
tZr55PXOY3I=
=kib0
-END PGP SIGNATURE-



--- End Message ---

Re: MVC advice..?

[Andy Wardley]

On Wed, May 29, 2002 at 11:11:59AM -0500, Dave Rolsky wrote:
> If require is given a string, it looks for a filename _matching_ that
> string.  If it's given a bareword, it converts '::' to filesystem path
> separators first.



...and appends '.pm' onto the end.

Thus
require Foo::Bar

is the same as:
$module = 'Foo::Bar';
$module =~ s[::][/]g;
$module .= '.pm';
require $module;

If you 'use' the module, then it also does the equivalent of:
$module->import();



A

Re: Reloading Modules

[Stas Bekman]

Ted Prah wrote:
> Hi again,
> 
> I'm having trouble seeing module changes when I reload
> a script that uses it.  

That's because Reload.pm doesn't re-exports the symbols when reloading 
the module and test.pl doesn't call import() because it sees the module 
in %INC, therefore it still sees the old sub till the moment it gets 
recompiled. Below you will find a complete analysis.

> I'm using Apache::Reload and my test
> script/module is as follows:
> 
> 
> test.pl
> 
> #!/usr/local/bin/perl
> use strict;
> use warnings;
> 
> use My::Test qw(:subs);
> 
> print "Content-type: text/plain\r\n\r\n";
> &test1();
> 
> 
> 
> Test.pm
> 
> package My::Test;
> use strict;
> use warnings;
> 
> BEGIN {
> use Exporter ();
> 
> our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> 
> @ISA   = qw(Exporter);
> @EXPORT= qw();
> @EXPORT_OK = qw();
> 
> %EXPORT_TAGS = (
> subs => [qw(test1)],
>);
> 
> Exporter::export_ok_tags('subs');
> 
> }
> 
> sub test1 { print "In test1 func\n"; }
> 
> 1;
> 

adjust the test.pl to do:

test1(); print \&test1, "\n";
#test2(); print \&test2, "\n";

and My::Test.pm to:

...
warn "test1:", \&test1, "\n";
#warn "test2:", \&test2, "\n";
sub test1 { print "In test1 func\n"; }
#sub test2 { print "In test2 func\n"; }
...

The first time you run the script you will see:

output:
In test1 func
CODE(0x85ad38c)

error_log:
test1:CODE(0x85ad38c)

you can see that both test1 and My::Test::test1 point to the same sub.

> When I modify sub test1, and I reload - no changes appear
> in the browser.  The following gets printed to error_log:
> Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line 22.

output:
In test1 func
CODE(0x85ad38c)

error_log:
test1:CODE(0x84ee110)

as you see the test1 is not the same as My::Test::test1

> When I touch test.pl - the changes appear.  The following gets printed
> to error_log:
> Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line 5

output:
In test11 func
CODE(0x84ee110)

now it points to the recent My::Test::test1

In that way you can debug any "mysteries" in Perl code.

Now, how to solve this problem. For example comment out
 require $key;

in Reload.pm

that way, test.pl will see that My::Test is not in %INC, and require it 
+ call its import() method.

Tell if this worked and we may adjust Reload.pm to have a special mode 
where it makes Perl forget about modified modules and let the code that 
loaded them in first place do the loading (and therefore the importing).

> Finally, if I add a new subroutine test2 to Test.pm, export it, and
> update the test.pl script to call test2, the script fails with an
> Internal
> Server Error.  The following gets printed to error_log:
> "test2" is not exported by the My::Test module at
> /export/home/httpd/cgi-bin/My/test.pl line 5
> [Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
> 
> /export/home/httpd/cgi-bin/My/test.pl line 5
> BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
> My/test.pl line 5.
> 
> Then, when I restart the server, the script runs fine.

Hmm, this one is different. Seems like a bug in Exporter.

if you remove Reload.pm from the setup, so it won't confuse you and 
adjust the code to do:

do "My/Test.pm";
My::Test->import(':subs');

you will see that it fails as well. This code acts like Reload.pm, but 
always reloads the module. So it's not Reload.pm's fault.

Is anybody else  familiar with this Exporter's (mis)behavior?

The solution that I see is to use something like this:

package My::Test;

use strict;
use warnings;

sub import {
 my $package = shift;

 no strict 'refs';
 for (@_) {
 *{ (caller)[0] . "::$_" } = \&{$_};
 }
}

sub test1 { print "In test1 func\n"; }
sub test2 { print "In test2 func\n"; }

1;

If somebody else can see the problem with Exporter may be we need to run 
it through p5p.

__
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: DBI & modperl_2 Segmentation fault

[Doug MacEachern]

On Fri, 24 May 2002, Udlei Nattis wrote:

> hi
> 
> i updating modperl-2.0-cvs and problem persist
> now i change DynaLoader in DBI.pm to XSLoader but problem persist :(

you shouldn't need to change DBI.pm
the output of perl build/config.pl (normally should use t/REPORT) might 
help.  and your DBI version.

Re: Patch to mod_perl 1.26: "error-notes" support

[Doug MacEachern]

On Tue, 28 May 2002, Geoffrey Young wrote:

> 
> 
> Doug MacEachern wrote:
> 
> > thanks, i've applied a variation of your patch to cvs and will be in 1.27
> > if anybody wants to work up a similar patch for Apache::PerlRun, that'd be 
> > nice too.
> > 
> 
> this seems to work ok as PerlRun and RegistryNG.

looks good, +1.  thanks.

Re: MVC advice..?

[Perrin Harkins]

Dave Rolsky wrote:
> On Wed, 29 May 2002, Perrin Harkins wrote:
> 
> 
>>There's no good reason to do an eval 'use'.  Use require instead, and
>>import if you need to (but most people don't).
> 
> 
> Actually, there is.  This code:
> 
>   my $module = 'Foo::Bar';
>   require $module;
> 
> is not the same as this:
> 
>   require Foo::Bar;
> 
> If require is given a string, it looks for a filename _matching_ that
> string.  If it's given a bareword, it converts '::' to filesystem path
> separators first.

Then do an eval 'require Foo::Bar', but eval 'use Foo::Bar' doesn't make 
sense.

- Perrin

Re: MVC advice..?

[Dave Rolsky]

On Wed, 29 May 2002, Perrin Harkins wrote:

> There's no good reason to do an eval 'use'.  Use require instead, and
> import if you need to (but most people don't).

Actually, there is.  This code:

  my $module = 'Foo::Bar';
  require $module;

is not the same as this:

  require Foo::Bar;

If require is given a string, it looks for a filename _matching_ that
string.  If it's given a bareword, it converts '::' to filesystem path
separators first.


-dave

/*==
www.urth.org
we await the New Sun
==*/

Re: separating C from V in MVC

[Perrin Harkins]

Ray Zimmerman wrote:
> If I understand correctly, the Mason component that generates the page 
> the user sees would be considered the View. But where is the Controller?

I wrote a little about this in my templating guide, and there has been 
discussion on the Mason list.  A common approach is to use Mason's 
autohandlers as controllers, but you could really use any component. 
Just have it do some work in perl, gather some data, and then pass it 
off to a view component that generates the HTML.

> This is code I
> would normally have put in the <%init> section of the display component 
> (with a possible redirect to another component based on application 
> logic). This sounds like C and V are not separated as they should be.

That's a standard way to do it in Mason, but not an MVC way.  To make it 
more MVC, you need to have separate components for C and V, with V just 
receiving data and displaying it in HTML.

- Perrin

separating C from V in MVC

[Ray Zimmerman]

We're developing a pretty complex web app using mod_perl and Mason 
and I'd like to use some form of MVC structure to keep things 
manageable.

I'm looking for some pointers on MVC in this context. Specifically, M 
is easy ... use Perl objects, but how are others implementing the 
Controllers and Views in order to keep them separate?

If I understand correctly, the Mason component that generates the 
page the user sees would be considered the View. But where is the 
Controller? I assume that, conceptually, the Controller is the code 
that responds to a given web request and decides which view to 
display. This is code I would normally have put in the <%init> 
section of the display component (with a possible redirect to another 
component based on application logic). This sounds like C and V are 
not separated as they should be.

What's the "right" way to do it?  (None of this TMTOWTDO stuff now, I 
want the RIGHT way :-)   ... and do I have the concepts right?

-- 
  Ray Zimmerman  / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
Associate  /  FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: MVC advice..?

[Perrin Harkins]

Rafiq Ismail (ADMIN) wrote:
> I'm not so keen on loading all the inheriting classes into memory
> beforehand

You really should do that, because it will save overall memory by 
increasing the amount of memory that's shared.  All modules should be 
loaded during startup in the parent process.

> It's a
> fairly large site and my main concern was to do with how I should store
> the correspondence from uri to object.

The httpd.conf format seems about as simple as you can get to me.  It's 
pretty unusual for a site to have dozens of controllers, and it usually 
indicates a design problem.  Apache::Dispatch is fine too.

> How does StatINC behave with 'required' packages?

Require and use are very similar and both add the loaded module to %INC. 
  Read 'perldoc -f use' for the exact differences.

- Perrin

Re: MVC advice..?

[Rafiq Ismail (ADMIN)]

Ello,

On 29 May 2002, Randal L. Schwartz wrote:

> > "Rafiq" == Rafiq Ismail (ADMIN) <[EMAIL PROTECTED]>
writes:
> Rafiq> Is there a neat way of dynamically loading in the appropriate
control
> Rafiq> subclass?  Something proven and widely used.
>
> Load the file with a require, and then just call the appropriate
> constructor using an indirect call:
>
> require "My/Prefix/$type"; # presuming $type has no colons
> $myClass = "My::Prefix::$type";
> my $handler = $myClass->new(@parms);
>
> This works even in "use strict".

Thanks.  This is pretty much the handler which I'd previously written,
with the the exception of s/use/require/.  I'll probably either go with
Apache::Dispatch, using the DispatchRequire option, or write something
custom.


On Wed, 29 May 2002, Perrin Harkins wrote:
> So, you're asking how to map URLs to perl modules?  Is there some reason
> you aren't simply using httpd.conf or Apache::Dispatch?  In my last MVC

I just took a look at Apache::Dispatch and I get he impression that if I
were to use it then I would have to either PerlModule 'all' my subclasses
beforehand, or alternateively use the DispatchRequire option anyway.  I'm
already using StatINC so I'm going to have to do a toss between code which
I've already written and converging to the Apache::Dispatch interface.

I'm not so keen on loading all the inheriting classes into memory
beforehand, nor setting up multiple handlers for each location.  It's a
fairly large site and my main concern was to do with how I should store
the correspondence from uri to object.


> design, we had all of our controllers inherit from one base controller
> that held all of the common code.

I could just map from URLs to the specific control subclasses and then use
Dispatch to require them - I'd already started on writing a mapping from
path names to relative namespaces.  I was still 'eval/use'ing the
Modules though.

How does StatINC behave with 'required' packages?

Hmm.. it's "make your mind up time. ;)


Thanks for the tips.
Cheers,

Fiq

__
"__  __   _ __  __
|  \/  | ___   __| | ___ _ __ _ __ |  \/  | __ _ _ __
| |\/| |/ _ \ / _` |/ _ \ '__| '_ \| |\/| |/ _` | '_ \
| |  | | (_) | (_| |  __/ |  | | | | |  | | (_| | | | |
|_|  |_|\___/ \__,_|\___|_|  |_| |_|_|  |_|\__,_|_| |_|
a pathetic example of his organic heritage"
- Bad Religion

Re: Referencing Directives

[Ian D. Stewart]

On 2002.05.28 01:23 Per Einar Ellefsen wrote:

> 
> Or... maybe you could try using Apache class methods inside  
> sections (like document_root) -- however I think that'd be pretty 
> shaky.

Hmm...something to tinker with as time permits...


Thanx,
Ian

Re: Carp interaction with mod_perl

[Stas Bekman]

Christian Gilmore wrote:
> How does the Carp module interact with mod_perl? Is there a built-in catch
> for croak or does it actually kill the child process, for instance?

seems not to have any effect, i.e. it doesn't kill the process

__
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: PerlWarn/AxKit - insecure dependency

[Per Einar Ellefsen]

At 16:00 29.05.2002, Arnold van Kampen wrote:


>Hi
>
>I have been going through the code example on www.perl.com
>(XSP, Taglibs and Pipelines)
>
>I  noticed I get a problem with
>PerlWarn On
>PerlTaintCheck On
>in httpd.conf.
>So, when I turn PerlWarn Off and PerlTaintCheck Off it works.
>
>Main error message:
>[AxKit] [Error] Insecure dependency in eval while running with -T switch
>at /usr/lib/perl5/site_perl/5.6.1/i586-linux/Apache/AxKit/Language/XSP.pm
>line 109.

This is AxKit and not mod_perl's fault. AxKit doesn't seem to be taint 
safe. You might want to get them to change it (unlikely, it'd be a pretty 
long job :) or turn off PerlTaintCheck.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: MVC advice..?

[Perrin Harkins]

Rafiq Ismail (ADMIN) wrote:
> Now my problem is that I have to assign which
> Subclass I want to instantiate, based on the script and params.

So, you're asking how to map URLs to perl modules?  Is there some reason 
you aren't simply using httpd.conf or Apache::Dispatch?  In my last MVC 
design, we had all of our controllers inherit from one base controller 
that held all of the common code.  Then we could just map from URLs to 
the specific controllers that handled them:


   SetHandler  perl-script
   PerlHandler My::Controller


> I my last
> effort I went for a Shared datastructure holding (script, control module
> pairs) which then allowed one to be dynamically "eval 'use..'"'ed in the
> main content handler.  I found that clunky.

There's no good reason to do an eval 'use'.  Use require instead, and 
import if you need to (but most people don't).

> I'm building from scratch
> again and am thinking of just firing up a template and allowing the
> control to be loaded INTO the view as a template toolkit plugin.  What I
> hate about this is that I'm surrendering my View layer.

I agree, that's a bad idea and certainly not MVC.

- Perrin

Re: MVC advice..?

[F . Xavier Noria]

On Wed, 29 May 2002 09:22:00 -0400
"Aaron Ross" <[EMAIL PROTECTED]> wrote:

: > Is there a neat way of dynamically loading in the appropriate control
: > subclass?  Something proven and widely used.
: 
: For what it's worth, I use the eval trick too.  Although it may seem a
: little clunky, I believe it is "proven and widely used".  The DBI.pm
: module uses code like this to load in the DBD drivers:
: 
: my $driver_class = "DBD::$driver";
: eval "package DBI::_firesafe; require $driver_class";

I wonder, why do you program such a central module that dynamic? Why
do you chose that approach instead of this one?

 package Dispatcher;

 use Controller1;
 # ...
 use ControllerN;

 sub handler {
 my $r = Apache::Request->new(shift);
 my $ctl = $r->param('ctl');

 return Controller1::handler($r) if $ctl = 'login';
 # ...
 return ControllerN::handler($r) if $ctl = 'show_cart';
 return SERVER_ERROR;
 }

-- fxn

PerlWarn/AxKit - insecure dependency

[Arnold van Kampen]

Hi

I have been going through the code example on www.perl.com
(XSP, Taglibs and Pipelines)

I  noticed I get a problem with 
PerlWarn On
PerlTaintCheck On
in httpd.conf.
So, when I turn PerlWarn Off and PerlTaintCheck Off it works.

Main error message:
[AxKit] [Error] Insecure dependency in eval while running with -T switch
at /usr/lib/perl5/site_perl/5.6.1/i586-linux/Apache/AxKit/Language/XSP.pm
line 109.
 
For testing I used these
lynx -source localhost/axkit/weather1.xsp?zip=15206 | xmllint --format -
lynx -source localhost/axkit/weather1.xsp?zip=15206 




Arnold


I am using 
Apache 1.3.23 
mod_perl 1.26
AxKit 1.52
linux 2.4.10 i686 (SuSE) 


Below are 
- config files
- code example files
- error message


CONFIG FILES

# startup.pl

#!/usr/bin/perl

use lib qw(/usr/local/apache/lib/modperl);
#use lib qw("/home/kampen/lib/modperl");

use Apache::Constants;
use Apache::Registry;
use Apache::RegistryLoader;
use DBI;
use CGI qw(:all);


use DirHandle;
use strict;


$Apache::Registry::NameWithVirtualHost = 0;


my $rl = Apache::RegistryLoader->new;
my $dh = DirHandle->new("/usr/local/apache/perl") or die $!;

foreach my $file ($dh->read) {
next unless $file =~ /\.(pl|cgi)$/;

#print $STDOUT "pre-loading $file\n";


$rl->handler("/perl/$file","/usr/local/apache/perl/$file");
}


1;
__END__


# perl.conf

PerlRequire conf/startup.pl

PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadTouchFile /tmp/reload_modules
#PerlWarn On
#PerlTaintCheck On

PerlModule  AxKit
Alias /axkit/   /usr/local/apache/axkit/

SetHandler  perl-script
PerlHandler AxKit
   
AxDebugLevel 10
AxCacheDir  /tmp/axkit_cache
AxStackTraceOn   
AxGzipOutputOff

AxAddXSPTaglib AxKit::XSP::Util
AxAddXSPTaglib AxKit::XSP::Param
AxAddXSPTaglib MyTaglibs::WeatherTaglib

AxAddStyleMap application/x-xsp Apache::AxKit::Language::XSP
AxAddStyleMap application/x-xpathscript Apache::AxKit::Language::XPathScript
AxAddStyleMap text/xsl  Apache::AxKit::Language::Sablot





SetHandler  perl-script
PerlHandler MyTaglibs::WeatherTaglibs



SetHandler  perl-script
PerlHandler Test::Test



PerlModule  Apache::PerlSections


push @Alias, [ qw(/perl/ /usr/local/apache/perl/) ];

$Location{"/perl/"} = { SetHandler  =>  "perl-script",
PerlHandler =>  "Apache::Registry",
Options =>  "+ExecCGI",
PerlSendHeader  =>  "On",
PerlSetupEnv=>  "On"
};

$PerlSetVar = "Filter On" if Apache->module('Apache::Filter');

print STDERR Apache::PerlSections->dump;






##
CODE SAMPLES

weather1.xsp:






http://www.apache.org/1999/XSP/Core";
xmlns:util="http://apache.org/xsp/util/v1";
xmlns:param="http://axkit.org/NS/xsp/param/v1";
xmlns:weather="http://olddog.acon.nl/axkit_articles/weather/";
>

Mijn weer rapportage

  









weather.xsl:
---
http://www.w3.org/1999/XSL/Transform";
>

Hi! It's 


The weather in
,
 is
 and
F
(courtesy of The
Weather Channel).
  











as_html.xsl
---
http://www.w3.org/1999/XSL/Transform";
version="1.0">




















ERROR MESSAGE form logs


[notice] Apache/1.3.23 (Unix) AxKit/1.52 mod_perl/1.26 configured --
resuming normal operations
[notice] Accept mutex: sysvsem (Default: sysvsem)
[warn] [client 127.0.0.1] [AxKit] handler called for /axkit/weather1.xsp
[AxKit] checking if we process this resource
[AxKit] media: screen, preferred style: #default
Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.6.1/i586-linux/Apache/AxKit/Cache.pm line 25.
[AxKit] Cache: key = f1e3924e8ebc61f378d51b84cb5dfec0
[AxKit] getting styles and external entities from the XML
[AxKit] styles not cached - calling $provider->get_styles()
[AxKit] using XS get_styles (libxml2)
[AxKit] calling xs_get_styles_fh()
[AxKit] calling xs_get_styles_str()
[AxKit] parse_pi: href = NULL
[AxKit] parse_pi: type = application/x-xsp
[AxKit] parse_pi: href = weather.xsl
[AxKit] parse_pi: type = text/xsl
[AxKit] parse_pi: href = as_html.xsl
[AxKit] parse_pi: type = text/xsl
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/site_perl/5.6.1/i586-linux/Apache/AxKit/Provider.pm line
256.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/site_perl/5.6

Re: "back-tracking"

[Stas Bekman]

Lucas M. Saud wrote:
> hi,
> 
> i'm writting a module to highlighting of Perl syntactical structures, but the 
>current code is very slow... :(
> 
> i need some help to implementing a method of "back-tracking" or one way to revising 
>a token that has already been formatted without reformatting the entire string? it's 
>possible?
> 
> if anyone interess, contact-me and i will send the source code...

I fail to see what this has to do with the mod_perl list :( This kind of 
questions is *not* welcome here.

__
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: Configuring mod_perl on Debian

[Stas Bekman]

Ian D. Stewart wrote:
> On 2002.05.27 12:57 Andrew McNaughton wrote:
> 
>>
>> Sounds to me like you're not setting your content-type correctly for
>> some
>> reason.  Have a look at the headers being sent out.  It's either not
>> sending this header, or it's sending something the browser doesn't
>> know
>> what to do with.
> 
> 
> This is the content of test.pl
> 
> BEGIN-SCRIPT
> -- 
> #!/usr/bin/perl
> 
> # your httpd.conf should have something like this:
> 
> # Alias /perl/  /real/path/to/perl-scripts/
> 
> # 
> # SetHandler  perl-script
> # PerlHandler Apache::Registry
> # PerlSendHeader On
> # Options +ExecCGI
> # 
> 
> print "Content-type: text/html\n\n";
> 
> print "Date: ", scalar localtime, "\n";
> 
> print "%ENV: \n", map { "$_ = $ENV{$_} \n" } keys %ENV;
> -- 
> END-SCRIPT
> 
> Based on this, I would expect the content to be set to text/html and the 
> page to be displayed to be a listing of the current environment.
> 
> Galeon identifies the content type as application/x-perl.  This would 
> seem to indicate to me that Apache is serving the script directly 
> instead of executing the script and serving the output.  According to 
> the mod_perl Guide, the ExecCGI option (which I have set for Location 
> /perl) is supposed to avoid this situation.

issue a request from the command line and look at the saved response. 
Use lwp's GET, or 'lynx -dump' or any other favorite downloading utility.

__
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: MVC advice..?

[Aaron Ross]

> Is there a neat way of dynamically loading in the appropriate control
> subclass?  Something proven and widely used.

For what it's worth, I use the eval trick too.  Although it may seem a
little clunky, I believe it is "proven and widely used".  The DBI.pm
module uses code like this to load in the DBD drivers:

my $driver_class = "DBD::$driver";
eval "package DBI::_firesafe; require $driver_class";

I'm not sure this answers your MVC questions, but maybe it will make you
feel more comfortable with your solution.

hth, aaron

RE: dso

[Joe Breeden]

I have to agree with this statement. We have a server farm with 15 apache servers 
running mod_perl as a DSO (not counting the several development and QC servers) with 
no problems. IMHO mod_perl as a DSO probably had problems in the beginning, but I 
couldn't confirm that without some research and I'm too lazy to do it, and as a result 
people now recommend compiling mod_perl into httpd. So I would say if DSO works for 
you use it, if not don't use it. 

> -Original Message-
> From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 6:54 AM
> To: Arnold van Kampen
> Cc: [EMAIL PROTECTED]
> Subject: Re: dso
> 
> 
> At 11:41 29.05.2002, Arnold van Kampen wrote:
> 
> >Hi
> >
> >Some messages ago, someone still mentioned that modperl had been
> >  - compiled in -,
> >when describing his configuration, that he was having trouble with.
> >
> >Does this mean it is still better to compile it in instead of
> >using mod_perl as a dso?
> 
> If you're having problems, it's often known to be the quick 
> answer to try. 
> If you're not having trouble, keep using DSO happily!
> 
> 
> -- 
> Per Einar Ellefsen
> [EMAIL PROTECTED]
> 
> 
> 

Re: dso

[Per Einar Ellefsen]

At 11:41 29.05.2002, Arnold van Kampen wrote:

>Hi
>
>Some messages ago, someone still mentioned that modperl had been
>  - compiled in -,
>when describing his configuration, that he was having trouble with.
>
>Does this mean it is still better to compile it in instead of
>using mod_perl as a dso?

If you're having problems, it's often known to be the quick answer to try. 
If you're not having trouble, keep using DSO happily!


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod-perl_2.0

[Per Einar Ellefsen]

At 00:25 29.05.2002, Kent, Mr. John wrote:
>Now my question.  In the older version,(126) mod-perl created a larger
>(heavy)
>webserver.  I could then add a startup.pl file to its http.conf file
>which used Apache::Registry to load perl and my modules.
>
>I don't see how this works in the new version of mod-perl, because
>I don't see a "larger" version of the httpd server anywhere.
>
>When I did the install it just seemed to load into the Perl 5.6.1 libraries.

We'll need some more information about your build process... Normally, you 
specify the Apache Prefix (or the location of apxs) when running perl 
Makefile.PL. Then, you run make for mod_perl, ./configure and make for 
Apache 2.0, make test for mod_perl and I guess finally make install on both 
parts.

You should see the mod_perl 2 installation documents: 
http://perl.apache.org/release/docs/2.0/user/index.html

>Did notice in the overview
>"The details of these optimizations from the most part are hidden from
> mod_perl users, the exception being that some will only be turned on
> with configuration directives. A few of which include:
> *   Inlined "Apache::*.xs" calls
>"
>But not sure how to use it.

This isn't really related to your question.. Look through the 
documentation, but for the most part these optimizations happen without you 
noticing.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Invoke PHP scripts?

[Andrew McNaughton]

On Wed, 29 May 2002, Thomas Klausner wrote:

> Hi!
>
> On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote:
> > I'm developing a large-ish web site in which I would like to use a
> > combination of mod_perl (90%) and PHP (10%). I have run into a
> > roadblock trying to include the output of a PHP script from a mod_perl
> > script.
> As far as I know this is rather impossible with mod_perl 1.x
>
> You can chain different perl handlers (but only perl handlers) using
> Apache::Filter, or you could let your mod_perl application issue a real http
> request (using LWP), parse the output, and then do what you want with it.

It's possible to lock up your server under heavy load if it's calling
itself via HTTP.  between that and mysql handles I prefer to have separate
apache engines for php and modperl.

Andrew

MVC advice..?

[Rafiq Ismail (ADMIN)]

Hi,

I'm building an MVC architecture site and have hit a design issue.  I have
varoius Control subclasses which relate to different templates with
different behaviour.  Now my problem is that I have to assign which
Subclass I want to instantiate, based on the script and params.  I my last
effort I went for a Shared datastructure holding (script, control module
pairs) which then allowed one to be dynamically "eval 'use..'"'ed in the
main content handler.  I found that clunky.  I'm building from scratch
again and am thinking of just firing up a template and allowing the
control to be loaded INTO the view as a template toolkit plugin.  What I
hate about this is that I'm surrendering my View layer.

Is there a neat way of dynamically loading in the appropriate control
subclass?  Something proven and widely used.

Cheers,

Fiq

"__  __   _ __  __
|  \/  | ___   __| | ___ _ __ _ __ |  \/  | __ _ _ __
| |\/| |/ _ \ / _` |/ _ \ '__| '_ \| |\/| |/ _` | '_ \
| |  | | (_) | (_| |  __/ |  | | | | |  | | (_| | | | |
|_|  |_|\___/ \__,_|\___|_|  |_| |_|_|  |_|\__,_|_| |_|
a pathetic example of his organic heritage"
- Bad Religion

Re: Invoke PHP scripts?

[Thomas Klausner]

Hi!

On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote:
> I'm developing a large-ish web site in which I would like to use a
> combination of mod_perl (90%) and PHP (10%). I have run into a
> roadblock trying to include the output of a PHP script from a mod_perl
> script.
As far as I know this is rather impossible with mod_perl 1.x

You can chain different perl handlers (but only perl handlers) using
Apache::Filter, or you could let your mod_perl application issue a real http
request (using LWP), parse the output, and then do what you want with it.

Apache 2.0 (and mod_perl 2.0) (both in BETA) can do what you want unsing
Filters.



-- 
 D_OMM  +>  http://domm.zsi.at <-+
 O_xyderkes |   neu:  Arbeitsplatz   |   
 M_echanen  | http://domm.zsi.at/d/d162.html |
 M_asteuei  ++

dso

[Arnold van Kampen]

Hi

Some messages ago, someone still mentioned that modperl had been
 - compiled in -, 
when describing his configuration, that he was having trouble with.

Does this mean it is still better to compile it in instead of
using mod_perl as a dso?



Arnold