[Zope-dev] ZConfig issue: "products" and "container-class"

[Leonardo Rochael Almeida]

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 at enfoldsystems.com>
Enfold Systems - http://www.enfolsystems.com/