[Zope] Zope 2.7.2 with Ape 1.0 installed in root, fails to restart,
without any usefull logging, after adding a local role
Tim Connor
tim at infosauce.com
Wed May 25 04:37:01 EDT 2005
I spoke too soon. I don't think it's Zope error on that type mismatch
(or if it is one, it's not that one I thought). It still happens if
there are multiple roles defined. As long as it hits the code adding
the non-existing Owner role* the start-up croaks. So either something
about Ape is causing the type mis-match or the Zope code has a bug and
just usually doesn't hit that branch (which is possible, as I suspect
most people don't manage to delete the Owner user). I don't know
python, very well, so I don't have much of an idea. I tried changing
the syntax on the ('Owner',) a couple different ways to get around the
type mis-match, and then I got things started, but without any of the
default users.
Now it seems even more like there is an Ape bug involved (or at least a
bug in getting it working on the root). Whenever I save the security
tab on the root folder, it rewrites the .properties file, without the
default roles defined, which puts Zope in an unstartable place. But then
if I tweak Zope to make it start the default roles aren't defined. It
seems I need to explicitly define those roles in the root .properties,
but even if I do that manually then I can never touch the security tab
(not sure if changing any other property on root causes the same problem).
Tim
* Since the traceback isn't in this set of replies, heres the pertinent
code:
File "/usr/lib/zope-2.7.2/lib/python/OFS/Application.py", line 457, in
install_required_roles
app.__ac_roles__=app.__ac_roles__ + ('Owner',)
TypeError: can only concatenate list (not "tuple") to list
Tim Connor wrote:
> Thanks Dennis,
>
> Between your and Shane's reply, I got it fixed:
>
> I just raised an error with the value of app.__ac_roles__, at that
> point in lib/python/OFS/Application.py and determined that ONLY the
> role I had added was being created. So going in and manually adding
> those starting default roles to the .properties file fixed it (running
> it from the console 2 days ago sure would have saved me some sleep :/).
> I have no idea if that is a problem with how I moved an existing
> project into a root install of Ape, or if it is a more generic one,
> but on my set-up Ape definitely only puts things in that [security]
> section of the .properties files when you make a change. (For
> example, just hitting save on the Security tab adds all those per role
> settings, but not the roles themselves). On everything aside from
> root that works better, but obviously if you ever get to the point I
> was at where there is only one role defined on start-up, it kill Zope,
> badly.
>
> Technically that might be a Zope error also - if there is only one
> role, it hits a type mismatch. But people shouldn't ever be getting
> there anyways, I suppose.
>
> Tim
>
> Dennis Allison wrote:
>
>> Tim,
>> You may want to run Zope in debug mode-- bin/runzope should do it.
>> Also, be sure you have the event.log configured and enable. -d
>>
>> On Wed, 25 May 2005, Tim Connor wrote:
>>
>>
>>
>>> I sent roughly this email directly to Shane Hathaway, since I hadn't
>>> asked for any help on Zope, yet, so didn't know where to look.
>>> Maybe this was a better avenue? If you read this list, Shane (or Mr.
>>> Hathaway, if you prefer), respond on whichever seems more
>>> appropriate, I guess. I don't know, let me know if I'm missing some
>>> etiquette point.
>>>
>>> Anyways, I'm using Ape 1.0 set-up in the root of Zope 2.7.2 install,
>>> based on the example fs config, and that is working fine. I was
>>> having a problem where some change was making that Zope instance not
>>> even get far enough in booting to write to the event.log (set to
>>> level all). I narrowed it down to adding a local role on the
>>> security tab of the root object. I revert the .properties file and
>>> restart - it works. I make the change again and restart - it
>>> doesn't. I diff the file, and the only difference is the
>>> define-role line. The problem is I have no idea where to start
>>> even, since no errors are thrown where I know to find them. Zope
>>> just doesn't respond at all when I try to restart it, and writes
>>> nothing to the log.
>>>
>>> If anyone could tell me what I can do to at least track down the
>>> problem, if not fix it, it would be much appreciated.
>>>
>>> Thanks,
>>> Tim
>>> _______________________________________________
>>> Zope maillist - Zope at zope.org
>>> http://mail.zope.org/mailman/listinfo/zope
>>> ** No cross posts or HTML encoding! **
>>> (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
>>> http://mail.zope.org/mailman/listinfo/zope-dev )
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> Zope maillist - Zope at zope.org
> http://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope-dev )
>
More information about the Zope
mailing list