headers
Issac Goldstand | 2 Oct 2008 11:48
Gravatar

CFP Open For ApacheCon Europe 2009


The Call for Papers for ApacheCon Europe 2009, to be held in Amsterdam,
from 23rd to 27th March, is now open! Submit your proposals at
http://eu.apachecon.com/c/aceu2009/cfp/ before 24th October.

Remember that early bird prices for ApacheCon US 2008, to be held in New
Orleans, from 3rd to 7th November, will go up this Friday, at midnight
Eastern time!

Sponsorship opportunities for ApacheCon US 2008 and ApacheCon EU 2009
are still available. If you or your company are interested in becoming a
sponsor, please contact Delia Frees at delia <at> apachecon.com for details.

*******

If you want all the details:

ApacheCon Europe 2009 - Leading the Wave of Open Source
Amsterdam, The Netherlands
23rd to 27th March, 2009

Call for Papers Opens for ApacheCon Europe 2009

The Apache Software Foundation (ASF) invites submissions to its official
conference, ApacheCon Europe 2009. To be held 23rd to 27th March, 2009
at the Mövenpick Hotel Amsterdam City Centre, ApacheCon serves as a
forum for showcasing the ASF's latest developments, including its
projects, membership, and community. ApacheCon offers unparalleled
educational opportunities, with dedicated presentations, hands-on
trainings, and sessions that address core technology, development,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Carmody | 3 Oct 2008 11:25
Picon
Favicon

live and dev versions of a module on the same server

I'm trying to run both the live and dev versions of my website using virtual hosting in Apache 1.3, and using
mod_perl 1.29 (on Debian stable, for reference).

The problem I'm having is that the package namespaces for the two handlers, and every module they require,
clash. I might need different  <at> INCs too. How have people got around this problem in the past?

Phil
--

-- 
()  ASCII ribbon campaign      ()    Hopeless ribbon campaign
/\    against HTML mail        /\  against gratuitous bloodshed

[stolen with permission from Daniel B. Cristofani]
Permalink | Reply | 7 comments |
headers
Philip M. Gollucci | 3 Oct 2008 16:34

Re: Mod_Perl and Net::SMTP

Guy Alston wrote:
  Error message:
> Can't call method "mail" on an undefined value at 
> sys:/perl/web/mailtest2.pl line 6.
>  
> It's always a line containing " $smtp = Net::SMTP->new("smtpserver")

Net::SMTP is known to work, though I'm not currently using it.
You could add

local $SIG{__WARN__} = \&Carp::cluck;
local $SIG{__DIE__}  = \&Carp::confess;

This will help tell you where in Net::SMTP you are having a problem.

Once you know that, you can try to fix it.

OR this works --

use MIME::Lite ();

sub email {
     my %args =  <at> _;

     my $email = MIME::Lite->new( Type => 'multipart/mixed' );

     $email->add(To      => $args{to});
     $email->add(BCC     => $args{bcc});
     $email->add(From    => $args{from});
     $email->add(Subject => $args{subject});
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Peters | 3 Oct 2008 17:48
Favicon
Gravatar

Re: live and dev versions of a module on the same server

Phil Carmody wrote:

> The problem I'm having is that the package namespaces for the two handlers, and every module they require,
clash. I might need different  <at> INCs too. How have people got around this problem in the past?

It's not a mod_perl problem. This is just how Perl works. You can't have 2 packages with the same 
name. Period. Sometimes it's easy to think that Apache's VHosts are using different Perl 
interpreters, but they aren't. Within the same process it's all the same interpreter.

So, if you want something similar to your original goal I see the following options:

1) Use a separate Apache. This isn't as hard as it sounds. And if you already have a proxy in front 
(which you should) it's even easier. Just have some mod_redirect rules which send requests for your 
dev version to a different port and have your other dev apache listening on that port. You don't 
even need another machine.

2) Rename your dev module to something like Dev::OriginalModuleName. You could have some automated 
scripts that process your dev code to remove these before sending it to production.

I like #1. I use it all the time for things like this and it works great. Complete separation 
between the code. Since each Apache has a different  <at> INC you can also do things like testing out 
upgraded versions of CPAN modules, etc. I personally wouldn't do #2 since it means that the code you 
test out isn't exactly the same code that you push to production. That would bother me.

--

-- 
Michael Peters
Plus Three, LP
Permalink | Reply | 3 comments |
headers
John Drago | 3 Oct 2008 18:48
Picon
Favicon
Gravatar

Re: live and dev versions of a module on the same server


--- On Fri, 10/3/08, Phil Carmody <thefatphil <at> yahoo.co.uk> wrote:

> From: Phil Carmody <thefatphil <at> yahoo.co.uk>
> Subject: live and dev versions of a module on the same server
> To: modperl <at> perl.apache.org
> Date: Friday, October 3, 2008, 3:25 AM
> I'm trying to run both the live and dev versions of my
> website using virtual hosting in Apache 1.3, and using
> mod_perl 1.29 (on Debian stable, for reference).
> 
> The problem I'm having is that the package namespaces
> for the two handlers, and every module they require, clash.
> I might need different  <at> INCs too. How have people got around
> this problem in the past?
> 
> Phil
> -- 
> ()  ASCII ribbon campaign      ()    Hopeless ribbon
> campaign
> /\    against HTML mail        /\  against
> gratuitous bloodshed
> 
> [stolen with permission from Daniel B. Cristofani]

There are a few options:

1---
Run your VirtualHost with PerlOptions +Parent.
This gives each VirtualHost its own Perl interpreter.
(Continue reading)

Permalink | Reply | 2 comments |
headers
adam.prime | 3 Oct 2008 21:07
Picon
Picon
Favicon
Gravatar

Re: live and dev versions of a module on the same server

Quoting John Drago <jdrago_999 <at> yahoo.com>:
>
> There are a few options:
>
> 1---
> Run your VirtualHost with PerlOptions +Parent.
> This gives each VirtualHost its own Perl interpreter.

This is mod_perl 2 specific, and until right now i personally was  
completely unaware of it.  Has anyone actually used it?  Does it work  
under all the MPM's?

Adam
Permalink | Reply | 1 comment |
headers
Philip M. Gollucci | 3 Oct 2008 21:40

Re: live and dev versions of a module on the same server

adam.prime <at> utoronto.ca wrote:
> Quoting John Drago <jdrago_999 <at> yahoo.com>:
>>
>> There are a few options:
>>
>> 1---
>> Run your VirtualHost with PerlOptions +Parent.
>> This gives each VirtualHost its own Perl interpreter.
> 
> This is mod_perl 2 specific, and until right now i personally was 
> completely unaware of it.  Has anyone actually used it?  Does it work 
> under all the MPM's?

I've played with it and it works, but not in production or anything.  I 
think Torsten uses/used it.
Permalink | Reply | 0 comments |
headers
Phil Carmody | 3 Oct 2008 22:25
Picon
Favicon

Re: live and dev versions of a module on the same server

--- On Fri, 10/3/08, Michael Peters <mpeters <at> plusthree.com> wrote:
> Phil Carmody wrote:
> > The problem I'm having is that the package
> > namespaces for the two handlers, and every module they
> > require, clash. I might need different  <at> INCs too. How have
> > people got around this problem in the past?
> 
> It's not a mod_perl problem. This is just how Perl
> works. You can't have 2 packages with the same 
> name. Period. Sometimes it's easy to think that
> Apache's VHosts are using different Perl 
> interpreters, but they aren't. Within the same process
> it's all the same interpreter.

I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2. That
might make my "how to go live" decisions trickier for other projects which I'm not prepared to host on my
home machine.

> So, if you want something similar to your original goal I
> see the following options:
> 
> 1) Use a separate Apache. This isn't as hard as it
> sounds. And if you already have a proxy in front 
> (which you should) it's even easier. Just have some
> mod_redirect rules which send requests for your 
> dev version to a different port and have your other dev
> apache listening on that port. You don't 
> even need another machine.

After working out that I was never going sensibly going to be able to get the modules to name themselves on the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Perrin Harkins | 3 Oct 2008 22:39

Re: live and dev versions of a module on the same server

On Fri, Oct 3, 2008 at 4:25 PM, Phil Carmody <thefatphil <at> yahoo.co.uk> wrote:
> I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2.

No, they typically just offer CGI.  This is not an issue with CGI
because you're spawning a whole new Perl interpreter for every
request.  For mod_perl or FastCGI you need to use one of the
suggestions in this thread.

- Perrin
Permalink | Reply | 1 comment |
headers
Scott Gifford | 5 Oct 2008 05:21
Gravatar

Re: live and dev versions of a module on the same server

"Perrin Harkins" <perrin <at> elem.com> writes:

> On Fri, Oct 3, 2008 at 4:25 PM, Phil Carmody <thefatphil <at> yahoo.co.uk> wrote:
>> I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2.
>
> No, they typically just offer CGI.  This is not an issue with CGI
> because you're spawning a whole new Perl interpreter for every
> request.  For mod_perl or FastCGI you need to use one of the
> suggestions in this thread.

And the interesting thing about CGI and mod_perl being basically
independent is that running your development code as a CGI script is a
great way to test it.  I write my code using CGI.pm, which will use
mod_perl if it's run under mod_perl, or act as a regular CGI script if
it is not.  If the development version of my script is run, it adds
the development library path to  <at> INC (with "use lib"); otherwise it
adds the production library path.  Between those two things I get a
development environment which is basically seperate from my production
environment, although it is much slower.  I have had very good luck
with this approach.

Still, I keep another Apache instance around to do the final testing.
That's useful too, especially on the rare occasion that the behavior
is different.

----Scott.
Permalink | Reply | 0 comments |

Gmane