Re: [Zope-CMF] Re: Problem with Registering Local Utilities on reinstall of product

2008-06-17 Thread Wichert Akkerman
Previously Hanno Schlichting wrote:
 The code here does seem indeed to be wrong. There's two modes for GS 
 import handlers, one being with purge and one without. The code in 
 question does not support that correctly. It does work in some cases, as 
 the underlying registerUtility function first checks if the component 
 was already registered. It does so effectively by checking the newly 
 registered object and the one that is already registered for equality. 
 This check obviously fails in case of creating a new utility via a factory.

This is due to an underlying problem in the ZCA that hurts GenericSetup
in several places: it is impossible to determine if a factory or an object
was registered. Without knowing that information it is also impossible
to reliably do an export. Once that has been corrected in zope.component
GenericSetup can be adjusted.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests


Re: [Zope-CMF] Re: Problem with Registering Local Utilities on reinstall of product

2008-06-16 Thread Nathan Van Gheem
With the old style products you could create afterInstall and beforeUnistall
scripts that were called on the product when proper.  Is there a way to do
this with the new style zope eggs.  Maybe somewhere in zcml?

Thanks,
Nathan

On Mon, Jun 16, 2008 at 12:31 PM, Balazs Ree [EMAIL PROTECTED] wrote:

 Hi Nathan,

 On Mon, 16 Jun 2008 10:51:34 -0500, Nathan Van Gheem wrote:

  Although, from what I've found, this is not the problem.  By stepping
  through the code, I found in this context, the local utility no longer
  exists.  So at some point in the install reinstall process it is
  unregistered.
 
  Looking deeper, I found that in the reinstall of a product the method
  _cascadeRemove() is called from
  Products.CMFQuickInstallerTool.InstalledProduct that unregisters all
  utilities.
 

  I don't know how to go about fixing this problem since the
  infrastructure is not set up to handle this.  Realistically, if there is
  an uninstall of a component needed, I would think it could be handled in
  the Products.GenericSetup.components class.
 
  Any ideas to help me get around this problem would be greatly
  appreciated.

 Not a solution, but the simplest workaround we found is setting up these
 utilities independently from genericsetup (and quickinstaller). This way
 you need to manually run an extra script to set up these utilities, and
 as a result quickinstaller will not have a chance to destroy and recreate
 the utility on reinstall. (Since it only borks stuff that it has set up
 itself.)

 Another gross hack that I've heard of (although I did not actually try it
 myself) is tinker with the __cmp__ method of the utility, which may
 convince quickinstaller to leave the utility intact. Maybe someone else
 will give more details about this.

 As far as for a real solution: I think the magic of quickinstaller is
 plain wrong. It should not ever delete your utilities on reinstall,
 because they form part of the content that is silently and entirely gone
 this way. (Think about object relations that are stored in local
 utilities, to understand the weight of this disaster.) I go even one step
 further: it also should not delete the utilities in case of an uninstall
 either, instead it should let you decide to delete them manually. There
 is something about upgrades (migrating data from an old version of
 utility to a new version) that makes this case a bit more complicated,
 however this is a more advanced use case and does not justify the data
 loss that happens on every reinstall, with the current implementation.

 Berst wishes,

 --
 Balazs Ree

 ___
 Zope-CMF maillist  -  Zope-CMF@lists.zope.org
 http://mail.zope.org/mailman/listinfo/zope-cmf

 See http://collector.zope.org/CMF for bug reports and feature requests

___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests


[Zope-CMF] Re: Problem with Registering Local Utilities on reinstall of product

2008-06-16 Thread Hanno Schlichting

Hi.

There's two issues here. One is with quick installer and one is with 
GenericSetup. This mailing list is not the right place to discuss issues 
with the first, please do that on the Plone developers mailing list.


Nathan Van Gheem wrote:

Martin Aspeli pointed out,

I think the problem is in Products.GenericSetup.components - in _initUtilities 
it does

  elif factory is not None:
  self.context.registerUtility(factory(), provided, name)

without first checking of a utility with this name for this interface already 
exists.


The code here does seem indeed to be wrong. There's two modes for GS 
import handlers, one being with purge and one without. The code in 
question does not support that correctly. It does work in some cases, as 
the underlying registerUtility function first checks if the component 
was already registered. It does so effectively by checking the newly 
registered object and the one that is already registered for equality. 
This check obviously fails in case of creating a new utility via a factory.


There is a bug report for this already at: 
https://bugs.launchpad.net/bugs/240170


I don't know how to go about fixing this problem since the 
infrastructure is not set up to handle this.  Realistically, if there is 
an uninstall of a component needed, I would think it could be handled in 
the Products.GenericSetup.components class. 


GenericSetup doesn't have any uninstall support, so this is not the 
right place to handle this.


Your main issue here is with quick installer.

Hanno

___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests