[Zope-dev] Extending SiteErrorLog
Hi, I'm starting to prepare an extension for the SiteErrorLog that will allow you to store the detailed view of an Exception as a file on the server (directory will be configurable from zope.conf). I'm adding this feature because we have consulting situations where it is easier to transport a file on the server to us, than from the workstation we are using. The copy to error log isn't exactly the same. Also it doesn't need to be done for *every* exception, but I like to take a snapshot of single pathological exceptions. If you have any comments to this, I'd be happy to include those in my thoughts. I'm starting to prepare that on a branch for Zope 2.8. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending SiteErrorLog
Replying to myself ... :) See the branch ctheune-extending_error_log. I checked my changes in. Any feedback is welcome. If no complaints come around, I'm going to put that on the trunk after a week. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] subobject in BaseObject
Please report Plone or Archetypes problems on their appropriate lists.
Florent
Pan Junyong [EMAIL PROTECTED] wrote:
Archetypes has a cool feature: when MS doc are transform to html,
pictures in the doc are stored as subobject of the content.
After many tests, the feature works only when anonymous can view the
content. Or the picture will not show even I login at admin.
I traced it, and found it fails at the last step: it returns the correct
wrapper object, but fails when call the following __call__ method(no
permission). It is quite strange since the
__allow_access_to_unprotected_subobjects__ is already in the Wrapper class.
Any hint for me?
# the Wrapper class in BaseObject.py:
class Wrapper:
wrapper object for access to sub objects
__allow_access_to_unprotected_subobjects__ = 1
def __init__(self, data, filename, mimetype):
self._data = data
self._filename = filename
self._mimetype = mimetype
def __call__(self, REQUEST=None, RESPONSE=None):
if RESPONSE is None:
RESPONSE = REQUEST.RESPONSE
if RESPONSE is not None:
mt = self._mimetype
name =self._filename
RESPONSE.setHeader('Content-type', str(mt))
RESPONSE.setHeader('Content-Disposition',
'inline;filename=%s' % name)
RESPONSE.setHeader('Content-Length', len(self._data))
return self._data
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Understanding LeakFinder-0.1.1
Hi, reading LeakFinder's code (version 0.1.1) I was puzzled by: if not hasattr(DB, '_lf_real_open'): # Patch DB with a way to block open operations. DB._open_lock = allocate_lock() def open(self, *args, **kw): self._open_lock.acquire() self._open_lock.release() return apply(self._lf_real_open, args, kw) DB._lf_real_open = DB.open DB.open = open Inside the redefined::open(), the lock is acquired and released before delegating to the original::open(). I wonder if: 1) That was done intentionally as a _step_on_the_break_ measure 2) acquire() or release() cause a desired side effect (despite 1), inside ZODB's inner-sanctum (that eludes me) 3) That was not the original intention, where apply() should come between acquire() and release() 4) none above (I'd appreciate to learn why) I've sent this mail to zope-dev because it was the only address mentioned in the source code. best regards, Rod Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Understanding LeakFinder-0.1.1
[Rodrigo Dias Arruda Senra] reading LeakFinder's code (version 0.1.1) I was puzzled by: if not hasattr(DB, '_lf_real_open'): # Patch DB with a way to block open operations. DB._open_lock = allocate_lock() def open(self, *args, **kw): self._open_lock.acquire() self._open_lock.release() return apply(self._lf_real_open, args, kw) DB._lf_real_open = DB.open DB.open = open Inside the redefined::open(), the lock is acquired and released before delegating to the original::open(). I wonder if: 1) That was done intentionally as a _step_on_the_break_ measure 2) acquire() or release() cause a desired side effect (despite 1), inside ZODB's inner-sanctum (that eludes me) 3) That was not the original intention, where apply() should come between acquire() and release() 4) none above (I'd appreciate to learn why) I'm not familiar with this code (haven't seen it before), but I think it's clear enough: elsewhere, getControlledRefcounts() acquires this lock. That prevents the patched DB.open() from calling the real DB.open() until getControlledRefcounts() releases the lock again. But I don't see anything to stop getControlledRefcounts() from being called while any number of other threads are in the midst of the real DB.open(). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] INGRES R3 . If you plan to use Ingres please read this
sathya wrote: Since Ingres Plone and APE have some things in common I thought I should post this on this forum. Your experience may be different and the above is just FYI . I hope things get better in the days ahead. Out of interest, where are APE and Ingres's python support downloadable from? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Understanding LeakFinder-0.1.1
On Wednesday 12 January 2005 12:15 pm, Rodrigo Dias Arruda Senra wrote: Inside the redefined::open(), the lock is acquired and released before delegating to the original::open(). I wonder if: 1) That was done intentionally as a _step_on_the_break_ measure 2) acquire() or release() cause a desired side effect (despite 1), inside ZODB's inner-sanctum (that eludes me) 3) That was not the original intention, where apply() should come between acquire() and release() 4) none above (I'd appreciate to learn why) It's intentional. The quick lock and unlock normally has no effect, but while getControlledRefcounts is running, it holds _open_lock for several seconds, preventing new connections. With the lock held, it waits for other connections to close, clears caches, computes the refcounts, and releases _open_lock. It does all this to take refcount measurements in a relatively controlled environment. Like Tim said, open() calls that start before getControlledRefcounts acquires _open_lock will not block. getControlledRefcounts does not account for that, so its call to pools.items() is unreliable. A possible solution is for getControlledRefcounts to also acquire the database's connection pool lock, accessible via the _a and _r attributes. But it can't hold that lock for long, since other threads will need it to close connections. I didn't know anybody still uses LeakFinder. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Authentication failed in case of redirect
Hi, I have a zope installation available on a pubblic IP address. A user may address this by an url, the domain manager redirect the request on my IP. It works well but the login process doesnt work properly. I think its a problem of cookie settings. Any idea ? Thanks !! Claudio Ramini ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
