[Zope] How to execute code at startup?
I have a very simple script that copies my production Zope instance to
a fresh test instance. I have some Python code that I need to execute
when the test instance starts for the first time (it only needs to
execute once, but it won't hurt Zope if it executes every time the
test instance starts. I usually execute this code interactively, from
the Zope debugger:
app.restrictedTraverse(/irtnog/portal_cache_settings).setCacheConfig
('zope')
Is there any way to execute this code (or something similar)
automatically? I guess the alternative is that I could script the
process of entering the Zope debugger and running the above using
Expect or something.
Best wishes,
Matthew
--
Rogues are very keen in their profession, and know already much more
than we can teach them respecting their several kinds of roguery.
- A. C. Hobbs in _Locks and Safes_ (1853)
smime.p7s
Description: S/MIME cryptographic signature
___
Zope maillist - Zope@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 )
RE: [Zope] Make folder's default view the contents of an item based on latest date
Praful, Quills (a webblog Product for Zope/Plone) works something like that. Perhaps you should take a look through its source code for clues as how to implement your archival mechanism? Best wishes, Matthew -- Rogues are very keen in their profession, and know already much more than we can teach them. - A. C. Hobbs in _Locks and Safes_ (1853) ___ Zope maillist - Zope@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 )
RE: [Zope] DeadlockDebugger revisited
From: Dieter Maurer [mailto:[EMAIL PROTECTED] I fear that you can call Python functions in general only on the current thread (the other's probably lack the GIL, an essential requirement to execute Python code). Well, I upgraded to Python 2.4, re-compiled Zope and friends, and updated a few of the third-party products, and my problems with Zope deadlocking have stopped, or at least my Zope has been running non-stop for the last 5 days. We'll see if it eventually crashes (hopefully not). Thanks for the help. Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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 )
RE: [Zope] DeadlockDebugger revisited
Dieter,
I tried the whole gdb threads debugging thing, with the following (nil)
results. Any other ideas? A lot of the instructions online seem to be
Linux-centric, so I'm at a loss as how to proceed:
(gdb) info threads
* 7 LWP 100099 0x2820e544 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.2
6 Thread 0x8111000 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
5 Thread 0xa358400 (LWP 100098) 0x2821546b in pthread_testcancel ()
from /usr/lib/libpthread.so.2
4 Thread 0x9918200 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
3 Thread 0x9064400 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
2 Thread 0x9064e00 (runnable) 0x0807b36f in PyType_IsSubtype ()
1 Thread 0x9a32200 (runnable) 0x08b53622 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x9064e00 (runnable))]#0 0x0807b36f in
PyType_IsSubtype ()
(gdb) call PyRun_SimpleString(import sys, traceback;
sys.stderr=open('/tmp/tb','w',0); traceback.print_stack())
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x9a32200 (LWP 100099)]
0x08b53622 in ?? ()
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use set unwindonsignal on
Evaluation of the expression containing the function (malloc) will be
abandoned.
(gdb) call PyRun_SimpleString(import sys, traceback;
sys.stderr=open('/tmp/tb','w',0); traceback.print_stack())
Cannot set lwp 100099 registers: Invalid argument
Cannot set lwp 100099 registers: Invalid argument
--
jsoffron: I'm generally pretty high on national defense...
Mr. Bad Example: Careful...it's a gateway policy. Before you know it,
you'll be mainlining the hard stuff like trade agreements.
jsoffron: Too late...I've been freebasing Nafta all day... Sweet,
sweet NAFTA.
- As seen on Slashdot
-Original Message-
From: Dieter Maurer [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 2:36 PM
To: Matthew X. Economou
Cc: zope@zope.org
Subject: Re: [Zope] DeadlockDebugger revisited
Matthew X. Economou wrote at 2006-6-16 09:10 -0400:
I thought a recent operating system upgrade (FreeBSD 5.4 to 6.1)
fixed
my problems with Zope. Unfortunately, once I re-compiled Python et
al
(to remove dependencies on the old libraries), my problems with
Zope
deadlocking recurred. I tried to use a combination of tools to try
to
discover the root cause of this problem, but nothing seems to work.
What am I missing, and what else can I try?
Your description seems to match an error case, I have seen
under Python 2.3.4 with Linux 2.4 kernel:
When a SIGSEGV occurs, then Zope's main thread (the ZServer
thread) dies
(and Zope therefore stops responding) but the other threads
remain alive and keep all sockets open.
The primary culprit was Python, although the Linux thread
implementation
had to help to expose the bug in this way.
I had thought that the problem were fixed in Python 2.3.5 (which you
use). Thus, maybe, your problem is different from the one
outlined above. Use OS means to check in what state the various
Zope threads are and whether the primary thread still exists.
If this is not the problem cause, you can attach your
Zope process with gdb and analyse the state -- especially
that of the main thread. There is a howto around how to do that.
--
Dieter
___
Zope maillist - Zope@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 )
RE: [Zope] DeadlockDebugger revisited
This time, when it locked, I thought to try a backtrace.
(gdb) info threads
* 7 LWP 100098 0x2820e544 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.2
6 Thread 0x8111000 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
5 Thread 0xa1e1a00 (LWP 100047) 0x2821546b in pthread_testcancel ()
from /usr/lib/libpthread.so.2
4 Thread 0x8c91e00 (runnable) 0x08098bc0 in _PyEval_SliceIndex ()
3 Thread 0x8c92c00 (runnable) 0x081008e0 in PyModule_Type ()
2 Thread 0x9061e00 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
1 Thread 0x991ac00 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
(gdb) thread 2
[Switching to thread 2 (Thread 0x9061e00 (sleeping))]#0 0x2820df0f in
pthread_mutexattr_init () from /usr/lib/libpthread.so.2
(gdb) call PyRun_SimpleString(import sys, traceback;
sys.stderr=open('/tmp/tb','w',0); traceback.print_stack())
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x8c91e00 (LWP 100098)]
0x08098bc0 in _PyEval_SliceIndex ()
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use set unwindonsignal on
Evaluation of the expression containing the function (malloc) will be
abandoned.
(gdb) bt
#0 0x08098bc0 in _PyEval_SliceIndex ()
#1 0x0809ba98 in _PyEval_SliceIndex ()
#2 0x0809c420 in PyEval_EvalCodeEx ()
#3 0x080cd2d2 in PyFunction_SetClosure ()
#4 0x0805973c in PyObject_Call ()
#5 0x0805f192 in PyMethod_New ()
#6 0x0805973c in PyObject_Call ()
#7 0x28465dbd in load_binpersid () from
/usr/local/lib/python2.3/lib-dynload/cPickle.so
#8 0x28466eea in load () from
/usr/local/lib/python2.3/lib-dynload/cPickle.so
#9 0x0809b310 in _PyEval_SliceIndex ()
#10 0x0809ba98 in _PyEval_SliceIndex ()
#11 0x0809ba98 in _PyEval_SliceIndex ()
#12 0x0809ba98 in _PyEval_SliceIndex ()
#13 0x0809c420 in PyEval_EvalCodeEx ()
#14 0x080cd2d2 in PyFunction_SetClosure ()
#15 0x0805973c in PyObject_Call ()
#16 0x0805f192 in PyMethod_New ()
#17 0x0805973c in PyObject_Call ()
#18 0x08059911 in PyObject_CallMethod ()
#19 0x28498671 in unghostify () from
/usr/local/www/Zope28/lib/python/persistent/cPersistence.so
#20 0x28499aff in Per_setstate () from
/usr/local/www/Zope28/lib/python/persistent/cPersistence.so
#21 0x28524a21 in P_getattr () from
/usr/local/www/Zope28/lib/python/Persistence/_Persistence.so
#22 0x284d1c29 in Wrapper_findattr () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#23 0x284d2367 in Wrapper_getattro () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#24 0x08091372 in _PyUnicodeUCS4_IsAlpha ()
#25 0x0809b310 in _PyEval_SliceIndex ()
#26 0x0809c420 in PyEval_EvalCodeEx ()
#27 0x080cd2d2 in PyFunction_SetClosure ()
#28 0x0805973c in PyObject_Call ()
#29 0x08096de7 in PyEval_CallObjectWithKeywords ()
#30 0x0805971b in PyObject_CallObject ()
#31 0x284cb59a in callfunction4 () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#32 0x284cbc85 in ZopeSecurityPolicy_validate () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#33 0x0805973c in PyObject_Call ()
#34 0x08096de7 in PyEval_CallObjectWithKeywords ()
#35 0x080ca342 in PyComplex_AsCComplex ()
#36 0x0805973c in PyObject_Call ()
#37 0x0805f192 in PyMethod_New ()
#38 0x0805973c in PyObject_Call ()
#39 0x08096de7 in PyEval_CallObjectWithKeywords ()
#40 0x0805971b in PyObject_CallObject ()
#41 0x284cb62d in callfunction5 () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#42 0x284cc6f9 in SecurityManager_validate () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#43 0x0809b310 in _PyEval_SliceIndex ()
#44 0x0809c420 in PyEval_EvalCodeEx ()
#45 0x0809a7ab in _PyEval_SliceIndex ()
#46 0x0809c420 in PyEval_EvalCodeEx ()
#47 0x0809a7ab in _PyEval_SliceIndex ()
#48 0x0809c420 in PyEval_EvalCodeEx ()
#49 0x0809a7ab in _PyEval_SliceIndex ()
#50 0x0809c420 in PyEval_EvalCodeEx ()
#51 0x080cd2d2 in PyFunction_SetClosure ()
#52 0x0805973c in PyObject_Call ()
#53 0x0809a3be in _PyEval_SliceIndex ()
#54 0x0809ba98 in _PyEval_SliceIndex ()
#55 0x0809c420 in PyEval_EvalCodeEx ()
#56 0x0809a7ab in _PyEval_SliceIndex ()
#57 0x0809c420 in PyEval_EvalCodeEx ()
#58 0x080cd2d2 in PyFunction_SetClosure ()
#59 0x0805973c in PyObject_Call ()
#60 0x0805f192 in PyMethod_New ()
#61 0x0805973c in PyObject_Call ()
#62 0x0809a3be in _PyEval_SliceIndex ()
---Type return to continue, or q return to quit---
#63 0x0809c420 in PyEval_EvalCodeEx ()
#64 0x080cd2d2 in PyFunction_SetClosure ()
#65 0x0805973c in PyObject_Call ()
#66 0x0805f192 in PyMethod_New ()
#67 0x0805973c in PyObject_Call ()
#68 0x08096de7 in PyEval_CallObjectWithKeywords ()
#69 0x284d14e6 in CallMethodO () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#70 0x0805973c in PyObject_Call ()
#71 0x08098b36 in _PyEval_SliceIndex ()
#72
[Zope] DeadlockDebugger revisited
I thought a recent operating system upgrade (FreeBSD 5.4 to 6.1) fixed
my problems with Zope. Unfortunately, once I re-compiled Python et al
(to remove dependencies on the old libraries), my problems with Zope
deadlocking recurred. I tried to use a combination of tools to try to
discover the root cause of this problem, but nothing seems to work.
What am I missing, and what else can I try?
This system is:
Nokia IP440 (Pentium II-333MHz, 256 MB RAM)
FreeBSD 6.1-RELEASE-p1
Python 2.3.5
Zope 2.8.6
Plone 2.1.2
Trace and event logs:
I set up the trace log to save all messages, and the last few lines of
the access, event, and trace logs are:
Z2.log:
127.0.0.1 - Anonymous [15/Jun/2006:22:52:54 -0400] GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/irtnog/he
lpcenter_icon.gif HTTP/1.1 200 1322
http://web.irtnog.org/howtos-orig/freebsd-pf-pppoe; Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
event.log:
2006-06-15T22:40:28 INFO Plone Debug Error exceptions.AttributeError on
getBeginAndEndTimes while rendering portlet
here/portlet_simpleblog/macros/portletBlogFull_local
trace.log:
B 221198124 2006-06-15T22:52:54 GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x
enophon/photos/washdc-jan-2006/photoalbum_view?b_start:int=20
I 221198124 2006-06-15T22:52:54 0
DeadlockDebugger + threadframe:
Once the Zope process deadlocks, it ceases to respond on port 8080 (the
configured listener port). Thus it is not possible to obtain a thread
dump from Zope using this package.
Lsof:
I checked the list of open files on the Zope process but didn't see
anything out of the ordinary (attached as zope-lsof.txt)
Strace/Truss/Ktrace:
I traced the process using ktrace, dumped it with kdump -H to get
thread IDs, and got the following information:
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
7505 100075 python2.3 PSIG SIGSEGV SIG_DFL
I traced the process using truss and got the following information:
SIGNAL 11 (SIGSEGV)
SIGNAL 11 (SIGSEGV)
SIGNAL 11 (SIGSEGV)
SIGNAL 11 (SIGSEGV)
SIGNAL 11 (SIGSEGV)
SIGNAL 11 (SIGSEGV)
Strace showed the same information:
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
--- SIGSEGV (Segmentation fault: 11) ---
GDB + attach + info threads
(https://engineering.purdue.edu/ECN/Resources/KnowledgeBase/Docs/2006051
8104722):
The faulting thread seems to be in the middle of pthread_mutexattr_init.
(gdb) info threads
* 7 LWP 100075 0x2820e5c2 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.2
6 Thread 0x8111000 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
5 Thread 0xa318a00 (LWP 100062) 0x2821546b in pthread_testcancel ()
from /usr/lib/libpthread.so.2
4 Thread 0x991ac00 (runnable) 0x in ?? ()
3 Thread 0x9062400 (runnable) 0x0cea3a2c in ?? ()
2 Thread 0x9a37a00 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
1 Thread 0x9a35800 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
None of the threads are in the sigsuspend, poll, select, or kill state,
although it's possible that the sleeping state is equivalent to
sigsuspend. At a whim, I tried stepping into the process, but this
didn't do anything other than show the SEGV on the console.
(gdb) call PyRun_SimpleString(import string,sys,os,ZServer;
sys.stdout=open('/tmp/urls','w',0); print string.join(map(lambda
a:str(getattr(a,'env',{}).get('PATH_INFO','')),
sys.modules['asyncore'].socket_map.values()), '\\n'))
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x9062400 (LWP 100075)]
0x0cea3a2c in ?? ()
The program being debugged was signaled while in a function called from
GDB.
And:
(gdb) call PyRun_SimpleString(import sys,
traceback;sys.stderr=open('/tmp/tb','w',0); traceback.print_stack())
[Switching to Thread 0x9062400 (LWP 100114)]
Cannot set lwp 100114 registers: Invalid argument
Cannot set lwp 100114 registers: Invalid argument
--
jsoffron: I'm generally pretty high on national defense...
Mr. Bad Example: Careful...it's a gateway policy. Before you know it,
you'll be mainlining the hard stuff like trade agreements.
jsoffron: Too late...I've been freebasing Nafta all day... Sweet,
sweet NAFTA.
- As seen on Slashdot
COMMANDPID USER FD TYPE DEVICE SIZE/OFF
RE: [Zope] RE: zope LDAP deadlock problem
You can use Florent's DeadlockDebugger to find out what happens. This is true for someone with the requisite skills and plenty of time. In my case, the actual deadlock happens in a system library routine (sigaction, as I recall), making the identification of the component that's actually at fault rather challenging for someone like me. Fortunately, something in FreeBSD's threading implementation must have changed between RELENG_5 and RELENG_6, because Zope doesn't become completely unresponsive now. Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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] RE: zope LDAP deadlock problem
(This is in regards to a post of mine from last year, i.e. http://mail.zope.org/pipermail/zope/2005-March/157400.html.) Sir, I received your email, but I am very sorry that I do not have time to reply in detail. In short, no, Zope will consume all available CPU cycles after some amount of idle time, due to a threading-relatedflaw in Zope, GRUF, Plone, LDAPUserFolder, python-ldap, or OpenLDAP (I don't know which). Lucky for me, upgrading from FreeBSD 5.4 to 6.1 reduced the severity of this problem. Under FreeBSD 6.1, Zope does not completely deadlock, and any web site access after Zope begins spinning will bring it out of this 100%-CPU state. I don't have this problem on Zope/Plone servers running under Fedora Core 4/5, so I've considered switching to Linux. Please note that I had to hack the FreeBSD ports tree in order to force it to use Python 2.3 with Zope 2.8. Email me privately for the details. I will try to follow up with additional detail when I have time time. Best wishes, Matthew ___ Zope maillist - Zope@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] Preserving ownership on export/import
Is it possible to export an object from a Zope instance in such a way that, upon importing the object in a completely different Zope instance and assuming the two Zope instances share a common authentication source (e.g. LDAP), the original owner of the object is preserved? I want to migrate key content (such as member folders) from my old Plone 2.0 server to my new Plone 2.1 server. Unfortunately, the imported objects are now owned by me, not by the users that originally owned them. Zope seems to support me only taking ownership of an object, not transferring ownership to someone else. Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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 )
RE: [Zope] Re: Linux/unix preferences question
I would recommend sticking to Linux, as this is the most well-tested Zope platform. Python on *BSD has historically had issues, don't know if that's still the case. I'm running Zope and Plone on FreeBSD, both on i386 and alpha platforms. I seem to have problems no one else experiences (like PloneExFile being unable to handle attached files over 25 MB, or LDAPUserFolder causing the entire Zope instance to get stuck in a loop). Like MediaWiki, Apache, and PHP, most of the Zope and Plone developers do their development on Linux. Unless you are prepared to deal with the bugs, you probably should start with Linux, too. Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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 )
RE: [Zope] Zope Scalability
Jens wrote: There is no answer to this question because it cannot be answered. No one has come against a limit yet as far as I know. Hitting RAM limits depends on the settings you apply to the Zope/ZEO instance(s) that serve(s) the content and how much RAM you put in, you can control ZODB memory cache size via zope.conf. No one sets up Zope so that the whole ZODB is loaded into memory, if that's what you mean. I got the impression that he was asking about the maximum object size. I don't know if there is a limit in Zope itself, but I've run into problems with PloneExFile when uploading files larger than about 25 MB. Who knows - it might be a bug in PloneExFile, AttachmentField, or Archetypes. I lack the expertise required to troubleshoot the error, so take this with the proverbial grain of salt. BTW: I'm using LDAPUserFolder in a 10,000-user Active Directory environment. It works great. Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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] Copying Data.fs to a different CPU architecture
My Zope server is currently an Alpha running FreeBSD. This computer's CPU is no longer working. I would like to restore my backup copy of Data.fs to a new computer, a PC running FreeBSD. Will this work as a straightforward copy, or will the two platform's differing byte orders (and word sizes) cause problems for me? Best wishes, Matthew -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot ___ Zope maillist - Zope@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 )
RE: [Zope] Folder Listing as a Plone Portlet Mini-HOWTO (draft)
-Original Message- From: David Convent [mailto:[EMAIL PROTECTED] Sent: Friday, April 01, 2005 3:30 AM Plone now uses catalog queries to build folder listings, it avoids waking up all objects and slow down the server response. Consider using it, your portlet as it is written now can slow down the browsing of a folder containing a large amount of objects. I don't understand this. Would you point out the relevant documentation or source code? As it is, portlet_folder_contents is a hack and probably only suitable for small folders. In my case, I intended to use it to create a small box of links (no more than five or six), without having to go to the ZMI all the time to change the portlet's contents. Best wishes, Matthew ___ Zope maillist - Zope@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] Folder Listing as a Plone Portlet Mini-HOWTO (draft)
http://web.irtnog.org/Members/xenophon/plone/portlet-folder-contents This folder listing portlet displays the title of the folder, its description, and a list of each item in the folder. Mousing over each link pops up its description in browsers that understand the title anchor (A) tag attribute. Your comments and suggestions are greatly appreciated! Best wishes, Matthew ___ Zope maillist - Zope@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 )
