Am 22.08.2014 um 00:57 schrieb Jolitz Ben - bjolit:
> The following patch will make it install from pip quite fine on current
> Python 3 versions.
Thanks for the tip, Ben. DBUtils was not developed with Python 3 in
mind, and I only tested and used it with Python 2, so I was amazed to
see that this works without further modifications. I've now run the test
suite on Python 3.4 and indeed it only found a minor problem that I've
already fixed in trunk. If you find any other issues, let me know.
-- Christoph

The following patch will make it install from pip quite fine on current Python 3 versions.
I set the minor for Python 3 to ’10' as there are no expected major syntax changes to Python 3 planned and it is reasonable to assume this package will function well with 2to3 being run, but it really is just a number.
Cheers,
Ben Jolitz
diff -Naur DBUtils-1.1/setup.py DBUtils-1.1-fix/setup.py
--- DBUtils-1.1/setup.py 2011-08-14 05:01:30.000000000 -0700
+++ DBUtils-1.1-fix/setup.py 2014-08-21 15:55:04.000000000 -0700
@@ -7,7 +7,7 @@
from sys import version_info
py_version = version_info[:2]
-if not (2, 3) <= py_version < (3, 0):
+if not (2, 3) <= py_version < (3, 10):
raise ImportError('Python %d.%d is not supported by DBUtils.' % py_version)
import warnings
@@ -66,5 +66,6 @@
license='Open Software License',
packages=['DBUtils', 'DBUtils.Examples', 'DBUtils.Tests'],
package_data={'DBUtils': ['Docs/*']},
- zip_safe=0
+ zip_safe=0,
+ use_2to3 = True
)
***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.
If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.
If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.
Thank You.
****************************************************************************

On Sunday, May 11, 2014 10:10:25 am Christoph Zwerschke wrote:
> Am 11.05.2014 03:30, schrieb Jeff Simmons:
> > Probably needs a small change in the Makefile, but I'm not enough of a C
> > programmer to know what. Any help would be appreciated.
>
> As far as I see, the problem may be that the "make" of OpenBSD does not
> support $^ internal macro as GNU/Linux does.
>
> Try to replace the $(^F) with the full list of prerequisites, i.e.:
> wkcgi.o marshal.o environ.o wkcommon.o parsecfg.o
>
> -- Christoph
I've tried various variations on this, and was unable to get the Makefile to
work. Must be some other things they don't support.
Fortunately, manually compiling and linking the various *.c files produces a
working program.
--
Jeff Simmons jeff@...
Simmons Consulting - Network Engineering, Administration, Security

Am 11.05.2014 03:30, schrieb Jeff Simmons:
> Probably needs a small change in the Makefile, but I'm not enough of a C
> programmer to know what. Any help would be appreciated.
As far as I see, the problem may be that the "make" of OpenBSD does not
support $^ internal macro as GNU/Linux does.
Try to replace the $(^F) with the full list of prerequisites, i.e.:
wkcgi.o marshal.o environ.o wkcommon.o parsecfg.o
-- Christoph

Am 30.04.2014 18:32, schrieb F. Behrens:
> for the first time in many years, a webware project for a customer has
> developed constant failure conditions. I do, however, have problems to
> isolate possible causes.
Never came across this kind of error. Maybe there is a memory leak and
it happens your server is running out of memory? I would monitor memory
usage and look if this is correlated.
-- Christoph

Hi all,
for the first time in many years, a webware project for a customer has
developed constant failure conditions. I do, however, have problems to
isolate possible causes.
Webware runs with mod_webware in apache. In irggualr intervals, the
following happens:
Exception in worker thread
-- CMDERR: cmd: ['CONNECT', 669L, 0] -> reply: Connection already active.
Traceback (most recent call last):
File "/opt/webware/WebKit/ThreadedAppServer.py", line 688, in threadloop
---------> Duplicate connect requests from 84.153.216.42 and
80.145.254.106 ??
handler.handleRequest()
File "/opt/webware/WebKit/ThreadedAppServer.py", line 1134, in
handleRequest
requestDict = self.receiveDict()
File "/opt/webware/WebKit/ThreadedAppServer.py", line 916, in receiveDict
block = self._sock.recv(missing)
error: [Errno 9] Bad file descriptor
[ ... 200-300 more of these tracebacks, then a lot of consecutive
"Exception in worker thread" lines, then more tracebacks and so on ...]
As I see it, the failure point is in AppServer, while trying to receive
parts of a request header in dictionary format - apparently from a
socket that has somehow become invalid. Interesting enough it can happen
that some hours(!) later, the AppServer suddenly continues to work
properly, without restart.
When I restart the Appserver completely, the problem is gone immediately.
I'd appreciate any hint on where to begin the investigation and what to
look after.
Thank you for reading!

Am 08.09.2013 18:47, schrieb Roger Haase:
> I noticed a few inconsistencies on line endings on the 1.1.1 release.
Thanks Roger, I fixed the .py files in the repository now.
The .config and .bat files seem to be ok in the distributed archive,
though. Can you check again?
-- Christoph

I noticed a few inconsistencies on line endings on the 1.1.1 release. These files have DOS line endings, should be unix:
WebKit/Configs/Application.config
WebKit/SessionMemcachedStore.py
WebKit/Adapters/WSGIAdapter.py
WebKit/Testing/DebugPage.py
WebKit/Testing/FieldStorage.py
WebKit/Tests/memcache.py
WebUtils/Tests/TestFieldStorage.py
..and this one has unix line endings, should be DOS:
bin/editfile.bat
Many thanks to Christoph for taking the time to maintain Webware for Python.
Roger Haase

Bugs item #3510197, was opened at 2012-03-22 12:49
Message generated for change (Comment added) made by cito
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3510197&group_id=4866
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: WebKit
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Adam Smith (adamdesmith)
>Assigned to: Christoph Zwerschke (cito)
Summary: HTTPRequest.serverPath() fallback fails on forwarding
Initial Comment:
HTTPRequest.serverPath() is supposed to return the path given to the web server before any rewrites. If the SCRIPT_URL values is set, it does this correctly. If is not, it falls back to constructing this path from the _servletPath and _pathInfo variables.
However, consider the case when a request is forwarded from one servlet to another (via Application.forward). In this case, _pathInfo gets rewritten (forward calls includeURL, which calls HTTPRequest.push(), which then rewrites _pathInfo via setURLPath()). Now HTTPRequest.serverURL() returns not the originally requested URL, but instead the URL of the servlet that WebKit has forwarded the request to.
As _pathInfo cannot reliably provide the serverPath, it should not be used in a fallback. Instead, it should attempt to extract a path from SCRIPT_URI and/or REQUEST_URI (perhaps using python's urlparse module). If neither are set, an exception should be raised rather than provide the client with potentially incorrect data.
----------------------------------------------------------------------
>Comment By: Christoph Zwerschke (cito)
Date: 2013-01-17 12:06
Message:
Sorry, for leaving this open for so long. Fixed now in r8249.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3510197&group_id=4866

Bugs item #3510197, was opened at 2012-03-22 12:49
Message generated for change (Tracker Item Submitted) made by adamdesmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3510197&group_id=4866
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: WebKit
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Smith (adamdesmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPRequest.serverPath() fallback fails on forwarding
Initial Comment:
HTTPRequest.serverPath() is supposed to return the path given to the web server before any rewrites. If the SCRIPT_URL values is set, it does this correctly. If is not, it falls back to constructing this path from the _servletPath and _pathInfo variables.
However, consider the case when a request is forwarded from one servlet to another (via Application.forward). In this case, _pathInfo gets rewritten (forward calls includeURL, which calls HTTPRequest.push(), which then rewrites _pathInfo via setURLPath()). Now HTTPRequest.serverURL() returns not the originally requested URL, but instead the URL of the servlet that WebKit has forwarded the request to.
As _pathInfo cannot reliably provide the serverPath, it should not be used in a fallback. Instead, it should attempt to extract a path from SCRIPT_URI and/or REQUEST_URI (perhaps using python's urlparse module). If neither are set, an exception should be raised rather than provide the client with potentially incorrect data.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3510197&group_id=4866

Bugs item #3499505, was opened at 2012-03-08 04:11
Message generated for change (Comment added) made by cito
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3499505&group_id=4866
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: WebKit
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marek (warth)
Assigned to: Nobody/Anonymous (nobody)
Summary: staticmethod uses self
Initial Comment:
Hi,
a couple of days ago I got an application written in WebWare 1.1 to make some adjustments in it.
While preparing an environment for running I've encountered a problem. The application was raising an exception:
"NameError: global name 'self' is not defined" in WebKit/HTTPContent.py:321.
After looking into this file I've found this piece of code:
@staticmethod
def callMethodOfServlet(url, method, *args, **kwargs):
return self.application().callMethodOfServlet(self.transaction(), url, method, *args, **kwargs)
After removing @staticmethod decorator and adding the missing "self" parameter everything works like a charm.
At the moment I'm trying to find out if it is a bug in the WebWare (as it looks like to me) or does my software use the framework in a -wrong- way and the lack of the first parameter is intended?
----------------------------------------------------------------------
>Comment By: Christoph Zwerschke (cito)
Date: 2012-03-08 06:54
Message:
Thanks for reporting. This is a bug and your fix is correct. I have already
applied it in the trunk as r8229. As a workaround, you can also use the
same method on the Application object, passing the transaction.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3499505&group_id=4866

Bugs item #3499505, was opened at 2012-03-08 04:11
Message generated for change (Tracker Item Submitted) made by warth
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3499505&group_id=4866
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: WebKit
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek (warth)
Assigned to: Nobody/Anonymous (nobody)
Summary: staticmethod uses self
Initial Comment:
Hi,
a couple of days ago I got an application written in WebWare 1.1 to make some adjustments in it.
While preparing an environment for running I've encountered a problem. The application was raising an exception:
"NameError: global name 'self' is not defined" in WebKit/HTTPContent.py:321.
After looking into this file I've found this piece of code:
@staticmethod
def callMethodOfServlet(url, method, *args, **kwargs):
return self.application().callMethodOfServlet(self.transaction(), url, method, *args, **kwargs)
After removing @staticmethod decorator and adding the missing "self" parameter everything works like a charm.
At the moment I'm trying to find out if it is a bug in the WebWare (as it looks like to me) or does my software use the framework in a -wrong- way and the lack of the first parameter is intended?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104866&aid=3499505&group_id=4866

Am 24.10.2011 18:37, schrieb F. Behrens:
> Do you happen to have the patches you did around and could mail them to
> me for a quick glance so I can get an idea about what to look after?
I'll send you the patch but you can also get it by checking out
http://svn.w4py.org/Webware/trunk and then "svn diff -c 8162".
There is a test for this in WebKit/Testing/FieldStorage which is called
by the Twill tests in WebKit/Tests/twill/Testing.twill. I'm pretty sure
I've checked it with all possible Python version.
-- Christoph

Christoph Zwerschke wrote:
> The fix has been commited to the trunk in r8162 and backported to the
> 1.0 branch in r8163. I've also added a twill test for this behavior.
Sorry to dig this up again but I just upgraded our development server to
the 1.1 release and this bug still prevails.
Do you happen to have the patches you did around and could mail them to
me for a quick glance so I can get an idea about what to look after?
--
kind regards,
Fionn Behrens