> Ross Patterson wrote:
>> Ross Patterson <
[hidden email]> writes:
>>
>>> Martin Aspeli <
[hidden email]>
>>> writes:
>>>
>
>>>> Hi Ross,
>>>>
>>>>> In Products.membrane, we're having an issue with our Plone 3.0-3.2
>>>>> compatible branch. Its quite a pain for us since the way we currently
>>>>> get the tests to pass makes us depend on 3.3 meaning we have to have one
>>>>> version whose tests pass with 3.0-3.2 and another whose tests pass with
>>>>> 3.3+.
>>>>>
>>>>> Wichert spent some time with the original problem...
>>>>>
>>>>> Wichert Akkerman <
[hidden email]> writes:
>>>>>
>>>>>> On 6/23/09 10:40 AM, Ross Patterson wrote:
>>>>>>> Wichert described the parts of membrane that broke under 3.3 this way:
>>>>>>> "the indexing changesin 3.3 break registerIndexableAttribute in some
>>>>>>> complex way in tests, and debugging that is a lot more effort".
>>>>>>> Wichert, can you say in any more detail how this was related
>>>>>>> specifically to tests? Did the membrane test fixtures make assumptions
>>>>>>> about the internals of indexable attributes they shouldn't? If you
>>>>>>> could help shed any light on this it could go a long way towards keeping
>>>>>>> a Plone 3.0-3.x compatible 1.1 branch which I'd certainly like.
>>>>>> registerIndexableAttribute in Plone 3.3 works via some special CA
>>>>>> registrations for the indexers. For a mysterious reason I could not
>>>>>> figure out after an hour of debugging those registration went missing
>>>>>> in functional tests. Moving to the new API was a quick way to fix both
>>>>>> that mysterious problem and get rid of the deprecation warnings.
>>>>> I wonder then if it isn't an issue with the registerIndexableAttribute
>>>>> magic happening at import time being cleared by the testing.cleanUp call
>>>>> that happens in the ZCML layer, IIRC. Is anyone else experiencing test
>>>>> breakage with 3.3?
>>>> That sounds like a reasonable assumption.
>>>>
>>>> Can you think of another way to fix this? We could try to emit
>>>> configuration actions instead of calling provideAdapter(). One way to do
>>>> that would be to have the registerIndexableAttribute() function just
>>>> build a list of indexers, and then have a ZCML directive that picks up
>>>> this list and registers components.
>>>>
>>>> Do you think that'd work?
>>> That's certainly where my thoughts were headed. But I'd like
>>> confirmation of my assumption first. As a workaround for membrane 1.1,
>>> I was going to move our registerIndexableAttribute calls into a module
>>> that is only imported by ZCML. If that worked it would pretty much
>>> confirm this assumption.
>>
>> This workaround doesn't work because under PTC, site.zcml is actually
>> loaded *twice*.
>>
>> I can't remember why or how and I'm certain it shouldn't be so, but I
>> do remember at some point in years past confirming that the ZCML does
>> get loaded twice. It gets loaded at some point during instance
>> startup and then in the Products.PloneTestCase.layer.ZCML layer the
>> Products.PloneTestCase.five.safe_load_site clears the ZCA and runs
>> the ZCML again.
>>
>> Of course, the second time around, the results of the
>> registerIndexableAttribute calls have already been cleared when the
>> ZCA was cleared but the module has already been imported and so the
>> registerIndexableAttribute registrations won't be repeated.
>>
>> I confirmed this by moving the registerIndexableAttribute calls into
>> a separate module that isn't imported until after the ZCML layer runs
>> and the tests work again. So yes, I think your solution would
>> resolve this.
>
> Okay. Are you able to help look into this? I think what we need to do
> is:
No, sorry, I've already put all the time I can afford into this. :(
Yup, sounds right. Sorry I can't help more with the impl.
