This is most likely my own doing as I'm attempting to upgrade an existing WebWork 2.1 installation. Front page of WW2 loads fine. When I attempt to login to Course Administration I receive the following error page:
...
Can't locate object method "status_abbrev_has_behavior" via package "WeBWorK::CourseEnvironment" at /opt/webwork2/lib/WeBWorK/Authen.pm line 312.
...
in WeBWorK::Authen::check_user called at line 221 of /opt/webwork2/lib/WeBWorK Authen.pm
in WeBWorK::Authen::do_verify called at line 150 of /opt/webwork2/lib/WeBWorK/Authen.pm
in WeBWorK::Authen::verify called at line 275 of /opt/webwork2/lib/WeBWorK.pm
Interestingly when I try to login as a nonexistent user, I get the correct error (the red Invalid User ID or Password). I installed WW2 in /opt/webwork2 and made, I thought, all of the changes in the conf files for the directory change. We have WW 1.9 running in /opt/webwork/.
RH AS 4, Apache 1.3, check_modules.pl returns 2 Apache2 modules missing (but I figure that's OK), perl 5.8.5
I tried upgrading the old mysql dbs and then moving the old mysql dbs and creating a new webwork db according to the install docs.
Any ideas where I should look to correct this error?
Thanks and take care,
Nathan
My guess is that one of the files didn't upgrade properly, or possibly a mismatch between the database.conf/global.conf versions and the other .pm files.
I recommend typing
cvs update -r rel-2-3-dev
in your webwork2 directory to get a stable version of WeBWorK that has most of the new features (but not the bleeding edge stuff that we are currently debugging)
Make sure that you get the same version for the conf/ directory
and then go through and compare the global.conf and global.conf.dist and database.conf and database.conf.dist files.
Checking the .conf files, upgrading the mysql database (using webwork2/bin/wwdb_upgrade) all seem the right approaches. I think that one of the updates didn't take for some reason.
Hope this helps.
Take care,
Mike
I recommend typing
cvs update -r rel-2-3-dev
in your webwork2 directory to get a stable version of WeBWorK that has most of the new features (but not the bleeding edge stuff that we are currently debugging)
Make sure that you get the same version for the conf/ directory
and then go through and compare the global.conf and global.conf.dist and database.conf and database.conf.dist files.
Checking the .conf files, upgrading the mysql database (using webwork2/bin/wwdb_upgrade) all seem the right approaches. I think that one of the updates didn't take for some reason.
Hope this helps.
Take care,
Mike
Did as you suggested with CVS. And went through the conf files- actually replaced the old conf files with the .dist files and edited those (starting from scratch so to speak). So far no joy. But the day is still young!
Thanks and take care,
Nathan
Thanks and take care,
Nathan
In lines 312 -- 335 of WeBWorK/CourseEnvironment.pm you should see something like:
=item status_abbrev_has_behavior($status_abbrev, $behavior)
Return true if the status abbreviated by $status_abbrev lists $behavior.
=cut
sub status_abbrev_has_behavior {
my ($ce, $status_abbrev, $behavior) = @_;
if (not defined $status_abbrev or $status_abbrev eq "") {
carp "status_abbrev_has_behavior: status_abbrev (first argument) must be defined and non-empty";
return;
}
if (not defined $behavior or $behavior eq "") {
carp "status_abbrev_has_behavior: behavior (second argument) must be defined and non-empty";
return;
}
my $status_name = $ce->status_abbrev_to_name($status_abbrev);
if (defined $status_name) {
return $ce->status_has_behavior($status_name, $behavior);
} else {
warn "status abbreviation '$status_abbrev' not found in \%statuses -- assuming no behaviors.\n";
}
}
also make sure that the permissions for all of these .pm files allows them to be read by the webserver (although it seems unlikely that would be the problem here).
-- Mike
=item status_abbrev_has_behavior($status_abbrev, $behavior)
Return true if the status abbreviated by $status_abbrev lists $behavior.
=cut
sub status_abbrev_has_behavior {
my ($ce, $status_abbrev, $behavior) = @_;
if (not defined $status_abbrev or $status_abbrev eq "") {
carp "status_abbrev_has_behavior: status_abbrev (first argument) must be defined and non-empty";
return;
}
if (not defined $behavior or $behavior eq "") {
carp "status_abbrev_has_behavior: behavior (second argument) must be defined and non-empty";
return;
}
my $status_name = $ce->status_abbrev_to_name($status_abbrev);
if (defined $status_name) {
return $ce->status_has_behavior($status_name, $behavior);
} else {
warn "status abbreviation '$status_abbrev' not found in \%statuses -- assuming no behaviors.\n";
}
}
also make sure that the permissions for all of these .pm files allows them to be read by the webserver (although it seems unlikely that would be the problem here).
-- Mike
Still no luck. The lines you list above for CourseEnvironment.pm are right where they should be.
I checked the mod_perl modules at perl-status?inc and the WebWork course environment shows up. After installing Devel::Symdump, I see these functions in the CourseEnvironment:
WeBWorK::CourseEnvironment::debug, WeBWorK::CourseEnvironment::empty_opset, WeBWorK::CourseEnvironment::new, WeBWorK::CourseEnvironment::readFile
Anything missing from that listing?
The mod_perl listing is pretty long- but includes WW Debug & Utils along with CourseEnv. That listing gives the versions of the various modules which may be important as this webserver install is 2 years old now. Could that be the case?
Thanks and take care,
Nathan
I checked the mod_perl modules at perl-status?inc and the WebWork course environment shows up. After installing Devel::Symdump, I see these functions in the CourseEnvironment:
WeBWorK::CourseEnvironment::debug, WeBWorK::CourseEnvironment::empty_opset, WeBWorK::CourseEnvironment::new, WeBWorK::CourseEnvironment::readFile
Anything missing from that listing?
The mod_perl listing is pretty long- but includes WW Debug & Utils along with CourseEnv. That listing gives the versions of the various modules which may be important as this webserver install is 2 years old now. Could that be the case?
Thanks and take care,
Nathan
I'd expect to see things like
WeBworK::CourseEnvironment::status_name_to_abbrevs
and
WeBworK::CourseEnvironment::status_abbrev_to_name
in the listing from Devel::Symdump.
I think there might be something wrong with the CourseEnvironment file -- perhaps
a missing blank line before or after a =cut in the pod documentation? It looks like it is reading the "new" subroutine but not the subroutine immediately following that.
WeBworK::CourseEnvironment::status_name_to_abbrevs
and
WeBworK::CourseEnvironment::status_abbrev_to_name
in the listing from Devel::Symdump.
I think there might be something wrong with the CourseEnvironment file -- perhaps
a missing blank line before or after a =cut in the pod documentation? It looks like it is reading the "new" subroutine but not the subroutine immediately following that.
Aha. Turns out apachectl restart (on apache 1.33 built by me) does not reread or reload the perl system. However a complete apache shutdown and startup does. So apache was using an old perl CourseEnvironment.pm module (I guess perl never reloaded) ... even though if I made a change to the existing CourseEnvironment.pm module an apachectl configtest would fail. So in my Redhat world, I needed to do a
service httpd stop
service httpd start
instead an an
apachectl restart
From http://www.server.../perl-status
...running since Tue Apr 17 09:45:55 2007
apachectl restart
...running since Tue Apr 17 09:45:55 2007 (though apache pid changes)
service httpd stop
service httpd start
...running since Tue Apr 17 09:56:08 2007
Or at least I think that is what's going on.
Learn something new every day. Thanks for your help as that was a bit devilish. And now I know a lot more about how perl modules interact with Apache.
Take care,
Nathan
service httpd stop
service httpd start
instead an an
apachectl restart
From http://www.server.../perl-status
...running since Tue Apr 17 09:45:55 2007
apachectl restart
...running since Tue Apr 17 09:45:55 2007 (though apache pid changes)
service httpd stop
service httpd start
...running since Tue Apr 17 09:56:08 2007
Or at least I think that is what's going on.
Learn something new every day. Thanks for your help as that was a bit devilish. And now I know a lot more about how perl modules interact with Apache.
Take care,
Nathan
Glad it's resolved. For what it is worth my apachectl will reload perl when called with
apachectl graceful
which supposedly shuts down and restarts the apache children while they are between handling web requests (so that no request is dropped). YMMV.
-- Mike
apachectl graceful
which supposedly shuts down and restarts the apache children while they are between handling web requests (so that no request is dropped). YMMV.
-- Mike