-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AttributeError: 'PersistentAdapterRegistry' object has no attribute 'lookupAll' #2228
AttributeError: 'PersistentAdapterRegistry' object has no attribute 'lookupAll' #2228
Comments
I had the same error here, but with different preconditions.
The bug is, for some reason local component registration just registers something (Plone Site object) instead of raising an exception if the dotted path does not exist. |
Update: This is not reproducible anymore with Plone-5.1.2.1 Had exactly the same error as reported above in a Plone-5.1.0.1, when installing an add-on via the add-site-advanced-form, but not when installing it after site-creation. The cause in my case was a portlet-assignment to a portlet-manager of Products.ContentWellPortlets via a GenericSetup-profile. Steps to reproduce:
And install it along a site-creation, using "Advanced configuration". |
This issue should be fixed before 5.1.2. |
Marked as blocker since this must be fixed before further releases. |
So is this when installing an add-on in the add-ons control panel? Or only when selecting extra add-ons to install while creating a site? |
@mauritsvanrees It only happens when selecting extra add-ons to install when creating a site. It does not happen when installing after site-creation via the add-ons control-panel or the ZMI's portal_quickinstaller. Tried your suggestion and it does resolve the error in my case. Frankly, I have no idea what's happening and avoid adapters in general, even more so because there was never a need for them amongst the use-cases I realized, and additionally ran into a non-reproducible(!) error, seemingly deriving of an adapter's persistent registry, some ages ago. |
With a So the Technically, it could be 'fixed' in
But that is also a workaround, for a transaction abort that seems to only happen when there is an error in an add-on that is being installed via the advanced site add form. |
@mauritsvanrees thanks a lot for the investigations. I wonder if would be possible to re-use parts of the working after-site-creation-form within the on-site-creation-form. Theoretically it should. And could be of benefit, in terms of reducing redundancy and less work for maintaining. Practically it might open up one or another can. [Placeholder for thinking-face-emoji] |
What do you mean with the 'working after-site-creation-form'? Do you mean the add-on form within the Site Setup? Problem here is that a transaction abort fails, maybe because too much has been aborted already (so that the site manager does not work properly) for this particular abort to work... A fix in There are a bit too many possible angles to take here. But at least someone searching for a problem like this might end up in this issue report, and get some ideas of where to look. |
Yes meant that form, wasn't aware it is reused already. Thought each form has it own solution and therein lies the difference. Agree the fix should be where the cause of the errors lies. |
Well, they don't share code, so it is not code reuse. But the basic functionality of both is the same: call |
Didn't mean that a |
By coincidence I saw another similar bug I reported a couple of weeks ago, in this case during test setup of Products.Poi in Plone 5.1: collective/Products.Poi#44 |
@hvelarde why did you removed the "high" flag? This issue is a major and blocker and it must be resolved before the next release (5.1.3). |
This bug now has labels '11 prio: blocker' and '12 prio: high'. I think that is why Hector removed one of them: there is no sense in having two priority labels. Now if someone would have a good idea on what the real underlying problem is, that would be very helpful. |
My workaround for this issue (in context of using plone.restapi for migration and my own browser view for provisioning a Plone site) is to create plain Plone website using |
Indeed, "blocker" is more than "high". For an explanation of the labels please read https://docs.google.com/spreadsheets/d/1IQ73bSQ10b0pwoUFn0u8SE4epDdvwjhTiYTDyPAhx7A/edit#gid=0 |
blocker or high...I would love that the release management considers a blocker as a blocker instead of ignoring them |
Why was 5.1.4 released with this blocker? |
Minimal buildout for failing Plone 5.1.4: https://github.com/zopyx/failing-plone |
https://github.com/zopyx/failing-plone works on MacOS - weird |
Your buildout works here on a very customized Ubuntu 14.04. Also tried with Multilingual using |
I can confirm the failing-plone buildout works for me on MacOS 10.14, python 2.7.15 |
Interesting observation: the error is reproducible with latest Ubuntu and FC26 where we use a shared eggs-directory. Both machines are pretty fresh and the eggs cache is also pretty new. Running the instance from a buildout with local egg-cache (eggs-directory=eggs) then I do not see the error. I also verified the issues with a system Python vs. self-compiled Python which makes no difference. This is unlikely a local problem (two different machines, two different OSes) however the different behaviour with local vs. global eggs cache appears more than weird. |
I have a global egg cache here configured in my |
As far as I understand, this is not a problem in Plone. It is a problem in GenericSetup that hides the underlying problem. And the underlying problem is an add-on that lists a non-existing dependency profile. Installing the add-on in the add-ons control panel would fail. Installing it in the advanced add-plone-site also fails, but sadly in a non-helpful way. So something that should fail, now fails in an unclear way. I would not call this a blocker. Onwards:
|
Using the current GS master does not make a difference. |
I cannot reproduce the issue. https://github.com/zopyx/failing-plone works fine. Even which |
I just gave the original issue (not the buildout thing) a quick shot on latest coredev/py3.7 and there's still an error page and a traceback in the log. I just added a typo in an addons
Maybe we should catch addon installation during site creation generally in the |
The very same issues continues to exist in Plone 5.2RC3 in its original form. https://github.com/zopefoundation/Products.PythonScripts/issues/32 causes this myriade of error mesages:
|
So, the fix with failing add-ons, we finally added, results in:
Latter is what you posted. What's missing? |
Tr
True when you create Plone site through the web. But my observation is true when you use |
The new behavior is also weird and does not make sense. I created a new site with a policy package throwing this mentioned error. Plone now says that the policy package could not be installed but it installed all its dependencies specified in metadata.xml. Sorry but this is completely odd. If I can not install the main policy package then Plone must not install any dependencies. This is broken. |
In what way is the result different than when creating a Plone site through the web? From a browser view or script I would currently expect the same thing: you get tracebacks in the logs, the faulty add-on is not installed, but the site gets created anyway. Do you see different behavior? Anyway, sounds like you want someone to implement what I proposed here and what Jens basically seconded here. |
If one has an buggy add-on the admin has to deal with it anyway. It is not Plone's fault. Plone just can fail completely, which is difficult in our case, or - as it is now - it can print big red error messages and lengthy tracebacks. So, yes we can enhance the code to fail and rollback all. I have no good idea how to achieve this, maybe only by deleting all that was prior created? But I dont think the current situation is a bug nor a blocker. If this is that important to you @zopyx please open an new issue as an "enhancement". If you - or another person thinking it is important enough - will work on it it is more than fine. We for sure will merge it, because it is the more elegant solution. But as said, from my POV this edge case handling of a failing third party addon is not worth spending more time. |
The current behavior is broken. If you are trying to install an add-on then the complete installation of the add-on including all of its dependencies must either work completely or the transaction must be rolled back. This is no longer the case case here. My the installation of the policy package with an error failed but it installed its dependencies correctly. This is undesired behavior. This leaves the a Plone installation in an undefined state. |
Please open a new issue. This is not a blocker. Its a special case with broken third party code. Thanks. PS.: We had a conscious decision that the current state is good enough. |
The following error is raised in Plone 5.1 when you try to install a new Plone site with an add-on where the Dexterity content-class could not be imported properly e.g. for some NameError in my case.
In particular this error message shadows the primary problem. It seems to me that some errors in the bootstrapping phase of Plone or inside of GS are just swallowed.
The text was updated successfully, but these errors were encountered: