Description

The exception I get is:
{quote}Zend_Application_Bootstrap_Exception: Resource matching "freak_application_resource_acl" not found in /home/dolf/Projects/Kandelaaronline/website/application/library/Zend/Application/Bootstrap/BootstrapAbstract.php on line 685{quote}

I'm not sure that there is an issue here at all. I suspect that loading a custom resource by passing the class name as a string was perhaps an unintended side effect of the previous use of class_exists(). Matthew would have to comment on that.

In any case, the manual states "As long as you register the prefix path for this resource plugin, you can then use it in your application."

Can't you just set your plugin path first instead of relying on autoloading?

Actually, Dolf, Graham's example DOES work, assuming (a) the class has been loaded previously or (b) the class may be autoloaded.

In fact, I have serious doubts if that commit is the one that caused your problems. The exception line mentioned in your report is in the _executeResource() method, and indicates that the bootstrap was unable to find either a class or plugin resource matching the name provided. The class_exists() call is within getPluginResource, which is called on line 673, and by proxy on line 671 when hasPluginResource is called.

I have personally tested the following situations:

adding a pluginPaths. entry, and using the resource's short name

adding a pluginPaths. entry, and using the resource's full class name

using only the resource's full class name, and manually require'ing the classfile

In all of the above cases, it works perfectly -- the resource is loaded without error. I only get the error message you describe if the class does not exist or is not loadable via the plugin path specified -- which is exactly how it should work.

I think you misidentified the source of the error -- that class_exists() call is actually now more lenient than it was previously in that it now allows a lookup by the autoloader. The previous situation did not do autoloading -- and the only way this would cause a conflict is if your class name could match the path of another class on the include_path. In that particular case, the issue is on your end.

I'm closing this issue; please re-open if you can provide a reproduce case.

I did add a reproduce case (which took me in turn 3 hours to get zend_tool up and running which didn't work on php5.3 (ralph has more details)) through zend_tool a few days ago as discussed on IRC. The reproduce project has been attached to this issue. The project resembles the situation perfectly. If I undo what was done in r17414 everything works at once. Applying r17414 breaks everything immediately.