External Methods: Object behavior different in 2.4.2 ?
Hello, I have an External Method that imports a module that in turn imports a Python/C library ... (A SWIG'ified software with shadow classes). This used to work fine in 2.4.1 ... But now in 2.4.2 I am having problems: It seems I can only run it once! If I hit refresh or something like that, I get the following error: Traceback (innermost last): File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.4.2/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: Zope) File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.4.2/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: drawmap) File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: drawmap) File /usr/local/Zope-2.4.2/lib/python/Products/ExternalMethod/ExternalMethod.py, line 274, in __call__ (Object: drawmap) (Info: ((400, 340, 'left'), {}, (400, 340, 'left'))) File /usr/local/Zope-2.4.2/Extensions/mapserver.py, line 6, in drawmap File /usr/lib/python2.1/mapscript.py, line 1041, in __setattr__ TypeError: Type error. Expected _p_mapObj And on the console: Exception exceptions.TypeError: 'Type error. Expected _p_mapObj' in <method mapObj.__del__ of mapObj instance at 0x895bafc> ignored Here is the code, it is short: from mapscript import * import tempfile def drawmap(width=400,height=340,align="left"): mymap = mapObj("/home/mapdata/nac/177.map") mymap.width = width mymap.height = height myimage = mymap.draw() oldtempdir = tempfile.tempdir tempfile.tempdir = "" mytempfile = tempfile.mktemp() tempfile.tempdir = oldtempdir msSaveImage(myimage,"/usr/local/apache/htdocs/tempimages/"+mytempfile,0,0,0, 0) return "<IMG SRC=http://localhost/tempimages/"+mytempfile+" ALIGN="+align+" BORDER=0>" Note the "mapObj" called "mymap" ... It does all the work. From what I see above, once the object is instanciated, there's a problem destroying it, or instantiating a new one ... This might be why I get th error above. Funny thing is this worked fine in 2.4.1 ... Is this a bug, or did some sort of behavior change with 2.4.2? And if so how do I get around it? I tried adding a "mymap = None" here and there to force the object to be destroyed after/before use, but that didn't seem to help. Any ideas? Thanks in advance, Jean-François Doyon Internet Service Development and Systems Support GeoAccess Division Canadian Center for Remote Sensing Natural Resources Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410
So it looks like the error occurs outside of Zope, in your library... what has that got to do with 2.4.2? Cheers. -- Andy McKay. ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon@CCRS.NRCan.gc.ca> To: <zope@zope.org> Sent: Tuesday, October 30, 2001 1:04 PM Subject: [Zope] External Methods: Object behavior different in 2.4.2 ?
Hello,
I have an External Method that imports a module that in turn imports a Python/C library ... (A SWIG'ified software with shadow classes).
This used to work fine in 2.4.1 ... But now in 2.4.2 I am having problems:
It seems I can only run it once! If I hit refresh or something like that, I get the following error:
Traceback (innermost last): File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.4.2/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: Zope) File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.4.2/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: drawmap) File /usr/local/Zope-2.4.2/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: drawmap) File
/usr/local/Zope-2.4.2/lib/python/Products/ExternalMethod/ExternalMethod.py,
line 274, in __call__ (Object: drawmap) (Info: ((400, 340, 'left'), {}, (400, 340, 'left'))) File /usr/local/Zope-2.4.2/Extensions/mapserver.py, line 6, in drawmap File /usr/lib/python2.1/mapscript.py, line 1041, in __setattr__ TypeError: Type error. Expected _p_mapObj
And on the console:
Exception exceptions.TypeError: 'Type error. Expected _p_mapObj' in <method mapObj.__del__ of mapObj instance at 0x895bafc> ignored
Here is the code, it is short:
from mapscript import * import tempfile
def drawmap(width=400,height=340,align="left"): mymap = mapObj("/home/mapdata/nac/177.map") mymap.width = width mymap.height = height myimage = mymap.draw() oldtempdir = tempfile.tempdir tempfile.tempdir = "" mytempfile = tempfile.mktemp() tempfile.tempdir = oldtempdir
msSaveImage(myimage,"/usr/local/apache/htdocs/tempimages/"+mytempfile,0,0,0,
0) return "<IMG SRC=http://localhost/tempimages/"+mytempfile+" ALIGN="+align+" BORDER=0>"
Note the "mapObj" called "mymap" ... It does all the work. From what I see above, once the object is instanciated, there's a problem destroying it, or instantiating a new one ... This might be why I get th error above.
Funny thing is this worked fine in 2.4.1 ... Is this a bug, or did some sort of behavior change with 2.4.2? And if so how do I get around it?
I tried adding a "mymap = None" here and there to force the object to be destroyed after/before use, but that didn't seem to help.
Any ideas?
Thanks in advance,
Jean-François Doyon Internet Service Development and Systems Support GeoAccess Division Canadian Center for Remote Sensing Natural Resources Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Tue, 2001-10-30 at 14:14, Andy McKay wrote:
So it looks like the error occurs outside of Zope, in your library... what has that got to do with 2.4.2?
That depends. If all was fine in 2.4.1, as he indicates, and the only change was to move to Zope 2.4.2, and now there is a problem, then the source would tend to lie within Zope. Of course, it may be that the problem existed in 2.4.1, but was not percolated up into Zope until a change in 2.4.2. Either way, provided the external method and accompanying software did not change, then Zope be the point ot start looking, IMO. Bill
participants (3)
-
Andy McKay -
Bill Anderson -
Doyon, Jean-Francois