From: German M. <ge...@fr...> - 2004-03-08 04:32:27
|
Hi, I'm trying to redefine application's exceptionHandlerClass in the=20 contextInitialize function of my context's __init__.py, but it looks=20 like in the application's __init__ function is defined after running=20 contextInitialize function in URLParser call. I have modified application=B4s __init__ function to run=20 exceptionHandlerClass definition before URLParser is called and it=20 worked well. Is that a bug? Is there any other way to redefine exceptionHandlerClass? What am I doing wrong? ------------------------------------------------------------------- #Context's __init__.py def contextInitialize(app, ctxPath): app._exceptionHandlerClass =3D NewExceptionHandlerClass ----------------------------------------------------------------- #CVS's Application.py --- __init__ ... URLParser.initApp(self) self._rootURLParser =3D URLParser.ContextParser(self) self.running =3D 1 self.startSessionSweeper() self._exceptionHandlerClass =3D ExceptionHandler -------------------------------------------------------------- #Modification's Application.py --- __init__ self._exceptionHandlerClass =3D ExceptionHandler URLParser.initApp(self) self._rootURLParser =3D URLParser.ContextParser(self) self.running =3D 1 self.startSessionSweeper() --------------------------------------------------------------- |
From: Jason H. <ja...@pe...> - 2004-03-09 20:35:30
|
On Sun, 2004-03-07 at 22:16, German Medina wrote: > I'm trying to redefine application's exceptionHandlerClass in the > contextInitialize function of my context's __init__.py, but it looks > like in the application's __init__ function is defined after running > contextInitialize function in URLParser call. > I have modified application=B4s __init__ function to run > exceptionHandlerClass definition before URLParser is called and it > worked well. > Is that a bug? Yes, this is a bug. Some of this code has been reorganized, and I guess this broke. Thanks for the report -- I've fixed it in CVS. By the way, if you report more bugs, please enter them into the sourceforge= =20 tracker, otherwise they might not get noticed. http://sourceforge.net/tracker/?func=3Dadd&group_id=3D4866&atid=3D10486= 6 peace, Jason |
From: Warren S. <wa...@wa...> - 2004-03-10 15:14:22
|
I currently support a legacy web based application that is implemented in Python CGI scripts with the session data stored client-side in hidden for= m variables. Although the session form variables are protected from manipulation by a checksum algorithm, this is still a non-optimal solution. This is one of several reasons that I have been considering the merits of migrating the app to WebKit and using the built in session support, but I am unsure of the scalability of the WebKit session implementation. The CGI app currently runs on more than a dozen web servers that share th= e same webspace via NFS. The web servers sit behind an "ip sprayer" (on th= e outside they appear as a single server). Changing this infrastructure is not an option. In the Application.config section of the WebKit Configuration Guide, unde= r the SessionPrefix heading, it talks about using mod_rewrite in conjunctio= n with a "hostname" SessionPrefix to avoid the need for multiple app server= s to share session data. Does this imply that multiple app servers can't share session data? If I had an app server running on each of the web servers, could they reliably share session data if the sessions were stored on the NFS space and the SessionStore was set to 'File'? --=20 Warren Smith wa...@wa... |