OpenSRF.pm AUTOLOAD complicates testing / serves little purpose

[Bill Erickson]

OpenSRF.pm contains an AUTOLOAD handler which warns when unimplemented subs are called. The original purpose was to log calls to nonexistent subs to the opensrf logs. While this may be helpful, the fact that the AUTOLOAD results in a value of "1" (the result of the final warn()), nonexistent subs do not cause execution to stop. Instead, the code continues using a value of "1" as the result of the bogus call. This can result in very confusing problems, particularly when testing new code.

Removing the AUTOLOAD will allow Perl to produce similarly useful error messages while also stopping code execution (unless captured by an eval/try). For example, removing the AUTOLOAD on a test system produces the following error when calling a nonexistent sub, invoked from srfsh:

Received Exception:
Name: osrfMethodException
Status: *** Call to [open-ils.actor.user.retrieve] failed for session [1368474564.335152.136847456411193], thread trace [1]:
Undefined subroutine &OpenILS::Application::Actor::foobar called at /usr/local/share/perl/5.10.1/OpenILS/Application/Actor.pm line 1154.

-----

WARNING: Removing AUTOLOAD means any code which relies (intentionally or otherwise) on the lax nature of nonexistent sub handling in OpenSRF will now die with a fatal error, whereas before it may have limped along. Evergreen users, I'm talking to you! Of particular interest will be ensuring the open-ils.storage CDBI entries are kept in sync with the IDL (as needed), as this is a common cause of calls to nonexistent subs in Evergreen.

Patch coming shortly.

[Bill Erickson (berick)]

Patch pushed to working/user/berick/lp1179660-kill-autoload

[Galen Charlton (gmc)]

I've linked this bug to Evergreen as well, since CDBI subclasses defined there have historically been prone to not being fully synchronized with the schema, and removing the autoload will convert those mistakes into (run-time, alas) fatal errors. I do think that they *should* be fatal errors, but we should fix the ones we know about first.

I've also removed the milestone targeting for the moment -- if we can get away with releasing it just for OpenSRF 2.2.x, that would be my preference. Regardless, related Evergreen fixes (if any) will probably have to be backported to all supported Evergreen release branches, since we don't say that older Evergreen version series *must* use older OpenSRF versions.

[Bill Erickson (berick)]

I've started testing this with Evergreen. So far, I've only poked around the TPAC and run the hold targeter. I've found one fatal error in Search/Z3950.pm. I've started a branch to collect Evergreen repairs and pushed a fix for the Z39 issue.

Evergreen -> working/collab/berick/lp1179660-eg-opensrf-autoload-repairs

[Galen Charlton (gmc)]

To get some movement on this, I've pushed the one EG commit in working/collab/berick/lp1179660-eg-opensrf-autoload-repairs to Evergreen master, and I will soon push the OpenSRF commit to OpenSRF master.

This means that there is a decent chance that Evergreen master running on OpenSRF master may see some breakage, though i will do as much testing as I can in Evergreen master first.

[Galen Charlton (gmc)]

I've committed the OpenSRF patch to master. Thanks, Bill!

[Galen Charlton (gmc)]

By virtue of when I pushed it, it's been in Evergreen rel_2_6 since the beginning. I've now pushed it to rel_2_5 so that 2.5.x can work with OpenSRF 2.4 once it's realized.