Webware for Python

Can you enter this as a bug report on SourceForge?  I'll bet you're the
first person who has tried to forward from one context to another.

As a workaround, you could use a redirect instead.

- Geoff

> -----Original Message-----
> From: Stephan Diehl [mailto:stephan.diehl@...]
> Sent: Friday, March 15, 2002 7:55 AM
> To: webware-discuss@...
> Subject: [Webware-discuss] bug in webware?
> 
> 
> I found a strange bug in webware (or is it a feature?)
> platform: linux
> webware: cvs (15.03.2002)
> python: 2.2
> 
> Circumstances:
> /usr/local/Intranet/Webserver contains my application 
> environment (via 
> MakeAppWorkDir). There are two contexts: "Test" and "Repository".
> Test contains one Main.py that forwards the request
> (self.application().forward(trans,'../Repository/Repository'))
>  to Repository.
> 
> The problem now seems to be, that the old path is still known 
> to some vital 
> element. Anyway, I think, the place where things go wrong are in
> WebKit.ServletFactory.py, line 78: remainder = 
> path[len(contextPath)+1:]
> This cuts away from
> "/usr/local/Intranet/Webserver/Repository/Repository.py" the part
> "/usr/local/Intranet/Webserver/Repos"
> Incidently, this is just the len of
> "/usr/local/Intranet/Webserver/Test/", the original context
> 
> Now the feature part:
> forward can only be used within one context
> 
> Traceback:
> 
> /usr/local/Intranet/Webserver/Repository/Repository.py
> Traceback (most recent call last):
>   File "/usr/local/Webware/WebKit/Application.py", line 388, in 
> dispatchRequest
>     self.handleGoodURL(transaction)
>   File "/usr/local/Webware/WebKit/Application.py", line 534, 
> in handleGoodURL
>     self.createServletInTransaction(transaction)
>   File "/usr/local/Webware/WebKit/Application.py", line 990, in 
> createServletInTransaction
>     inst = self.getServlet(transaction,path,cache)
>   File "/usr/local/Webware/WebKit/Application.py", line 916, 
> in getServlet
>     inst = factory.servletForTransaction(transaction)
>   File "./WebKit/ServletFactory.py", line 178, in 
> servletForTransaction
>   File "./WebKit/ServletFactory.py", line 94, in importAsPackage
>   File "./WebKit/ServletFactory.py", line 130, in 
> _importModuleFromDirectory
> IOError: [Errno 2] No such file or directory: 
> '/usr/local/Intranet/Webserver/Test/itory/__init__.py'
> 
> stephan
> 
> 
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>

Re: [Webware-discuss] bug in webware? From: Stephan Diehl <stephan.diehl@gm...> - 2002-03-15 17:32 On Friday 15 March 2002 18:20, you wrote: > Can you enter this as a bug report on SourceForge? I'll bet you're the > first person who has tried to forward from one context to another. done > > As a workaround, you could use a redirect instead. I'll try that (if I think about it, I might have wanted a redirect in the first place anyway :-) Thanks for this hint > > - Geoff stephan > > > -----Original Message----- > > From: Stephan Diehl [mailto:stephan.diehl@...] > > Sent: Friday, March > > 15, 2002 7:55 AM > > > To: webware-discuss@... > > Subject: [Webware-discuss] bug in webware? > > > > > > I found a strange bug in webware (or is it a feature?) > > platform: linux > > webware: cvs (15.03.2002) > > python: 2.2 > > > > Circumstances: > > /usr/local/Intranet/Webserver contains my application > > environment (via > > MakeAppWorkDir). There are two contexts: "Test" and "Repository". > > Test contains one Main.py that forwards the request > > (self.application().forward(trans,'../Repository/Repository')) > > to Repository. > > > > The problem now seems to be, that the old path is still known > > to some vital > > element. Anyway, I think, the place where things go wrong are in > > WebKit.ServletFactory.py, line 78: remainder = > > path[len(contextPath)+1:] > > This cuts away from > > "/usr/local/Intranet/Webserver/Repository/Repository.py" the part > > "/usr/local/Intranet/Webserver/Repos" > > Incidently, this is just the len of > > "/usr/local/Intranet/Webserver/Test/", the original context > > > > Now the feature part: > > forward can only be used within one context > > > > Traceback: > > > > /usr/local/Intranet/Webserver/Repository/Repository.py > > Traceback (most recent call last): > > File "/usr/local/Webware/WebKit/Application.py", line 388, in > > dispatchRequest > > self.handleGoodURL(transaction) > > File "/usr/local/Webware/WebKit/Application.py", line 534, > > in handleGoodURL > > self.creat > > eServletInTransaction(transaction) > > > File "/usr/local/Webware/WebKit/Application.py", line 990, in > > createServletInTransaction > > inst = self.getServlet(transaction,path,cache) > > File "/usr/local/Webware/WebKit/Application.py", line 916, > > in getServlet > > inst = factory.servletForTransaction(transaction) > > File "./WebKit/ServletFactory.py", line 178, in > > servletForTransaction > > File "./WebKit/ServletFactory.py", line 94, in importAsPackage > > File "./WebKit/ServletFactory.py", line 130, in > > _importModuleFromDirectory > > IOError: [Errno 2] No such file or directory: > > '/usr/local/Intranet/Webserver/Test/itory/__init__.py' > > > > stephan > > > > > > > > _______________________________________________ > > Webware-discuss mailing list > > Webware-discuss@... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss

[Webware-discuss] bug in SessionDynamicStore? From: Tavis Rudd <tavis@re...> - 2002-03-16 01:15 Hi, I just noticed what looks like a thread conflict in the cvs version of SessionDynamicStore.py at 158, storeAllSessions. It acquires the lock and then calls MoveToFile, which will wait until it can acquire the lock: def MovetoFile(self, key): self._lock.acquire() try: global debug if debug: print ">> Moving %s to File" % key self._fileStore[key] = self._memoryStore[key] del self._memoryStore[key] finally: self._lock.release() ## Application support ## def storeSession(self, session): pass def storeAllSessions(self): self._lock.acquire() try: for i in self._memoryStore.keys(): self.MovetoFile(i) finally: self._lock.release() Tavis

Re: [Webware-discuss] bug in SessionDynamicStore? From: Tavis Rudd <tavis@re...> - 2002-03-16 02:04 Hello again, there as appears to a buglet in SessionMemoryStore that might leave old session files lying around permanently if TaskKit or Application change in subtle ways in the future: def __init__(self, app, restoreFiles=1): SessionStore.__init__(self, app) self._store = {} if restoreFiles == 1: filestore = SessionFileStore(app) keys = filestore.keys() for i in keys: self[i] = filestore[i] def storeAllSessions(self): filestore = SessionFileStore(self._app) for i in self.keys(): filestore[i]=self[i] In theory, there there should be a: filestore.clear() added after the old sessions are restored because the 'filestore' appears to be discarded after it is used in __init__. In practice, I assume TaskKit keeps a reference to it and the old sessions are cleared by the sweeper thread. But, it wouldn't hurt to be safe. Tavis On Friday 15 March 2002 18:30, Tavis Rudd wrote: > Hi, > I just noticed what looks like a thread conflict in the cvs version > of SessionDynamicStore.py at 158, storeAllSessions. It acquires > the lock and then calls MoveToFile, which will wait until it can > acquire the lock: > > def MovetoFile(self, key): > self._lock.acquire() > try: > global debug > if debug: print ">> Moving %s to File" % key > self._fileStore[key] = self._memoryStore[key] > del self._memoryStore[key] > finally: > self._lock.release() > > > > ## Application support ## > > def storeSession(self, session): > pass > > def storeAllSessions(self): > self._lock.acquire() > try: > for i in self._memoryStore.keys(): > self.MovetoFile(i) > finally: > self._lock.release() > Tavis > > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss

Re: [Webware-discuss] bug in SessionDynamicStore? From: Tavis Rudd <tavis@re...> - 2002-03-16 02:07 excuse my Friday afternoon typos ;) On Friday 15 March 2002 19:18, Tavis Rudd wrote: > Hello again, > there as appears to a buglet in SessionMemoryStore that might leave > old session files lying around permanently if TaskKit or > Application change in subtle ways in the future:

Re: [Webware-discuss] RE: a patch for better email error notification From: Tavis Rudd <tavis@re...> - 2002-03-16 04:00 Attachments: email.diff      Geoff, here's an updated patch for that email thing, including a config setting. Tavis

Re: [Webware-discuss] bug in SessionDynamicStore? From: Geoffrey Talvola <gtalvola@at...> - 2002-03-16 14:10 The lock is actually a threading.RLock object, which allows the same thread to acquire the lock multiple times as long as it releases it the same number of times. So this isn't a bug. Someone on comp.lang.python once said that the only synchronization objects you ever need in Python are RLock and Queue. I tend to agree. - Geoff On Friday March 15, 2002 09:30 pm, Tavis Rudd wrote: > Hi, > I just noticed what looks like a thread conflict in the cvs version > of SessionDynamicStore.py at 158, storeAllSessions. It acquires the > lock and then calls MoveToFile, which will wait until it can acquire > the lock: > > def MovetoFile(self, key): > self._lock.acquire() > try: > global debug > if debug: print ">> Moving %s to File" % key > self._fileStore[key] = self._memoryStore[key] > del self._memoryStore[key] > finally: > self._lock.release() > > > > ## Application support ## > > def storeSession(self, session): > pass > > def storeAllSessions(self): > self._lock.acquire() > try: > for i in self._memoryStore.keys(): > self.MovetoFile(i) > finally: > self._lock.release() > Tavis

Re: [Webware-discuss] bug in SessionDynamicStore? From: Geoffrey Talvola <gtalvola@at...> - 2002-03-16 14:53 On Friday March 15, 2002 10:18 pm, Tavis Rudd wrote: > Hello again, > there as appears to a buglet in SessionMemoryStore that might leave > old session files lying around permanently if TaskKit or Application > change in subtle ways in the future: > > def __init__(self, app, restoreFiles=1): > SessionStore.__init__(self, app) > self._store = {} > if restoreFiles == 1: > filestore = SessionFileStore(app) > keys = filestore.keys() > for i in keys: > self[i] = filestore[i] > > def storeAllSessions(self): > filestore = SessionFileStore(self._app) > for i in self.keys(): > filestore[i]=self[i] > > In theory, there there should be a: > filestore.clear() > added after the old sessions are restored because the 'filestore' > appears to be discarded after it is used in __init__. You're right. I'll add it. > In practice, I assume TaskKit keeps a reference to it and the old > sessions are cleared by the sweeper thread. But, it wouldn't hurt to > be safe. No, I don't think TaskKit will ever clean it up. The sweeper thread will only sweep the old sessions from memory, but I don't think they'll ever get deleted from disk, because FileStore is temporarily used while loading and saving the sessions but isn't used while sweeping the sessions. This bug only affects SessionMemoryStore, not Dynamic or File stores. - Geoff

1 message has been excluded from this view by a project administrator.