[Zope] Broken products after transferring Data.fs file

[Tres Seaver]

"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