five.localsitemanager and unregisterUtility
Hello, I used to use those features in Silva. It work well with 0.4, but it's broken in 1.x. (I have tests in Silva testing that). This have to do with the wrapping (to remember the aquisition path) of an utility which is done inside the registry by registerUtility, which breaks the unregisterUtility. unregisterUtility is checking that the component you want to unregister is the same than the one which is in the registry, for the same specification, which is not true, because the one in the registry in wrapped with a ComponentPathWrapper (in register). If you do grep unregisterUtility in five.localsitemanager, you have no match, but the site API defines both, so they should both works (and so be tested). I volunteer myself to add test (and fix it) in the SVN, as I need that fix. Does anyone have an objection with that ? Does any official maintainer will do a release (1.1.1, as it will be a bug fix) afterwards ? (of course, the trunk will need to be fixed if the same problem is present, and no, I do not want to use the trunk, but the 1.x branch). Best regards, Sylvain Viollon -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
Hi Sylvain. I'm including Michael here, who's added the mentioned feature in the first place. On Fri, Oct 9, 2009 at 2:22 PM, Sylvain Viollon <sylvain@infrae.com> wrote:
I used to use those features in Silva. It work well with 0.4, but it's broken in 1.x. (I have tests in Silva testing that).
This have to do with the wrapping (to remember the aquisition path) of an utility which is done inside the registry by registerUtility, which breaks the unregisterUtility.
unregisterUtility is checking that the component you want to unregister is the same than the one which is in the registry, for the same specification, which is not true, because the one in the registry in wrapped with a ComponentPathWrapper (in register).
If you do grep unregisterUtility in five.localsitemanager, you have no match, but the site API defines both, so they should both works (and so be tested).
I volunteer myself to add test (and fix it) in the SVN, as I need that fix.
Does anyone have an objection with that ?
No objection, please go ahead.
Does any official maintainer will do a release (1.1.1, as it will be a bug fix) afterwards ?
Sure, ping me once you are done and I'll cut a new release. Michael, do you want to test anything, before I do a new release?
(of course, the trunk will need to be fixed if the same problem is present, and no, I do not want to use the trunk, but the 1.x branch).
There were some changes to the registerUtility code on trunk (incorporating bug fixes from zope.component), but these had to do with re-registering utilities and the implicit unregister that happens during that. As unregisterUtility is still not overridden, I suspect the same problem still exits and your tests should show that. Thanks, Hanno
Am 09.10.2009 um 14:41 schrieb Hanno Schlichting:
Hi Sylvain.
I'm including Michael here, who's added the mentioned feature in the first place.
On Fri, Oct 9, 2009 at 2:22 PM, Sylvain Viollon <sylvain@infrae.com> wrote:
I used to use those features in Silva. It work well with 0.4, but it's broken in 1.x. (I have tests in Silva testing that).
This have to do with the wrapping (to remember the acquisition path) of an utility which is done inside the registry by registerUtility, which breaks the unregisterUtility.
unregisterUtility is checking that the component you want to unregister is the same than the one which is in the registry, for the same specification, which is not true, because the one in the registry in wrapped with a ComponentPathWrapper (in register).
It seems that I overlooked the unregisterUtility functionality when implementing that registerUtility stores the acquisition path.
If you do grep unregisterUtility in five.localsitemanager, you have no match, but the site API defines both, so they should both works (and so be tested).
I volunteer myself to add test (and fix it) in the SVN, as I need that fix.
Does anyone have an objection with that ?
No objection, please go ahead.
+ 1
Does any official maintainer will do a release (1.1.1, as it will be a bug fix) afterwards ?
Sure, ping me once you are done and I'll cut a new release. Michael, do you want to test anything, before I do a new release?
For me it's enough that the tests inside five.localsitemanager succeed. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Fri, 9 Oct 2009 14:41:14 +0200 Hanno Schlichting <hanno@hannosch.eu> wrote:
Hi Sylvain.
Hello,
I volunteer myself to add test (and fix it) in the SVN, as I need that fix.
Does anyone have an objection with that ?
No objection, please go ahead.
I added test for unregisterUtility, and fix the bug I encounter, which happens only for utilities which inherit from Aquisition, and have a physical path.
Does any official maintainer will do a release (1.1.1, as it will be a bug fix) afterwards ?
Sure, ping me once you are done and I'll cut a new release. Michael, do you want to test anything, before I do a new release?
If you have time, I guess it's ready for a release.
(of course, the trunk will need to be fixed if the same problem is present, and no, I do not want to use the trunk, but the 1.x branch).
There were some changes to the registerUtility code on trunk (incorporating bug fixes from zope.component), but these had to do with re-registering utilities and the implicit unregister that happens during that.
As unregisterUtility is still not overridden, I suspect the same problem still exits and your tests should show that.
Actually, I didn't need to override the unregisterUtility method (which is better), I fixed the issue by adding a comparison one to the wrapper (and this should work with all versions of zope.component like this). Best regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
Hi. On Mon, Oct 19, 2009 at 5:11 PM, Sylvain Viollon <sylvain@infrae.com> wrote:
I added test for unregisterUtility, and fix the bug I encounter, which happens only for utilities which inherit from Aquisition, and have a physical path.
If you have time, I guess it's ready for a release.
I released both: http://pypi.python.org/pypi/five.localsitemanager/1.2 http://pypi.python.org/pypi/five.localsitemanager/2.0.1 I merged your fix to trunk, but had to adjust it by overriding parts of unregisterUtility there. Otherwise I got test failures under Python 2.6 / Zope 2.12. Hanno
On Mon, 19 Oct 2009 19:16:30 +0200 Hanno Schlichting <hanno@hannosch.eu> wrote:
Hi.
Hello,
I released both:
http://pypi.python.org/pypi/five.localsitemanager/1.2 http://pypi.python.org/pypi/five.localsitemanager/2.0.1
I merged your fix to trunk, but had to adjust it by overriding parts of unregisterUtility there. Otherwise I got test failures under Python 2.6 / Zope 2.12.
Thanks a lot Hanno ! I didn't look too much at 2.0, because 1.0 use the code of 3.4 which is different than the 3.5 version (which support more things). Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
participants (3)
-
Hanno Schlichting -
Michael Howitz -
Sylvain Viollon