1. 03 Nov, 2004 4 commits
  2. 02 Nov, 2004 3 commits
    • Sidnei da Silva's avatar
      1bb6f655
    • Sidnei da Silva's avatar
      · 45e5350a
      Sidnei da Silva authored
            - Always unescape element contents on webdav.xmltools
      
            - Use saxutils to escape/unescape values for/from
              PROPFIND/PROPPATCH.
      
            - Make OFS.PropertySheet use the escaping function from
              webdav.xmltools.
      
            - Escape/unescape " and '
      
            - Set a default value of '' for the new 'alt' property as not to
              break existing content.
      45e5350a
    • 's avatar
      fixed typo · df259636
      authored
      df259636
  3. 31 Oct, 2004 1 commit
    • Andreas Jung's avatar
      · e4679cb4
      Andreas Jung authored
            - Collector #1443: Applied patch by Simon Eisenmann that reimplements 
              the XML parser used in WebDAV fixing a memory leak.
      e4679cb4
  4. 30 Oct, 2004 8 commits
  5. 29 Oct, 2004 6 commits
  6. 18 Oct, 2004 1 commit
    • Tim Peters's avatar
      Collector 1542: Python 2.4/Zope 2.8 unittest failure in asyncore.py · b11eabb7
      Tim Peters authored
      Forward port form 2.7 branch.
      
      medusa's class monitor_server derives from asyncore.dispatcher, but
      never called the latter's constructor.  As a result, the ._map attribute
      set by 2.4's asyncore.dispatcher.__init__() never gets set, and calling
      asyncore methods later dies with an AttributeError on ._map.  The fix
      is a 1-liner, adding a call to the base-class constructor.
      b11eabb7
  7. 17 Oct, 2004 1 commit
  8. 15 Oct, 2004 4 commits
  9. 14 Oct, 2004 2 commits
  10. 13 Oct, 2004 1 commit
  11. 12 Oct, 2004 4 commits
  12. 11 Oct, 2004 1 commit
  13. 10 Oct, 2004 1 commit
  14. 09 Oct, 2004 1 commit
  15. 08 Oct, 2004 2 commits
    • Tim Peters's avatar
      Gentler treatment for issue #1350. · 3f0db85b
      Tim Peters authored
      The Python fatal errors occur only in a debug build now.
      
      In a release build, unghostify() raises a Python SystemError
      exception if it detects insanity, and ghostify() ignores the
      problem (as ZODB 3.2 did, although it looks like 3.2 ignored
      the problem by mistake).  This isn't *good*, because the
      system is insane.  But it can become insane only by breaking
      absolute threading rules, and that "should never happen".
      Unfortunately, hundreds of things can go wrong if it does
      happen, and we can't detect most of them.
      3f0db85b
    • Tim Peters's avatar
      Extreme sanction for collector #1350. · 17c89bd8
      Tim Peters authored
      In ghostify() and unghostify(), trigger a fatal error if the
      object is insane.  This prevents a segfault (or, worse, arbitrary
      memory corruption) later.
      
      The test suite isn't bothered by this, and neither is bringing
      up a Zope and playing around with it.  The only known cause
      appears to be threading problems related to Transience.py,
      partly explained in issue #1350.  It should be impossible for
      these fatal errors to trigger via thread-correct use of ZODB.
      
      I don't expect to keep these fatal errors in the code; indeed,
      I'm checking this in only in Zope's *copy* of ZODB.  The intent
      is to help whoever can make time for 1350 know whether that
      problem still exists, until that problem goes away.  Unfortunately,
      it's not even possible to raise an exception from ghostify()
      (it's a void routine that "can't fail"), so it takes an extreme
      measure to catch the problem as soon as it's visible.
      17c89bd8