[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