Re: failure to require an installed module + eval fails to trap?

[syphilis]

Just for kicks I have tried "using" the module as well to no effect

I presume that means the module loaded ok. (Please correct me if that's wrong.)

Should it not be blowing at the die line below it?

There's no "die" in the snippet of code (lines 35 to 43) that you've given.
Update: but there is a "die" at the next line (line 44) - and that's where the script is, in fact, dying.
However, because, $err ends with a newline, you don't get the "at line 44" in relation to the die.
The "at line 39" is where the error occurred - not where the script died.
If you chomp $err; before you die($err); you should see what I mean.

I can't put my finger on the reason for the "Can't locate Apache::Session::Postgres" error. Perhaps related to some permissions problem ?
I seem to recall that there have been occasions where "Can't locate" should really have been "Can't load" - because the module was actually located ok, but could not be loaded (because of permissions issues).

What does the following command output:

perl -MApache::Session::Postgres -le 'print "@INC";'

Cheers,
Rob

[Keep]

The output of:

perl -MApache::Session::Postgres -le 'print "@INC"'
/opt/m42c/managed/opt/perl/5.8.9/lib/5.8.9/x86_64-linux /opt/m42c/mana
+ged/opt/perl/5.8.9/lib/5.8.9 /opt/m42c/managed/opt/perl/5.8.9/lib/sit
+e_perl/5.8.9/x86_64-linux /opt/m42c/managed/opt/perl/5.8.9/lib/site_p
+erl/5.8.9 .

As I would expect. Also, using <% Dumper(\@INC) %> from inside of a mason component yeilds the same result; (Since Environments can change).

Permissions are not the issue, as the webserver runs as the same user as the module installer, (The whole kit is frameworked into /opt/m42c to isolate everything from any system dependencies. This makes things pretty portable, as long as everything is installed in the same place on a different machine. I'm sure you guys have seen this approach many many times.

Also, I am aware of "require" being far different from "use" and that its use is special.

And switching to "use" actually does not load the module at all, in fact, it wont even pass tests with use, complaining that $sessionClass has not been declared:

[amps@autotech M42C-Web]$ make test
PERL_DL_NONLAZY=1 "/opt/m42c/managed/opt/perl/5.8.9/bin/perl5.8.9" "-M
+ExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::
+Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/M42C-Web.t .. Failed 1/1 subtests 

Test Summary Report
-------------------
t/M42C-Web.t (Wstat: 11 Tests: 0 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=1, Tests=0,  1 wallclock secs ( 0.02 usr  0.01 sys +  0.04 cusr 
+ 0.02 csys =  0.09 CPU)
Result: FAIL
Failed 1/1 test programs. 0/0 subtests failed.
make: *** [test_dynamic] Error 255

But that isn't why I chose to use require. I am simply not importing anythi
ng from Apache::Session::Postgres, why would I not require it? Even still the error I get from "using" the Module is concerning at best. (The line containing the import() was not originally there, and I was just testing something quick.).

You were correct though, chomp($@) placed the blame on the offending line. - I don't eval {} often from within a module, I tend to do that at the GUI level.

Also worth noting that installing the module anyway, despite failing make test, throws a seg fault when it's used.

[syphilis]

I think tye has picked it.
$sessionClass is presumably the string 'Apache::Session::Postgres', but it needs to be the string 'Apache/Session/Postgres.pm'.
At least, the error message implies that there's a require 'Apache::Session::Postgres' being done somewhere ... and that needs to be changed to require 'Apache/Session/Postgres.pm'

Cheers,
Rob

[Keep]

in: M42C::Web::Session::new end of the sub, should be: return $self, NOT return $class. THAT Fixed a lot of issues. Because I chose to return a string instead of a blessed refrence: $self->{_r}->dir_config->get("M42CSessionClass")

Had no value, however confused perl may have been I'm fairly sure there should have been an error about calling methods on a non package *anything.

So there you have it. I feel like an idiot now. :P Thanks for the help though, and I did end up switching to "use" simply because it's easier. I'll consider revising it later XD after testing on a few databases.

[Keep]

$class->do_something, != $self->do_something. I was absolutely exhausted writing that code, and after some much needed sleep (+ a day at the water park with the fam) + more sleep, i saw the bug strait off and fixed everything up. Much thanks to those that looked over that montage of code.