failed authentication attempts?
Neither event.log or Z2.log shows anything. As Z2.log is the access log,
I would have guessed that such things should be logged there. If not,
where and how?
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com
IP-adress and port the zope server is started on.)
DEBUG: For debug information.
TRACE: I need to have a lot of information now!
I find all this fairly self-evident and highly useful, and se
absolutely zero reason for removing them, when they are so useful.
--
Florent Guillaume, Nuxeo (Paris
out of ideas to investigate this issue. Does any of you
have an idea of why could this happen ? Or an idea of what I could try
to undersatnd what's happening ? Any idea is dearly welcomed.
Thanks a lot !
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59
at
the trace level (as they were before the move to python's logging module),
I'm thinking of transaction logs here.
This leaves the 'debug' level free for application debugging.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL
Philipp von Weitershausen wrote:
Log message for revision 41225:
Sanely deprecate StructuredText by making it a facade of zope.structuredtext.
Just to make sure: we didn't lose the ReST allowed arbitrary file includes
bugfix by doing this?
Florent
--
Florent Guillaume, Nuxeo (Paris
strings, and indeed ZODB and zLOG have them
defined.
I want to use them.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http
On 9 Jan 2006, at 17:03, Andreas Jung wrote:
--On 9. Januar 2006 17:00:13 +0100 Florent Guillaume [EMAIL PROTECTED]
wrote:
Philipp von Weitershausen wrote:
Log message for revision 41225:
Sanely deprecate StructuredText by making it a facade of
zope.structuredtext.
Just to make sure
On 9 Jan 2006, at 17:25, Andreas Jung wrote:
--On 9. Januar 2006 17:06:25 +0100 Florent Guillaume [EMAIL PROTECTED]
wrote:
My point is that the python logging levels are insufficiently fine
grained.
Sufficently enough for me.
Sufficient for me is not a good reason sorry. If you don't want
On 9 Jan 2006, at 17:20, Fred Drake wrote:
On 1/9/06, Florent Guillaume [EMAIL PROTECTED] wrote:
My point is that the python logging levels are insufficiently fine
grained.
The python logging framework leaves room for numeric levels and
registering equivalent strings, and indeed ZODB and zLOG
for PythonScripts would
no longer be necessary.
I know but that means you have backward compatibility cruft that stays there
forever. And no good way to tell the administrators how to upgrade before a
given date.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59
://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http
for Python Scripts recompiling for instance. Or I can call it myself in
my upgrade procedures on the exact objects I know will need updates.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists
that uses LDAP as a storage for
quite a while. It's not plone compatible though, it uses an entirely
different framework.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
this same code?
Otherwise no clue, I'd do a network trace to know what's really posted.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http
)
--
Florent Guillaume, Nuxeo (Paris, France) 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
. I
hope by Saturday night it will be over -- but I'm having to learn the
TemporaryStorage code at the same time.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope
; make inplace; make instance
Doesn't work for me; I don't have a bin/mkzopeinstance after this
procedure so I still cannot create instances. Sigh.
I use utilities/mkzopeinstance.py (until moves again...)
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71
What happens if the request started by clockserver takes a long time
or hangs?
Will the next tick start a new one anyway, or will it be blocked?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
finished with exit code 255
Florent
--
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
Log message for revision 40929:
Forgotten import.
Changed:
U Zope/trunk/lib/python/OFS/CopySupport.py
-=-
Modified: Zope/trunk/lib/python/OFS/CopySupport.py
===
--- Zope/trunk/lib/python/OFS/CopySupport.py2005-12-21
-scary
components in Zope (please no further discussion about the pros and cons
of ZClasses..this discussion took already place already a bunch of times
on the list).
+1 as I don't use ZClasses and don't intend to maintain them.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO
() there if you know how to use PDB.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
Log message for revision 40864:
Added a 'conflict-error-log-level' directive to zope.conf, to set the
level at which conflict errors (which are normally retried
automatically) are logged. The default is 'info'.
This doesn't interfere with the error_log site object which copies
Log message for revision 40865:
Merged r40864 from 2.9 branch:
Added a 'conflict-error-log-level' directive to zope.conf, to set the
level at which conflict errors (which are normally retried
automatically) are logged. The default is 'info'.
This doesn't interfere with the error_log
the Persistent base class. PersistentList and
PersistentMapping are examples.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http
system as when using XML-RPC. It gets more complicated with
XML-RPC though!
The successive XML-RPC call you describe provoke new transactions,
surely you're aware of that? Whereas just calling a function of course
doesn't.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
sys.argv[1:] on Zope start?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) 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
description, but the devil is in
the details. I'd be interested in looking at it if you code something.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists
Log message for revision 40764:
The SiteErrorLog now copies exceptions to the event log by default
Changed:
U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
U
Zope/branches/Zope-2_8-branch/lib/python/Products/SiteErrorLog/SiteErrorLog.py
-=-
Modified:
Log message for revision 40765:
The SiteErrorLog now copies exceptions to the event log by default
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
U Zope/branches/2.9/lib/python/Products/SiteErrorLog/SiteErrorLog.py
-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
warnings at the places where
PlacelessTranslationService (or Localizer for that matter) do their
workarounds so that normally incompatible types are mixed together.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
no more messages.
What could I do? I must update that CPS site...
Add a
self.getFunction()
before the 'if' at line 229.
Please report if it works, I'll add it in the Zope code.
rantAnother stupid use of _v_ attributes.../rant
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director
points. (This is even true for English. Generally,
users prefer to see text sorted without regard to case.)
A proposal to address this problem is here:
http://dev.zope.org/Zope3/LocaleSpecificTextCollation
Comments are welcome.
+1, no comment :)
Florent
--
Florent Guillaume, Nuxeo (Paris
propose another little change: have the error_log copy to event.log be
the default behaviour. Today the default is off.
Florent
Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict
errors. These are the ConflictErrors that aren't returned to the user
with broken ZCML
configuration. (Don't know why - Zope is seriously broken in that case
and you don't see any useful error messages.)
I fixed this in recent zope.configuration. Should be in 2.8.5b1.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59
. The second element is a dictionary with items
for each of the assigned slots.
Other classes can specialise the methods, see for instance BTrees.Length.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
for httplib.HTTPConnection or a method
like getConnection that can then be subclassed or modified during tests.
Provided it does not important performance issues.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
Andreas Jung wrote:
Log message for revision 40580:
Zope 2.9.0 b1
Changed:
A Zope/tags/2.9.0b1/2.9/
-=-
Copied: Zope/tags/2.9.0b1/2.9 (from rev 40579, Zope/branches/2.9)
Huh, did you really want to do that?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
Log message for revision 40536:
ObjectManager now has an hasObject method to test presence. This
brings it in line with BTreeFolder.
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
U Zope/branches/2.9/lib/python/OFS/ObjectManager.py
U Zope/branches/2.9/lib/python/OFS/interfaces.py
Log message for revision 40537:
Merged r40536 from 2.9 branch:
ObjectManager now has an hasObject method to test presence. This
brings it in line with BTreeFolder.
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/lib/python/OFS/ObjectManager.py
U
Log message for revision 40542:
Merged r40536 from 2.9 branch:
ObjectManager now has an hasObject method to test presence. This
brings it in line with BTreeFolder.
Changed:
U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
U
I've added a long needed hasObject method to ObjectManager.
Note that BTreeFolder2 has had it for a long time and it's quite useful.
Enjoy.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
levels are useful too). INFO and BLATHER are for the
administrator. DEBUG and TRACE are for the developer.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev
On 2 Dec 2005, at 11:09, Chris Withers wrote:
Damn, I was working on this at the same time :-S
Florent Guillaume wrote:
I've improved the logging of ConflictError in Zope 2.9 and trunk.
http://svn.zope.org/?rev=40454view=rev
Now you'll get two things:
- logs at level BLATHER for each conflict
to you overwriting without consultation code I
just checked in and that was approved by at least 3 people.
And I'm totally -1 on any logging at level INFO or above about
retriable conflict errors.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http
On 2 Dec 2005, at 20:40, Dieter Maurer wrote:
Florent Guillaume wrote at 2005-12-1 19:49 +0100:
I've improved the logging of ConflictError in Zope 2.9 and trunk.
http://svn.zope.org/?rev=40454view=rev
Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
On 2 Dec 2005, at 20:50, Dieter Maurer wrote:
Florent Guillaume wrote at 2005-12-2 13:33 +0100:
...
Please no. Don't put anything at INFO. A conflict error is either
something normal that should be at level BLATHER or below, or an
ERROR that a sysadmin wants to see logged as such.
I strongly
,
Florent
--
Florent Guillaume, Nuxeo (Paris, France) 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
that *can't* be
retried (and are returned to the user as an error, and are also logged
to the error_log) should be additionally explicitely logged to the
event log, and at which level:
ERROR
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com
().__of__(context)
Then in restricted code you'll be able to do:
...
ob = getStuff(context)
v = ob.viewit()
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope
Log message for revision 40454:
Improved logging of ConflictErrors. Now a log is made at level BLATHER
with traceback for any conflict retried. In addition, a log is made at
level ERROR for a conflict that can't be retried anymore and is returned
to the browser as an error. Nothing is
Log message for revision 40455:
Merged r40454 from 2.9 branch:
Improved logging of ConflictErrors. Now a log is made at level BLATHER
with traceback for any conflict retried. In addition, a log is made at
level ERROR for a conflict that can't be retried anymore and is returned
to the
as an error.
I removed the log at level INFO because it is very misleading for system
administrators in my experience.
Do people want this also for 2.8? Note that it changes the log format, so
may break third party tools that parse logs.
Florent
--
Florent Guillaume, Nuxeo (Paris, France
Log message for revision 40432:
Fixed #1960. Simplified dumb useless dialog.
Changed:
U Zope/branches/Zope-2_8-branch/lib/python/Products/SiteAccess/SiteRoot.py
-=-
Modified:
Zope/branches/Zope-2_8-branch/lib/python/Products/SiteAccess/SiteRoot.py
Log message for revision 40433:
Fixed #1960. Simplified dumb useless dialog.
Changed:
U Zope/branches/2.9/lib/python/Products/SiteAccess/SiteRoot.py
-=-
Modified: Zope/branches/2.9/lib/python/Products/SiteAccess/SiteRoot.py
Log message for revision 40403:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/branches/2.9/lib/python/AccessControl/SecurityInfo.py
U
Log message for revision 40404:
Merged r40403 from 2.9 branch:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/trunk/lib/python/AccessControl/SecurityInfo.py
U
Log message for revision 40405:
Update CHANGES.
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
===
--- Zope/branches/2.9/doc/CHANGES.txt 2005-11-29 14:56:48 UTC (rev 40404)
Log message for revision 40406:
Merged r40403 from 2.9 branch:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
U
Log message for revision 40408:
Added backward compat for suppress_events parameter passing.
Changed:
U Zope/branches/2.9/lib/python/OFS/CopySupport.py
U Zope/branches/2.9/lib/python/OFS/OrderSupport.py
-=-
Modified: Zope/branches/2.9/lib/python/OFS/CopySupport.py
Log message for revision 40409:
Merged r40408 from 2.9 branch:
Added backward compat for suppress_events parameter passing.
Changed:
U Zope/trunk/lib/python/OFS/CopySupport.py
U Zope/trunk/lib/python/OFS/OrderSupport.py
-=-
Modified: Zope/trunk/lib/python/OFS/CopySupport.py
me an ETA on this, so I can decide if and how to
support zope in light of other pressing linux requirements for our distro.
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
strategy.
This is supposed to be open source, can't we be reactive to change in such
situation? Are folks really going to ship their framework code with
_setObject unmodified from the current version when they ship it for Five
1.2 or Zope 2.9?
Florent
--
Florent Guillaume, Nuxeo (Paris, France
please?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) 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
to overwrite
_setObject and _delObject.
Maybe, the code that calls these methods with an additional parameter
should be prepared to meet implementations that do not support
the extra parameter.
I checked in a backward compatibility check for this too.
Florent
--
Florent Guillaume, Nuxeo (Paris, France
to isolate the modification time change in its own
persistent subobject.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http
()
else:
LOG(CustomZODB,PROBLEM,Connection is down)
start_new_thread(keepAlive,())
Why not use the max-disconnect-poll option of the zeoclient section in
zope.conf ?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL
Log message for revision 40389:
Use ObjectCopiedEvent with an 'original' parameter.
Changed:
U Zope/branches/2.9/lib/python/OFS/CopySupport.py
U Zope/branches/2.9/lib/python/OFS/ObjectManager.py
U Zope/branches/2.9/lib/python/OFS/OrderSupport.py
-=-
Modified:
Log message for revision 40390:
Merged 40389 from 2.9 branch:
Use ObjectCopiedEvent with an 'original' parameter.
Changed:
U Zope/trunk/lib/python/OFS/CopySupport.py
U Zope/trunk/lib/python/OFS/ObjectManager.py
U Zope/trunk/lib/python/OFS/OrderSupport.py
-=-
Modified:
not support
the extra parameter.
Maybe. But on the other hand I'd rather not have object manager code
slowed down and uglified to suit the negligibly small number of classes
that are in this case, and that can be trivialy upgraded in a
forward-compatible manner.
Florent
--
Florent Guillaume
threads are blocked at.
From the description I'd wager that you'll find your threads stuck in a
corner of the MySQL DA. In which case you'd have to find why it
deadlocks and find a fix.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com
On 26 Nov 2005, at 09:28, Hanno Schlichting wrote:
Florent Guillaume wrote:
I've done a big checkin to switch practically everything to the
new- style (actually they're 5 years old) security declarations.
I'd appreciate if another set of eyes could double-check
everything; while I've taken
Log message for revision 40371:
Merged 40370 from 2.9 branch:
Send ContainerModifiedEvent when appropriate.
This requires Five 1.3+ = r20254.
Some BBB has been kept until Zope 3.2 = r40368 is stiched in.
Changed:
U Zope/trunk/lib/python/OFS/CopySupport.py
U
Log message for revision 40372:
Updated to Five 1.3b4.
Changed:
U Zope/branches/2.9/lib/python/Products/Five/CHANGES.txt
U Zope/branches/2.9/lib/python/Products/Five/__init__.py
U Zope/branches/2.9/lib/python/Products/Five/tests/event.txt
U
Log message for revision 40375:
Forgotten in Five 1.3b4 merge.
Changed:
A Zope/trunk/lib/python/Products/Five/monkey.py
-=-
Added: Zope/trunk/lib/python/Products/Five/monkey.py
===
---
on a
naked Zope?
from ZODB.POSException import ConflictError
raise ConflictError
Guess what, I know that. But I want a real ConflictError, to see what
useful info about involved objects I can log.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http
2.9 and
Zope 2 trunk to make them work. I'll do that later today.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http
Florent Guillaume wrote:
I've made changes so that Five and (Zope 2.9 Zope 2 trunk) send
IContainerModifiedEvents when appropriate. These events are new in Zope
3.2, and subclass IObjectModifiedEvents.
This is of course available in Five 1.2 and Five 1.3.
I still have to stich
to do so.
Florent
--
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
http://mail.zope.org/mailman/listinfo/zope-checkins
--
Florent Guillaume, Nuxeo (Paris, France) 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
://mail.zope.org/pipermail/zope-checkins/2005-November/030103.html
Thanks,
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http
is logged, I'll add something at level ERROR.
BTW does someone have a handy script to provoke conflict errors on a
naked Zope?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
that it is not so
obtuse? My monkey-patch now has to munge two methods
to make xml uploads work and I am less happy with it
than I was before.
This could be turned into a disable-xmlrpc config option. Could you
provide your updated monkey-patch?
Florent
--
Florent Guillaume, Nuxeo (Paris, France
then be used to test DateTime or to test
another potential implementation. That would go a long way to help
actually write a new implementation.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED
Log message for revision 40280:
Merged r40279 from 2.9 branch:
Warn when an attempt is made to have a security declaration on a
nonexistent method. Removed one such method.
Fixed unclear security declarations. When bug 761 was fixed,
declareProtected(perm) was made illegal, at
Log message for revision 40281:
Merged r40279 from 2.9 branch:
Warn when an attempt is made to have a security declaration on a
nonexistent method. Removed one such method.
Fixed unclear security declarations. When bug 761 was fixed,
declareProtected(perm) was made illegal, at
[Intended for zope-dev actually...]
Florent Guillaume wrote:
Florent Guillaume wrote:
I'm in the process of refactoring OFS to use new-style security
declarations (about time ;)), and I stumbled on something which may
or may not be a bug, I don't know, I'd like some else's opinion
Products.CMFSetup.tool.SetupTool has a security
declaration for nonexistent method 'runAllSetupSteps'
WARNING Init Class Products.CMFSetup.tool.SetupTool has a security
declaration for nonexistent method 'executeStep'
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http
/src/zope/Zope2.8/lib/python/Shared/DC/ZRDB/TM.py, line 64,
in abort
try: self._abort()
File /opt/zope/zproducts/standard/ZMySQLDA/db.py, line 389, in _abort
self._tlock.release()
error: release unlocked lock
Well undoubtedly the bug is in ZMySQLDA...
Florent
--
Florent Guillaume
?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) 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
Florent Guillaume wrote:
I'm in the process of refactoring OFS to use new-style security
declarations (about time ;)), and I stumbled on something which may or
may not be a bug, I don't know, I'd like some else's opinion:
The class SimpleItem has the definition (it's been there since
for Products.ZMySQLDA.db.DB instance at
0x41487acc at 1190774252
Same here, the traceback is important.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist
to schedule bug days. One per
week, or something like that. Otherwise nobody will set aside the time
to discuss, investigate and fix the current bugs.
BTW I'm for removing the 2.9 branch for now.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http
or a feature...it's basically a question of having
time...
But having specific days set aside is still a good incentive.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev
')
or
manage_changeProperties(**somemapping)
I've been meaning to fix Zope for years but...
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org
might pick them up on next
bugday?
There's already one actually: http://www.zope.org/Collectors/Zope/878
It's really the code that should be changed, the patch in the
collector (modernized a bit) would be enough.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33
.
=
Apologies for the long email but I have no idea what's going on... if
ANYONE has ANY suggestions or ideas on what else I could investigate
it would be GREATLY appreciated!
Thank you!
Garth
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http
which results in a even more loaded queue on
the booting server ...
Does this sound reasonable to make the behaviour of opening the ports
configurable? Does anybody have an idea how hard this would be to do?
Cheers,
Christian
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33
101 - 200 of 505 matches
Mail list logo
