- Zope - Zope lists

Re: [ZOPE] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

Chris: the errors I get are always ConflictErrors without any usable tracebacks. I would like to give more information, but it really is very complex when you go a little deeper and would probably not be useful. I'll try to describe it a little better anyway: I have an Object that offers an interface for dispatching methods. It does so by deciding wether the method's object is on the local server or not, and depending on that, calls it via XML-RPC or via the ZOPE context (self). A remote ZOPE server cannot be part of a ZEO backend because there need to be several (hundred) self sustained servers that can act on their own when the connection to the others fails (which is likely rather than possible). But, as I just realised - in an internet context, isn't it possible that something like this could happen without even being part of a design? One ZOPE server's object, say, "LibraryManager", calls an object in another ZOPE server, say "UniversityLibrary", via XML-RPC (because it doesn't even know it's ZOPE). It asks it for a book. The University Library doesn't have it, but it has a service that looks in all the libraries it knows and returns any found occurences. Thus, at some point during that call, it asks the first server's LibraryManager about the book - again, not even knowing that it is a ZOPE server, via XML-RPC. Should this work, and where does it differ from what I'm doing? > > The problem is that it isn't my design, and the design is part of a > > contract. I can't really do anything about that (the major problem is > > that there will be SOAP components that might even need to be > > transparently integrated - which completely excludes ZEO). > Why do you think that? ZEO is simply a single point of persistence for > a group of Zope Application Servers. But what if I don't know which components are ZOPE, and components can be transparently exchanged? Ole

1 1

Re: [Zope] Hooks for methods other than GET/POST on port 80?
by Chris Withers 12 Dec '05

12 Dec '05

(please keep the list CC'ed in) Roman Susi wrote: >> What do you mean by freezes? how did you cause this to happen? > > Surely, this is not only a bug but a security issue leading to DOS > attack, IMHO. Well, it's a pretty weird use case from what I can see... > >> >>> Traceback (most recent call last): >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 674, in emit >>> msg = self.format(record) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 567, in >>> format >>> return fmt.format(record) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 369, in >>> format >>> s = s + self.formatException(record.exc_info) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 342, in >>> formatException >>> traceback.print_exception(ei[0], ei[1], ei[2], None, sio) >>> File "/usr/local/lib/python2.3/traceback.py", line 123, in >>> print_exception >>> print_tb(tb, limit, file) >>> File "/usr/local/lib/python2.3/traceback.py", line 68, in print_tb >>> line = linecache.getline(filename, lineno) >>> File "/usr/local/lib/python2.3/linecache.py", line 14, in getline >>> lines = getlines(filename) >>> RuntimeError: maximum recursion depth exceeded >> >> We need more of the traceback, there is no repeating part here so it's >> impossible to see what's causing the infinite recursion... >> > I am not sure how to get the whole traceback... Well, where did you see the above? > Chris, could you put this into Zope issue tracker (with security tick as > I do not want to make this info public right now)? > (I've tried but I do not have an account there..) No, there's nothing stopping you registering at zope.org and doing this yourself. Furhtermore, I'd guess this is likely a bug in your code and nothing to do with Zope ;-) (of course, I could be wrong on that, but I haven't seen any evidence yet) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 10

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

The problem is that it isn't my design, and the design is part of a contract. I can't really do anything about that (the major problem is that there will be SOAP components that might even need to be transparently integrated - which completely excludes ZEO). I tried doing my own commits, but it doesn't work, it just bombs earlier (no matter where I do them). I really don't know why, my only guess is that something about the transaction management breaks terribly when you go back and forth between objects without them being able to track it. Only I cannot figure out what. It is not possible to do _really_ explicit transaction management with ZODB, is it? Ole 2005/12/12, Alan Milligan <alan(a)balclutha.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan-Ole Esleben wrote: > > OK, the following is the case: > > > > The setup is for functions dispatching either locally or via XML-RPC. > > At the moment, the mechanism I use is to detect locality is flawed and > > thus doesn't work well. So I have local XML-RPC calls where I could > > have global ones. But. > > > > 1. I need that possibility for testing the XML-RPC setup. I cannot set > > up multiple instances for every cheap test. At least I shouldn't have > > to. The very important reason, however, is: > > 2. This is a generic call dispatcher. It is used, for example, for > > object name resolution in a widely deployed system. So, what could > > happen and couldn't happen locally is this: > > Zope isn't CORBA. ZEO is the correct way to scale/cluster Zope's. > > > > > 1. Server1 dispatcher calls, via XML-RPC, Server2. > > 2. Server2 dispatcher calls Server1, which does something locally > > (same communication management object as the dispatcher, maybe another > > local call) and then returns > > > > This is the same problem spread out over two servers, where locality > > isn't possible anymore. The call from Server1 to Server2 must be made > > via XML-RPC and I cannot exclude Server2 calling Server1 back. > > If you really must architect your solution this way, then you are going > to have to do your own transaction management. Your 'local' calls need > to do explicit commit() calls and you're going to have to reread > 'tainted' objects. > > Again, it will take you half an hour to modify your design instead of > half a year to get all the bugs out of your implementation. > > Alan > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnN2ACfroLk4EZpkRAkQ7AJ4rTWpmldRq1GoPGIV8r0CT7+VPJwCZAbKB > 5PBuLd5sJgh7QZe1ey8lZ9g= > =3TrG > -----END PGP SIGNATURE----- >

2 1

Re: [Zope] zdsock
by John Poltorak 12 Dec '05

12 Dec '05

On Sun, Dec 04, 2005 at 11:32:15AM +0100, Andreas Jung wrote: > WHY? Because 'zdsock' is not an acceptable name. I am running on OS/2 and the path name must start with '\\socket\\'. > --On 4. Dezember 2005 10:26:03 +0000 John Poltorak <jp(a)warpix.org> wrote: > > > On Sun, Dec 04, 2005 at 11:13:29AM +0100, Andreas Jung wrote: > >> > >> > >> > > >> > At the top of sample.conf it says > >> > > >> ># Sample config file for zdctl.py and zdrun.py (which share a schema). > >> > > >> > This sounds like something other than zope.conf. > >> > > >> > >> Is there a real need for you to touch the configuration. Also as very > >> advanced Zope user I've never had the need to touch this configuration > >> for any reason. So what are your reasons? > > > > I need to change the name of the socket. > > > >> > >> -aj > > > > -- > > John -- John

4 16

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

OK, the following is the case: The setup is for functions dispatching either locally or via XML-RPC. At the moment, the mechanism I use is to detect locality is flawed and thus doesn't work well. So I have local XML-RPC calls where I could have global ones. But. 1. I need that possibility for testing the XML-RPC setup. I cannot set up multiple instances for every cheap test. At least I shouldn't have to. The very important reason, however, is: 2. This is a generic call dispatcher. It is used, for example, for object name resolution in a widely deployed system. So, what could happen and couldn't happen locally is this: 1. Server1 dispatcher calls, via XML-RPC, Server2. 2. Server2 dispatcher calls Server1, which does something locally (same communication management object as the dispatcher, maybe another local call) and then returns This is the same problem spread out over two servers, where locality isn't possible anymore. The call from Server1 to Server2 must be made via XML-RPC and I cannot exclude Server2 calling Server1 back. Does this make it a little more of a real problem? Ole 2005/12/12, Alan Milligan <alan(a)balclutha.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan-Ole Esleben wrote: > >>It really *is* in your interests to ensure a single request completes > >>all your functional requirements ;) > > > > > > That's not possible unfortunately. The design of the system is rather > > complex, and unalterable in this respect. However, it is not true that > > it is usually possible to fulfil this requirement. What of programs > > running on an operating system that call other programs via that > > operating system? > > > > I don't believe you. > > You have a client application calling your Zope server's bla() > function. It can do this either by HTTP or XML-RPC by choosing the > appropriate Content-Type. > > You've chosen to implement this interface by making other XML-RPC calls > to the same server to complete the task. This is both unnecessary and > bad. Unnecessary because you're doing an RPC when you've got all you > need in local memory. This is bad because you're introducing the > additional overhead of setting up said RPC. Worse, you're now > responsible for your own transaction management because you've split the > task across multiple ZODB connections. > > You need to think about the *correct* way to write your bla() function. > In doing this, you want to be able to take advantage of the automatic > rollback facilities of Zope by keeping all of this in one transaction, > which will also avoid your initial problem of conflict errors. > > Alan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnNZcCfroLk4EZpkRArTDAJ96TGwDy047D09jkmRNbGyD7e+3QgCg0aNZ > lLo0znXi4qvXr5j4SseH2k8= > =hu4V > -----END PGP SIGNATURE----- >

1 0

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

> It really *is* in your interests to ensure a single request completes > all your functional requirements ;) That's not possible unfortunately. The design of the system is rather complex, and unalterable in this respect. However, it is not true that it is usually possible to fulfil this requirement. What of programs running on an operating system that call other programs via that operating system? Given that that is a requirement that needs to be met, do I have any options? Ole

1 0

Re: live dtml updating?
by Rich Harley 11 Dec '05

11 Dec '05

On Sunday 11 December 2005 22:30, you wrote: > > Hi all > > > > Sorry if this is not a specific zope question but I'm confident someone > > will be able to help me with the following. > > > > I have an input form on a webpage and below it a table which pulls out of > > a database. The column headers in the table relate to the input form in > > that I want whatever the user types into the input box for the correct > > column to be highlighted in bold. So say, for example I had two columns A > > and B I want column B to be highlighted bold when the user types 'b' into > > the input box > > at > > > the top. How can I do this? > > Rich -- www.horsey.tk

3 3

Zwiki contributor policy update
by Simon Michael 11 Dec '05

11 Dec '05

Hi all! I'm slightly burned out and bored with certain areas of Zope 2 Zwiki development. I think the product will provide some value for a while yet, and it's not too late to shake things up and make a bigger splash. If we don't do this during the period of Zwiki & Zope 2's relevance, our good work will bring less benefit than it might have. So I'm putting out a call for help. I'd really like to see more people take on development of Zwiki. What are the roadblocks - of my making, and otherwise - to a more active Zwiki developer community ? For one thing I needed to nail down some copyright/license issues more explicitly, to make contributing and accepting contributions more of a no-brainer. Here's my latest thinking: LICENSE Much Zope code uses the ZPL. We want to maximize code sharing and participation with the whole Zope community. Much of the rest of the FOSS world uses the GPL, and the same goes for them. Dual GPL/ZPL licensing may seem a good option, but I'm convinced it's not worth the added complexity, legal uncertainty and fragmentation; either straight GPL or straight ZPL is preferable. GPL is the mainstream license for the future IMHO, I think it's still the best option, and I have no plan to leave it. Also I think we should adopt GPLv3? <http://zwiki.org/PolicyAnnouncementDraft/createform?page=GPLv3> when it's ready. That said, there's now clear policy allowing non-GPL code to be added to Zwiki if necessary (below). Also I remain open to license exemption requests from Zope developers. COPYRIGHT I no longer think the single copyright holder policy is best for this project, and I'm going to drop it. I am changing the main repo's policy to multiple copyright holders (& allowing multiple licenses), with the simple condition that the overall project manager is assigned the right to relicense to newer license versions. The powerful darcs revision control system (together with new CONTRIBUTORS list) should help us to keep track of copyright & licensing status and even remove problematic commits later if needed. CONTRIBUTOR'S AGREEMENT To ensure that everyone gets proper credit for their work; a clear audit trail and legal status for the project; and that the project can remain license-compatible with other free & open-source software in future, I have added a very simple contributor agreement/contributor list: http://zwiki.org/repos/ZWiki/CONTRIBUTORS.txt . All Zwiki contributors should read and consider signing this file, to help us meet these goals. You can follow this easy procedure to add your name to the glorious list: (install darcs if needed, see http://darcs.net/DarcsWiki/CategoryBinaries) darcs get --partial http://zwiki.org/repos/ZWiki cd ZWiki echo "- Your Name <your@email>" >>CONTRIBUTORS.txt darcs record -a -m"signed it" CONTRIBUTORS.txt (enter your name & email address again) darcs send This will become the authoritative list of code committers (at least), and I'll be working to make sure all of you are listed properly. Many have donated their time and creativity over the years - this list will make that clearer. All comments, help and other ideas welcome. And I hope to see some of you online or off. Happy holidays, and thanks -Simon

1 0

resolving conflict errors
by Dennis Allison 10 Dec '05

10 Dec '05

Zope 2.7.6 I am a bit confused. I have a Zope DTML method that is generating ZODB conflict errors. The DTML method identified as producing the conflicts is a list of calls to other methods, conditionally executed. Most conflicts don't cause problems because the backoff and restart of the initial transaction will not have changed global state. In our particular case, the conflicting transaction has changed global state in our RDBMS so when it gets rerun, some RDBMS transactions are duplicated. And that's a problem. The solution, of course, is to resolve the conflicts properly. The first question: what data is generating the conflict? The DTML code and all the method references are static and unchanged. What data does Zope store in the ZODB when an object is evaluated? Presumably conflicts can be reolved programatically by setting a method on the object _p_resolveConflict( self, old, saved, new ) and returning one or another of the states (old, saved, new). It's not real clear how to do it. --

4 9

First International Workshop on Free/Open Source EIS/ERP
by Rogério Atem de Carvalho 10 Dec '05

10 Dec '05

Dear Colleague, as the First International Workshop on Free/Open Source EIS/ERP organizer, I would like to invite you to submit a paper to it. This event is the first one, of international dimension, dedicated to free/open source EIS/ERP and will be held in parallel to the IFIP TC8 International Conference on Research and Practical Issues of Enterprise Information Systems 2006 (CONFENIS 2006). We expect papers from both academicians and practitioners, in all subjects related to Enterprise Information Systems and Enterprise Resources Planning. Authors that do not focus their work specifically in free/open source software can submit to Confenis 2006. Elsevier will publish proceedings of both events and best papers will be also published by top ranking IEEE and ACM periodicals. More information is available at http://www.confenis.org. About the IFIP: The IFIP (International Federation for Information Processing) was created in 1960 under the auspicious of UNESCO; it aggregates the main computer societies worldwide, including the ACM and IEEE. It is responsible for the realization of top ranking conferences like IFIP/W3C/ACM International World Wide Web Conference and IEEE/ACM/IFIP International Conference on Hardware/Software Codesign & System Synthesis. More information about IFIP is available at http://www.ifip.or.at/ About the IFIP TC8: The IFIP Technical Committee 8 Information Systems is divided in many subcommittees, each one for a specific IS area: · WG 8.1 Design and Evaluation of Information Systems · WG 8.2 Interaction of Information Systems and the Organization · WG 8.3 Decision Support Systems · WG 8.4 E-Business: Multi-disciplinary research and practice · WG 8.5 Information Systems in Public Administration · WG 8.6 Transfer and Diffusion of Information Technology · WG 8.8 Smart Cards At http://ifiptc8.itu.dk/ more information can be found about the IFIP TC8. Please forward this message and CFPs to other EIS/ERP researchers and practitioners. Best regards, -- Prof. Rogério Atem de Carvalho, D.Sc. Gerente de Pesquisa / Research Manager CEFET Campos _______________________________________________________________________ ''O remetente desta mensagem é o responsável pelo seu conteúdo e endereçamento. A utilização deste meio para fins que não aqueles dispostos na Portaria nº 267, de 20 de outubro de 2003 da Direção Geral do CEFET CAMPOS, é passível das sanções cabíveis, dispostas nas normas internas para utilização de correio eletrônico e acesso à Internet.'' _______________________________________________________________________ Servidor de E-mail CEFET Campos

1 0