Hi, I found a problematic corner case in the interaction between two zconfig directives: If I set the "products" directive to a value other than the standard ones (SOFTWARE_HOME/Products or INSTANCE_HOME/Products) AND set the container-class directive of the <zodb_db> section to a class that is only available inside the alternate "products" directory specified above, then Zope completely fails to start-up with a configuration error. Reproducing this error is simple. Just set the "products" directive to, say, $INSTANCE/../Products; put, say, CMF or Plone in there; add another <zodb_db> section, for instance: <zodb_db mounttest> <filestorage> path $INSTANCE/var/mounttest.fs </filestorage> mount-point /mounttest container-class Products.CMFPlone.PloneFolder.PloneFolder </zodb_db> Change the container-class directive to a class that only exists in "../Products" (like Products.CMFPlone.PloneFolder.PloneFolder or Products.CMFCore.PortalFolder.PortalFolder). Finally, try to startup Zope. It will fail with something like: Error: The object named by "Products.CMFPlone.PloneFolder.PloneFolder" could not be imported (line 862 in file:///home/leo/opt/enfold/etc/zope.conf) For help, use /opt/zopes/Zope-2.7.2/lib/python/Zope/Startup/run.py -h If you comment out the new <zodb_db> section, Zope starts up fine, and CMF and Plone work ok, proving that the "produtcts" directive work on it's own. If instead of commenting out the new <zodb_db> section, you just move your products back to the standard $INSTANCE_HOME/Products location, Zope also starts up ok, proving that the "container-class" directive works (or at least doesn't keep Zope from starting up). I'm just mentioning this here before filing a collector entry to see if I'm not forgetting something obvious or if others have found the same behaviour. This behaviour is problematic for Windows users with, say, multiprocessor machines, who want to maintain a consistent setup between various ZEO clients, as this forces them to copy products between instances instead of keeping them in a shared location. It's obvious that the "container-class" directive is being "evaluated" much earlier than the "products" directive. Without delving further into the code, it looks like the "container-class" directive has an error checking built right into the directive type that tries to import the assigned class, while the "products" direcive will only be made effective AFTER all ZConfig configuration has been processed... Any pointers? Should this go right into the collector? Cheers, Leo -- Leonardo Rochael Almeida <leo@enfoldsystems.com> Enfold Systems - http://www.enfolsystems.com/