Re: [Zope-dev] ZEO install/runtime issues

2003-05-29 Thread Dieter Maurer 
Jeremy Hylton wrote at 2003-5-27 14:38 -0400:
  ...
  The problem with sharing software is that the ZEO server can load
  arbitrary modules when it attempts to perform conflict resolution.  If
  there is a conflict for an instance of class A.B.C, then ZEO will load
  A.B.C and see if it has an _p_resolveConflict() method.  If the modules
  A or B have any side-effects at import time, then those side-effects
  will occur in the ZEO server.  I've seen this method lookup cause all of
  CMF to get imported and try to initialize itself.  This ended up brining
  down the ZEO server.

That sounds bad...

Products may well have classes which require conflict resolution
(see e.g. QueueCatalog). It would be very tedious to let
ZEO see only the classes, keep them importable for ZEO but
remove everything else.

Can we find a better solution, maybe, some kind of configuration
which lists are classes which may have conflict resolution?



Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ZEO install/runtime issues

2003-05-29 Thread Richard Jones 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday, May 28, 2003, at 04:38 AM, Jeremy Hylton wrote:
[Please followup to zodb-dev.]

You made some changes to the mkzeoinst.py script in April.  I was busy
then, and I've just had a chance to look at the changes now.  I'd like
to discuss some of the changes, and I'm including a wider discussion
list to make sure we include anyone else who is interested.
A number of the changes are Zope specific.  (For example, you can't 
even
run mkzeoinst.py without having a directory named Zope hanging off of
sys.path.)  ZEO and ZODB are intended for use separately from the rest
of Zope, so we need to find a way to factor this out into a generic
configuration and a Zope-specific configuration.
Go for it :)  [I'm in hard-core product development mode for a few 
months, so apart from critical Zope bugfixes along the way I'll not 
really be much use, sorry ... even Roundup is taking the back seat for 
a while ;)]

Perhaps Zope's mkzeoinstance should have all that Zope-specific stuff, 
and only hook into the mkzeoinst module for some of the generic 
functions. there may even be some more potential for sharing of code 
between mkzeoinstance and mkzopeinstance.


The other question I have is about the organization of software into a
Zope home and an instance home.  I'm not sure what the history of this
arrangement is, but I recommend that people do not configure their ZEO
servers to share software with their Zope app servers.  It can cause
fairly severe problems!
I was completely unaware of this, and have always run ZEO servers with 
the full complement of Products. I have no immediate suggestion for a 
solution to this problem. The big issue is really how are (potentially 
dumb, point-n-click) users to know that they need to install product 
X in their ZEO server but not product Y? Dieter's solution of some 
configuration variable controlling this sounds like a really good idea, 
if possible.

Richard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE+1ZI4rGisBEHG6TARApA1AJ9V5Vy/FD8Dx7Nyp2lcXhTgDuAokwCeJqLJ
gbubTTKmtV/Heyush75rW44=
=qVyG
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )