Jeff Shell wrote:
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:

Jeff Shell wrote:

On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:

Jeff Shell wrote:

Is it related to this? "Bug in Multi Adapter Lookup"?
('fixed' in Zope 3.2b1)

That's my suspicion.

That would be my suspicion too.  It should be easy to test.
Just get a check out and merge out that change:

 svn merge -r40385:40384 svn+ssh://

Going through a lot of debugging, ....

Did you do the experiment I suggested? (above)

Yes. Against that merge, against a Zope 3.2b1 release, applying those
specific revisions to the 3.2b1 release, even going back to the
revisions listed in Collector Issue 396, the same result happens.

I assume that, by "the same result happens", you mean that your application
works the way it did before. No, that can't be.

I screwed up and gave you the wrong revision number. The revision in which I
fixed this bug was 39948, so the merge should have been:

  svn merge -r39948:39947 svn+ssh://

It's one that makes sense to me, in its way. As stated in the
debugging output message, I just expected the layer to somehow have a
higher precedence than it does. At the multi-adapter lookup level, I
think I can understand why the new code does what it does. I may just
need to re-evaluate how my interfaces are declared, or what my
subclassing is causing to happen, or how my views are declared.

Here's a bit more detail.

When we look up multi-adapters, we want to look up adapters that
fit the first object best, and, if more than one adapter require the same
first interface as the one that fits the first object best, then, among
those we prefer the ones that fit best for the second object, and so on.

There was a bug that caused the adapter that fit the second object
best to be prefered, as long as it also matched the first object at all.
This is illustrated by the test shown in

This bug has now been fixed.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to