"Brian K. Holdsworth" <bhold@awod.com> wrote:
I have seen a number of threads that talk about products becoming broken in a Zope installation with no apparent cause. I had a similar experience the other day. I moved my Data.fs file, which included several third-party and custom made ZClass Products, from one server to another. After moving the file, many of the ZClass Products were broken on the new server.
In order to fix this, I ended up also moving the complete contents of my lib/python/Products directory tree from the old server to the new one. This fixed everything. However, most of the products that were orginally broken did not depend on anything that was in the Products directory. Here is my best analysis of what might have happened:
One of the Products I was using was based on the "Renderable" add-on product which is installed into the lib/python/Products directory. Initially, I did not have this product on the new server. What I think happended is that the abscence of this product caused several other unrelated products to appear broken, even though they did not use "Renderable." If anybody can confirm this through similar experiences, we can probably get the problem fixed in the code.
I'm pretty sure that this is the same problem that the PTK list discussed last week. It appears that, during Zope's startup, "one bad apple ... spoil[s] the whole bunch, girl" -- i.e., a Product which barfs (due to missing dependencies, in particular) seems to abort the whole product loading process. Most product's are hardened against exceptions thrown during their initialize() functions; this kind of problem could occur, however, during the module import. For instance:: # $INSTANCE_HOME/lib/Python/FooProduct.__init__.py import Foo # if this throws, nobody catches it? def initialize( context ): """ Initialize our product classes.""" try: # capture traceback to show on our management interface context.registerBaseClass( Foo.FooClass, 'FooBase' ) except: # throw all exceptions on stderr import sys, traceback, string type, val, tb = sys.exc_info() sys.stderr.write( string.join( traceback . format_exception( type, val, tb ) , '' ) ) del type, val, tb We probably need to harden the Zope product traversal process against exceptions triggered at "module scope".
While this is an annoying problem, I am still BLOWN AWAY by how good Zope is. What I didn't mention yet is that the old server was an Intel box running Linux and the new server is a Sparc box running Solaris. I am very impressed that my application and data moved from one platform to the other so seamlessly. It is really awesome that Zope and the ZODB files that it uses are so cross-platform friendly! Bravo to the developers!
Amen, brother! Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com