Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <5037EA05.50408@rubystudio.com>
Date: Fri, 24 Aug 2012 16:54:29 -0400
From: RS Tech <tech@rubystudio.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: modperl@perl.apache.org
Subject: problem moving mod_perl app from Linux to Windows
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'm trying to migrate a mod_perl application from Linux, where it works 
beautifully, to a Windows 2008 virtual machine, where it ain't doing so 
hot. Been trying to track down the problem for many a day. I'm stuck.

The application in question is a front-end for a WSDL service. I'm using 
mod_perl to serve the site/UI and XML->Compile to manage data. Again, 
all works perfectly on Linux/Apache2/mod_perl -- and snippets of the 
code in question work fine on Windows when pulled out of Apache and run 
as standalone Perl scripts. But when running as a mod_perl application 
on Windows (Win2008 VM/Apache2.2/modperl w/Perl 5.12 versions of either 
Strawberry or ActivePerl), XML parsing breaks with the following error:

'error' => 'Can\'t call method "parse_string" on unblessed reference at 
C:/Perl/site/lib/XML/Compile/Transport.pm line 77.

I've tried tracing the calls. The first part of a request looks 
identical across working and breaking versions -- the XML is retrieved 
and looks good, but in the Windows/Apache2 environment, the parser 
object isn't getting set up -- or maybe it's getting set up and then 
breaking.

A critical point here -- in XML::Compile::Transport on Windows, $parser 
is getting set to '\undef' -- it should be getting set like this:

$VAR1 = bless( {
	'_State_' =>  0,
	'XML_LIBXML_PARSER_OPTIONS' =>  528390
},  'XML::LibXML' );


Not much to go on, I realize, but for all my troubleshooting, I just 
don't know where the problem is. Best guess here is that since the code 
works in the Linux/Apache/mod_perl setting -- and relevant pieces of the 
code (the pieces that are breaking as mod_perl) also work in Windows 
when executed as standalone scripts -- that there must be some critical 
difference in the Windows/Apache/mod_perl environment that's breaking 
the Perl structures.

Has anyone run into similar problems? Any suggestions would be much 
appreciated.

Thanks,
Richard